MSSQL unter Windows: 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.
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.
Knowledge Base article:
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 einigen Fällen führt eine Deadlock-Bedingung dazu, dass eine DB-Bibliotheksfunktion (wie dbsqlexec, dbsqlok, dbresults oder dbnextrow ) einen FEHLER ausgibt. Die Prüfung der Rückgabecodes aus DB-Bibliotheksfunktionen ist immer Aufgabe des Programms. Wenn von einer der DB-Bibliotheksfunktionen ein FEHLER ausgegeben wird, soll das Programm den Batch abbrechen und nicht versuchen, den Vorgang fortzusetzen. In einigen Fällen ist es möglich, folgeende Funktionen im Batch weiter auszuführen. Wenn jedoch eine Deadlock-Situation aufgetreten ist und die Funktionen, die diese herbeigeführt haben, zurückgesetzt wurden, schlagen spätere Funktionen in dem Batch wahrscheinlich mit einer schwerwiegenderen Fehlermeldung wie "Objekt nicht gefunden" fehl.
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:
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.
Überschreibbare Parameter
Name
Beschreibung
Standardwert
Aktiviert
Aktiviert oder deaktiviert den Workflow.
Ja
Intervall (Sekunden)
Gibt das Wiederholungsintervall in Sekunden für die Ausführung des Workflows an.
300
Priorität
Definiert die Warnungspriorität.
1
Schweregrad
Definiert den Warnungsschweregrad.
1
Synchronisierungszeit
Synchronisierungszeit
Timeout (Sekunden)
Gibt die Zeit an, zu der der Workflow ausgeführt werden dann, bevor er geschlossen und als fehlerhaft markiert wird.
200
Timeout für Datenbankverbindung (Sekunden)
Es tritt ein Fehler beim Workflow auf, und ein Ereignis wird registriert, wenn der Workflow nicht innerhalb des angegebenen Zeitraums auf die Datenbank zugreifen kann.
MSSQL unter Windows: 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.
Home
DEU