Vereisten: Er zijn veel redenen waarom de SQL Server-database deadlocks veroorzaakt; in productie kan iedereen deadlock-problemen tegenkomen, en de specifieke oorzaak wordt mogelijk niet alleen op basis van abnormale informatie van applicatiedeadlocks gelokaliseerd, dus het is noodzakelijk om extensie-events in SQL Server te gebruiken om deadlock-problemen te volgen en de specifieke details vast te leggen van wanneer deadlocks optreden.
Uitgebreide overzicht van het evenement
Extended Events is een lichtgewicht prestatiemonitoringfunctie waarmee gebruikers de gegevens kunnen verzamelen die ze nodig hebben om problemen te monitoren en op te lossen. Met deze functie kun je details bekijken over de interne werking van de data-engine voor prestatiemonitoring en probleemoplossingsgerelateerde doeleinden.
Met de Extended Events (XEvents)-architectuur kunnen gebruikers zoveel of zo weinig data gebruiken als nodig is om de prestaties van SQL Server, Azure SQL Database en Azure SQL Managed Instance te monitoren, identificeren of problemen op te lossen. Uitgebreide evenementen zijn zeer configureerbaar, licht en goed schaalbaar.
Referentie:
De hyperlink-login is zichtbaar.
De hyperlink-login is zichtbaar.
Oorzaken van patstellingen
Deadlocks worden veroorzaakt door concurrerende gelijktijdige vergrendelingen in een database, meestal bij meerstapstransacties. Elke gebruikerssessie kan één of meer taken namens zich laten draaien, waarbij elke taak verschillende resources kan ophalen of wachten om verschillende resources op te halen. De volgende soorten middelen kunnen blokkering veroorzaken en uiteindelijk tot een deadlock leiden.
- Locks: Locks die wachten om resources zoals objecten, pagina's, rijen, metadata en applicaties op te halen, kunnen deadlocks veroorzaken. Bijvoorbeeld, transactie T1 heeft een gedeeld slot (S-slot) op rij r1 en wacht op een exclusieve vergrendeling (X-slot) voor rij r2. Transactie T2 heeft een gedeelde vergrendeling (S-vergrendeling) op rij r2 en wacht op een exclusieve vergrendeling (X-vergrendeling) voor rij r1. Dit resulteert in een lockloop waarin zowel T1 als T2 op elkaar wachten om de vergrendelde bron vrij te geven.
- Werkerthreads: Taken die in de rij staan voor beschikbare workerthreads kunnen deadlocks veroorzaken. Als een queue-taak een resource heeft die alle worker-threads blokkeert, resulteert dit in een deadlock. Bijvoorbeeld, nadat sessie S1 een transactie start en een gedeelde vergrendeling (S-lock) voor regel r1 heeft verworven, gaat het in slaapstand. Een actieve sessie die op alle beschikbare workerthreads draait, probeert een exclusieve lock (X-lock) voor regel r1 te verkrijgen. Omdat sessie S1 geen workerthread kan krijgen, kan het de transactie niet committen en de lock op regel r1 niet openen. Dit zal resulteren in een patstelling.
- Geheugen: Een deadlock kan optreden wanneer een gelijktijdig verzoek wacht om geheugen te verkrijgen en het momenteel beschikbare geheugen niet voldoende is voor de behoeften. Zo worden bijvoorbeeld twee gelijktijdige queries (Q1 en Q2) uitgevoerd als door de gebruiker gedefinieerde functies, waarbij respectievelijk 10 MB en 20 MB geheugen worden verkregen. Als elke query 30 MB vereist en het totale beschikbare geheugen 20 MB is, moeten Q1 en Q2 wachten tot de ander geheugen vrijmaakt, wat zal resulteren in een deadlock.
- Parallelle query- en uitvoeringsgerelateerde resources: Verwerkingscoördinatoren, generatoren of consumententhreads die typisch aan geswitchte poorten worden gekoppeld, kunnen elkaar blokkeren wanneer ze ten minste één proces bevatten dat geen deel uitmaakt van een parallelle query, wat leidt tot deadlocks. Daarnaast bepaalt SQL Server bij de start van een parallelle query de mate van parallelisme of het aantal workerthreads op basis van de huidige werklast. Een deadlock kan optreden als er een onverwachte verandering in de systeemwerklast optreedt, bijvoorbeeld wanneer een nieuwe query op de server begint te draaien of wanneer het systeem zonder workerthreads komt te zitten.
- Multiple Activity Outcome Set (MARS) resources: Deze middelen worden gebruikt om de kruisuitvoering van meerdere activiteitsverzoeken onder MARS te beheersen.
Referentie:
De hyperlink-login is zichtbaar.
Deadlock uitgebreide gebeurtenisregistratie
Maak een extensie-event aan om de deadlock-informatie vast te leggen met het volgende commando:
Start een deadlock-event sessie
Stop een evenementsessie
Verwijder een gebeurtenissessie
Zoek de sessiegegevens van gebeurtenissen op
Testimpasses
Maak een nieuwe Tab1-tabel aan voor testen, maak twee nieuwe uitvoeringsvensters aan, en voer respectievelijk de volgende commando's uit:
Een deadlock treedt als volgt op:
Een transactie (proces-ID 68) met een ander proces is vastgelopen op een vergrendelde bron en is geselecteerd als deadlock-slachtoffer. Voer de transactie alsjeblieft opnieuw uit.
Transactie (Proces-ID 68) was vastgelopen op lockresources met een ander proces en is gekozen als deadlock-slachtoffer. Voer de transactie opnieuw uit. 
Bekijk de sessiegegevens van het evenement zoals weergegeven in de volgende figuur:
De gedetailleerde XML-gegevens zijn als volgt:
(Einde)
|
Geplaatst op 02-03-2024 19:13:04
|
|
|
|
Huisbaas|
Geplaatst op 02-03-2024 19:14:35
|
