Der er mange grunde til, at applikationer kan være langsomme til at reagere, men hvis brugere klager over ydeevne, har du muligvis at gøre med en SQL Server-deadlock. Heldigvis er der måder at identificere og korrigere SQL Server-deadlock på og endda forhindre, at det påvirker applikationens ydeevne negativt.
SQL Server-deadlock er i bund og grund en afstand mellem to processer, der konkurrerer om eksklusiv adgang til den samme ressource. Fordi kun én proces kan bruge en ressource ad gangen, sænkes ydeevnen, indtil dødvandet er løst.
Der er to typer SQL Server-deadlocks, man skal være opmærksom på:konverteringslåse og cykluslåse.
Konverteringslåse deadlocks opstår, når en tråd forsøger at konvertere en lås fra én eksklusiv type til en anden eksklusiv type, men ikke kan, fordi en anden tråd allerede har en delt lås på den ressource, den første tråd forsøger at konvertere.
I SQL Server er der tre typer konverteringslåse:
- Delt med hensigt eksklusiv (SIX):Denne lås opstår, når en transaktion, der har en delt lås, også har en eksklusiv lås på nogle sider eller rækker.
- Delt med hensigtsopdatering (SIU):Denne lås opstår, når en transaktion, der har en delt lås, også har nogle sider eller rækker låst med en opdateringslås.
- Opdatering med eksklusiv hensigt (UIX):Denne lås opstår, når en transaktion, der har en opdateringslås, også har en eksklusiv lås på nogle sider eller rækker.
Cykluslåse er SQL Server-deadlocks forårsaget af to processer, der kæmper om en eksklusiv lås på en ressource, der er låst af den anden proces.
For eksempel holder proces 1 en lås på ressource 1, mens den venter på, at proces 2 frigiver sin lås på ressource 2. Hvis proces 2 holder en lås på ressource 2, mens den venter på, at proces 1 frigiver ressource 1, har vi os selv en låst cykellås.
Sådan diagnosticeres SQL Server-deadlock
SQL Server-deadlock er blot en af snesevis af mulige årsager til, at din applikation kan have problemer med ydeevnen. Hvis forespørgsler, der normalt kører hurtigt, pludselig går langsommere, er det muligt, at du har en dødvande. Men det er også muligt, at der sker noget andet.
Så bortset fra at bemærke reduceret forespørgselshastighed, hvordan afgør du så med sikkerhed, om dødvande er skyld i dine databaseydeevneproblemer?
Den nemmeste og mest definitive måde at identificere dødvande er tilstedeværelsen af en 1205 fejlmeddelelse:
Transaktionen (Proces-ID %d) var låst på %.*ls ressourcer med en anden proces og er blevet valgt som offer for dødvandet. Kør transaktionen igen.
1205-fejlmeddelelsen fortæller dig bogstaveligt talt, at der er et dødvande, og hvordan du løser det. Men som Jeremiah Peschka påpeger, hvis du ikke har rettet årsagen til dødvandet, vil det sandsynligvis være mislykket at køre transaktionen igen.
En anden mulighed for at finde deadlocks er at trække en SQL Server-deadlock-graf ud af Extended Events. Ved at udtrække deadlock gennem Extended Events kan du se på deadlock XML, som giver flere oplysninger end den grafiske repræsentation af en deadlock-graf.
Deadlock XML er organiseret efter offerlisten, proceslisten og ressourcelisten. Hvert afsnit giver detaljerede beskrivelser af ofrene, processerne og ressourcerne involveret i dødvandet, hvilket gør det nemmere at fejlfinde og løse problemet.
Sådan rettes SQL Server-deadlock
Den eneste måde at løse en SQL Server-deadlock på er at afslutte en af processerne og frigøre den låste ressource, så processen kan fuldføres. Dette sker automatisk, når SQL Server registrerer et dødvande og dræber en af de konkurrerende processer (dvs. offeret).
SQL Server vælger normalt, hvilken forbindelse der skal dræbes tilfældigt, men det er muligt at indstille deadlock-prioriteter for at bestemme hvilken forbindelse der dræbes under en deadlock. Når to forbindelser har forskellige prioritetsindstillinger, afbryder SQL Server transaktionen med den laveste prioritet.
Sådan forhindrer du SQL Server-deadlock
SQL Server-deadlock er et faktum, når du administrerer en travl database. DBA'er kan dog hjælpe med at reducere forekomsten af deadlocks og minimere deres indvirkning på databasens ydeevne ved at tage nogle få forebyggende foranstaltninger:
- Opret bedre indekser
- Juster transaktionsprioriteter
- Indfør en Prøv/Prøv-model
- Skift isolationstilstande
- Hold låse i så kort tid som muligt
- Få adgang til ressourcer i samme rækkefølge hver gang
- Indsend ikke en transaktion, før du har alle de oplysninger, du har brug for
- Begræns låseeskalering
Selvom det ikke er muligt helt at forhindre SQL Server-deadlock, kan du implementere disse bedste praksisser og proaktivt omgå nogle af de mest almindelige kilder til deadlock for at holde transaktionerne flydende og optimere databasens ydeevne.