Anforderungen: Es gibt viele Gründe, warum SQL-Server-Datenbanken Deadlocks verursachen; in der Produktion kann jeder auf Deadlock-Probleme stoßen, und die spezifische Ursache wird möglicherweise nicht allein durch die abnormalen Informationen von Anwendungs-Deadlocks bestimmt, daher ist es notwendig, Erweiterungsereignisse in SQL Server zu verwenden, um Deadlock-Probleme zu verfolgen und die genauen Details zu dokumentieren, wann Deadlocks auftreten.
Erweiterte Veranstaltungsübersicht
Extended Events ist eine leichte Performance-Monitoring-Funktion, die es Nutzern ermöglicht, die Daten zu sammeln, die sie benötigen, um Probleme zu überwachen und zu lösen. Diese Funktion ermöglicht es Ihnen, Details zu den internen Abläufen der Daten-Engine zur Leistungsüberwachung und Problemlösung einzusehen.
Mit der Extended Events (XEvents)-Architektur können Nutzer so viel oder so wenig Daten verwenden, wie sie benötigen, um die Leistung von SQL Server, Azure SQL Database und Azure SQL Managed Instance zu überwachen, zu identifizieren oder zu beheben. Extended Events sind hoch konfigurierbar, leicht und gut skalierbar.
Referenz:
Der Hyperlink-Login ist sichtbar.
Der Hyperlink-Login ist sichtbar.
Ursachen von Pattsituationen
Deadlocks entstehen durch konkurrierende Nebenläufigkeitssperren in einer Datenbank, meist bei mehrstufigen Transaktionen. Jede Benutzersitzung kann eine oder mehrere Aufgaben in ihrem Namen ausführen, wobei jede Aufgabe verschiedene Ressourcen abrufen oder warten kann. Die folgenden Arten von Ressourcen können Blockade verursachen und schließlich zu einer Deadlock führen.
- Sperren: Sperren, die darauf warten, Ressourcen wie Objekte, Seiten, Zeilen, Metadaten und Anwendungen abzurufen, können zu Deadlocks führen. Zum Beispiel hat die Transaktion T1 ein gemeinsames Schloss (S-Schloss) auf Zeile r1 und wartet darauf, ein exklusives Schloss (X-Schloss) für Zeile r2 zu erhalten. Transaktion T2 hat ein gemeinsames Schloss (S-Schloss) in Reihe r2 und wartet darauf, ein exklusives Schloss (X-Schloss) für Zeile r1 zu erhalten. Dies führt zu einer Lock-Loop, in der sowohl T1 als auch T2 darauf warten, dass der andere die gesperrte Ressource freigibt.
- Worker-Threads: Aufgaben, die für verfügbare Worker-Threads in Warteschlangen gehen, können zu Deadlocks führen. Wenn eine Warteschlange-Aufgabe eine Ressource hat, die alle Worker-Threads blockiert, führt das zu einem Deadlock. Zum Beispiel geht Sitzung S1 nach Beginn einer Transaktion und dem Erwerb eines gemeinsamen Schlosses (S-Lock) für Zeile r1 in den Ruhemodus. Eine aktive Sitzung, die auf allen verfügbaren Worker-Threads läuft, versucht, eine exklusive Sperre (X-Lock) für Zeile r1 zu erhalten. Da Sitzung S1 keinen Worker-Thread abrufen kann, kann sie die Transaktion nicht committen und die Sperre auf Zeile R1 aufheben. Das führt zu einer Pattsituation.
- Speicher: Ein Deadlock kann auftreten, wenn eine gleichzeitige Anfrage darauf wartet, Speicher zu gewinnen, und der derzeit verfügbare Speicher nicht für seine Bedürfnisse ausreicht. Zum Beispiel werden zwei gleichzeitige Abfragen (Q1 und Q2) als benutzerdefinierte Funktionen ausgeführt und erhalten jeweils 10 MB bzw. 20 MB Speicher. Wenn jede Abfrage 30 MB benötigt und der gesamte verfügbare Speicher 20 MB beträgt, müssen Q1 und Q2 aufeinander warten, um Speicher freizumachen, was zu einem Deadlock führt.
- Parallele Abfrage- und ausführungsbezogene Ressourcen: Verarbeitungskoordinatoren, Generatoren oder Consumer-Threads, die typischerweise mit geschalteten Ports assoziiert sind, können sich gegenseitig blockieren, wenn sie mindestens einen Prozess enthalten, der nicht Teil einer parallelen Abfrage ist, was zu Deadlocks führt. Außerdem bestimmt SQL Server bei Beginn der Ausführung einer parallelen Abfrage den Grad der Parallelität oder die Anzahl der Worker-Threads basierend auf der aktuellen Arbeitsbelastung. Ein Deadlock kann auftreten, wenn eine unerwartete Änderung der Systemarbeitslast auftritt, zum Beispiel wenn eine neue Abfrage im Server läuft oder wenn das System keine Worker-Threads mehr hat.
- Multiple Activity Outcome Set (MARS)-Ressourcen: Diese Ressourcen werden verwendet, um die Cross-Ausführung mehrerer Aktivitätsanfragen unter MARS zu steuern.
Referenz:
Der Hyperlink-Login ist sichtbar.
Deadlock-erweitertes Ereignislogging
Erstellen Sie ein Erweiterungsereignis, um die Deadlock-Informationen mit folgendem Befehl festzuhalten:
Starte eine Deadlock-Ereignissitzung
Stoppen Sie eine Veranstaltungssitzung
Eine Ereignissitzung löschen
Abfrage von Ereignissitzungsdaten
Test-Deadlocks
Erstelle eine neue Tab1-Tabelle zum Testen, erstelle zwei neue Ausführungsfenster und führe jeweils folgende Befehle aus:
Ein Deadlock tritt wie folgt auf:
Eine Transaktion (Prozess-ID 68) mit einem anderen Prozess ist auf einer gesperrten Ressource blockiert und als Deadlock-Opfer ausgewählt. Bitte führen Sie die Transaktion erneut durch.
Die Transaktion (Prozess-ID 68) war bei den Sperrressourcen mit einem anderen Prozess blockiert und wurde als Opfer der Blockade ausgewählt. Wiederholen Sie die Transaktion. 
Sehen Sie sich die Daten der Veranstaltungssitzungen wie in der folgenden Abbildung dargestellt an:
Die detaillierten XML-Daten sind wie folgt:
(Ende)
|
Veröffentlicht am 02.03.2024 19:13:04
|
|
|
|
Vermieter|
Veröffentlicht am 02.03.2024 19:14:35
|
