# Nach dem Deadlock
Typ: Checkliste
Herkunft: database-administration-basics / transactions-isolation / database-transactions-deadlock-sequence
Version: database-transactions-deadlock-sequence-2026-09-12
Geprüft: 2026-09-12

ACHTUNG: Dieses Dokument ist ein Lernartefakt aus einer Schulungssequenz. Es ist kein produktives Runbook. Vor jeder Anwendung in einer realen Umgebung müssen die Schritte gegen lokale Dokumentation, Runbooks und Freigabestatus geprüft werden.

## Szenario
Zwei nächtliche Verarbeitungsläufe geraten mehrmals pro Woche in einen Deadlock. Die Datenbank bricht jedes Mal einen der beiden ab; welcher es trifft, wechselt. Beide Läufe ändern dieselben zwei Tabellen, keiner verwendet ausdrückliche Sperrbefehle.

## Schritte
1. Den Deadlock-Eintrag auswerten: welche Objekte, in welcher Reihenfolge, von welchem Lauf
2. Die tatsächliche Zugriffsreihenfolge beider Läufe gegenüberstellen
3. Beide Läufe auf eine einheitliche Zugriffsreihenfolge umstellen
4. In beiden Läufen eine begrenzte Wiederholung für abgebrochene Transaktionen ergänzen
5. Die Transaktionen so eng schneiden, dass sich die Zeitfenster kaum noch überlappen
6. Über mehrere Nächte prüfen, ob noch Deadlocks auftreten

## Begründung
Warum: Gegen Deadlocks hilft zuerst die Ursache und erst danach die Abfederung: Eine einheitliche Sperrreihenfolge beseitigt den Zyklus, während eine Wiederholung ihn nur überlebt. Die Reihenfolge der Maßnahmen entscheidet, ob am Ende ein behobenes oder ein dauerhaft verwaltetes Problem steht.
Folgen: **+** Die vereinheitlichte Reihenfolge beendet den Zyklus, und die Wiederholung fängt die Restfälle ab, ohne dass jemand nachts eingreifen muss. **−** Sie zwingt beide Läufe in eine gemeinsame Konvention, die bei jedem künftigen Lauf mitgedacht werden muss — und der Abbruch bleibt möglich, weil laut Dokumentation nicht vorhersagbar ist, welche Transaktion es trifft.

## Quellen
1. https://www.postgresql.org/docs/current/explicit-locking.html