Die Transaktion befand sich wegen eines anderen Prozesses in einer ressourcenbezogenen Deadlocksituation und wurde als Deadlockopfer ausgewählt. Führen Sie die Transaktion erneut aus

Zusammenfassung

Dieser Fehler tritt auf, wenn in Microsoft® SQL Server™ ein Deadlock auftritt. Ein Deadlock tritt auf, wenn zwei (oder mehr) Prozesse auf eine Ressource zuzugreifen versuchen, die ein anderer Prozess gesperrt hat. Da jeder Prozess eine Anforderung für eine andere Ressource aufweist, kann keiner der Prozesse abgeschlossen werden. Wenn ein Deadlock erkannt wird, führt SQL Server einen Rollback des Befehls mit der kürzesten Verarbeitungsdauer aus und gibt die Fehlermeldung 1205 an die Clientanwendung zurück. Dieser Fehler ist nicht schwerwiegend und führt nicht unbedingt zum Beenden des Batchs.

Lösungen

In manchen Fällen führt ein Deadlockzustand dazu, dass eine DB-Library-Funktion (z. B. dbsqlexec, dbsqlok, dbresults oder dbnextrow) den Wert FAIL zurückgibt. Die Verantwortung für das Überprüfen der Rückgabecodes der einzelnen DB-Library-Funktionen liegt immer beim Programm. Wenn von einer dieser DB-Library-Funktionen der Wert FAIL zurückgegeben wird, sollte der Batch vom Programm abgebrochen und der Vorgang nicht fortgesetzt werden. In einigen Fällen ist die Ausführung nachfolgender Funktionen im Batch möglich. Da eine Deadlocksituation aufgetreten ist und für die Funktionen, die sie verursacht haben, ein Rollback ausgeführt wurde, schlagen spätere Funktionen im Batch wahrscheinlich mit einem schwerwiegenderen Fehler fehl (z. B. "Objekt nicht gefunden").

In anderen Fällen führt ein Deadlockzustand nicht dazu, dass eine DB-Library-Funktion FAIL zurückgibt. In diesen Fällen muss das Programm den Nachrichtenhandler auf die Fehlermeldung 1205 überprüfen und die dbsetuserdata-Funktion verwenden, um dies der Anwendung mitzuteilen. Anschließend muss das Programm nach jedem DB-Library-Aufruf den Deadlockindikator überprüfen. Der Batch sollte abgebrochen werden, wenn ein Deadlock erkannt wird.

Obwohl es möglicherweise unnötig scheinen mag, nach Empfang einer Deadlockmeldung 1205 einen Batch abzubrechen, ist dies notwendig, da der Server den Batch in einer Deadlocksituation nicht immer beendet. Wenn der Batch nicht abgebrochen wird, können alle Versuche, einen neuen Batch abzusenden, zum DB-Library-Fehler 10038 "Es wurde versucht, einen neuen SQL Server-Vorgang zu starten, obwohl Ergebnisse ausstehen" führen.

Sie können auch die SET DEADLOCK_PRIORITY-Anweisung (mit dem Parameter LOW oder NORMAL) verwenden. Von SET DEADLOCK_PRIORITY wird die Reaktion der Sitzung in einer Deadlocksituation gesteuert. Wenn LOW festgelegt ist, ist der Prozess das bevorzugte Opfer einer Deadlocksituation. Wenn NORMAL festgelegt ist, wird von der Sitzung die Standardbehandlungsmethode für Deadlocks verwendet.

Beim Fortbestehen einer Deadlocksituation ist es oft hilfreich, das Ablaufverfolgungsflag 1204 zu verwenden, um weitere Informationen zu sammeln. Das Ablaufverfolgungsflag 1204 druckt die Deadlockketten und das Deadlockopfer, wie in dieser Beispielausgabe gezeigt, aus:

*** Deadlock Detected *** == Process 7 chosen as deadlock victim == Deadlock Detected at: 1998-09-10 16:39:29.17 == Session participant information: SPID: 7 ECID: 0 Statement Type: UPDATE Input Buf: update t1 set c1 = c1 where c1 = 2 SPID: 8 ECID: 0 Statement Type: UPDATE Input Buf: update t1 set c1 = c1 where c1 = 1 == Deadlock Lock participant information: == Lock: KEY: 2:117575457:1 (010001000000) Database: tempdb Table: t1 Index: i1 - Held by: SPID 7 ECID 0 Mode "S" - Requested by: SPID 8 ECID 0 Mode "X" == Lock: KEY: 2:117575457:1 (020002000000) Database: tempdb Table: t1 Index: i1 - Held by: SPID 8 ECID 0 Mode "S" - Requested by: SPID 7 ECID 0 Mode "X"

Diese Deadlockinformationen können wie folgt interpretiert werden:

• Der erste Abschnitt zeigt das Deadlockopfer und den Zeitpunkt des Deadlocks sowie die am Deadlock beteiligten Sitzungen an. Für jede Sitzung werden die aktuelle Serverprozess-ID (SPID), der Anweisungstyp und ein Teil des Eingabepuffers angezeigt.

• Der zweite Abschnitt zeigt Details zu den am Deadlock beteiligten Sperren an. Beachten Sie in der oben angezeigten Ausgabe, dass Schlüsselsperren für die t1-Tabelle und den i1-Index am Deadlock beteiligt sind. Die Deadlockausgabe zeigt an, welche Prozesse die am Deadlock beteiligten Sperren besitzen und welche Sitzungen auf die Gewährung der Sperren warten sowie die zugeordneten Sperrmodi.

• Der Prozess, der das geringste Protokollvolumen generiert hat, wird standardmäßig als Deadlockopfer ausgewählt, und es wird ein automatischer Rollback für ihn ausgeführt. Um zu beeinflussen, für welche Sitzung ein Rollback ausgeführt wird, legen Sie DEADLOCK_PRIORITY für eine Sitzung fest.