Er zijn veel redenen waarom applicaties traag reageren, maar als gebruikers klagen over de prestaties, heb je mogelijk te maken met een SQL Server-impasse. Gelukkig zijn er manieren om de impasse van SQL Server te identificeren en te corrigeren, en zelfs te voorkomen dat deze de prestaties van de applicatie negatief beïnvloedt.
De deadlock van SQL Server is in wezen een impasse tussen twee processen die strijden om exclusieve toegang tot dezelfde bron. Omdat slechts één proces een resource tegelijk kan gebruiken, vertragen de prestaties totdat de impasse is opgelost.
Er zijn twee soorten SQL Server-deadlocks waar u op moet letten:conversievergrendelingen en cyclusvergrendelingen.
Deadlocks voor conversievergrendeling treden op wanneer een thread probeert een slot van het ene exclusieve type naar een ander exclusief type te converteren, maar dit niet kan omdat een andere thread al een gedeelde vergrendeling heeft op de bron die de eerste thread probeert te converteren.
In SQL Server zijn er drie soorten conversievergrendelingen:
- Gedeeld met intentie exclusief (SIX):deze vergrendeling treedt op wanneer een transactie met een gedeelde vergrendeling ook een exclusieve vergrendeling heeft op sommige pagina's of rijen.
- Gedeeld met intentie-update (SIU):deze vergrendeling treedt op wanneer een transactie met een gedeelde vergrendeling ook enkele pagina's of rijen heeft die zijn vergrendeld met een updatevergrendeling.
- Update met intentie exclusief (UIX):deze vergrendeling treedt op wanneer een transactie met een updatevergrendeling ook een exclusieve vergrendeling heeft op sommige pagina's of rijen.
Cyclusvergrendelingen zijn SQL Server-deadlocks die worden veroorzaakt door twee processen die strijden om een exclusieve vergrendeling van een resource die is vergrendeld door het andere proces.
Proces 1 houdt bijvoorbeeld een vergrendeling op resource 1 vast terwijl het wacht tot proces 2 zijn vergrendeling op resource 2 vrijgeeft. Als proces 2 een vergrendeling op resource 2 vasthoudt terwijl het wacht tot proces 1 resource 1 vrijgeeft, hebben we onszelf een blokkering van het fietsslot.
Hoe een SQL Server-impasse te diagnosticeren
De deadlock van SQL Server is slechts een van de tientallen mogelijke redenen waarom uw toepassing prestatieproblemen kan hebben. Als zoekopdrachten die normaal snel worden uitgevoerd, plotseling langzamer worden, is het mogelijk dat u een impasse hebt. Maar het kan ook zijn dat er iets anders aan de hand is.
Dus, afgezien van het opmerken van verminderde querysnelheid, hoe bepaal je zeker of deadlock de oorzaak is van je databaseprestatieproblemen?
De gemakkelijkste en meest definitieve manier om een impasse te identificeren, is de aanwezigheid van een 1205-foutmelding:
Transactie (proces-ID %d) is vastgelopen op %.*ls-bronnen met een ander proces en is gekozen als het slachtoffer van de impasse. Voer de transactie opnieuw uit.
De 1205-foutmelding vertelt u letterlijk dat er een impasse is en hoe u deze kunt oplossen. Echter, zoals Jeremiah Peschka opmerkt, als je de oorzaak van de impasse niet hebt opgelost, zal het waarschijnlijk niet lukken om de transactie opnieuw uit te voeren.
Een andere optie voor het vinden van deadlocks is om een SQL Server-deadlock-grafiek uit Extended Events te halen. Door de deadlock te extraheren via Extended Events kunt u de deadlock-XML bekijken, die meer informatie biedt dan de grafische weergave van een deadlock-grafiek.
De deadlock-XML is geordend op de lijst met slachtoffers, de proceslijst en de bronnenlijst. Elke sectie geeft gedetailleerde beschrijvingen van de slachtoffers, processen en bronnen die betrokken zijn bij de impasse, waardoor het gemakkelijker wordt om problemen op te lossen en op te lossen.
SQL Server-deadlock oplossen
De enige manier om een SQL Server-impasse op te lossen, is door een van de processen te beëindigen en de vergrendelde bron vrij te maken zodat het proces kan worden voltooid. Dit gebeurt automatisch wanneer SQL Server een impasse detecteert en een van de concurrerende processen (d.w.z. het slachtoffer) uitschakelt.
SQL Server kiest normaal gesproken willekeurig welke verbinding moet worden afgebroken, maar het is mogelijk om prioriteiten voor deadlocks in te stellen om te bepalen welke verbinding wordt verbroken tijdens een deadlock. Wanneer twee verbindingen verschillende prioriteitsinstellingen hebben, zal SQL Server de transactie met de laagste prioriteit beëindigen.
Hoe SQL Server-deadlock te voorkomen
SQL Server-impasse is een feit van het leven wanneer u een drukke database beheert. DBA's kunnen echter helpen het optreden van deadlocks te verminderen en hun impact op de databaseprestaties te minimaliseren door een aantal preventieve maatregelen te nemen:
- Maak betere indexen
- Transactieprioriteiten aanpassen
- Een Try/Retry-model uitvoeren
- Isolatiemodi wijzigen
- Houd sloten zo kort mogelijk vast
- Toegang tot bronnen elke keer in dezelfde volgorde
- Dien geen transactie in voordat u alle benodigde informatie heeft
- Schakel escalatie beperken
Hoewel het niet mogelijk is om de deadlock van SQL Server volledig te voorkomen, kunt u deze best practices implementeren en proactief enkele van de meest voorkomende bronnen van deadlock omzeilen om transacties soepel te laten verlopen en de databaseprestaties te optimaliseren.