Deadlock / Sperrkonflikt (ORA-00060, 1213, 40P01)

Du hast einen Deadlock erhalten (Oracle ORA-00060, MySQL 1213, PG 40P01, MSSQL 1205). Erfasse den Graph, ermittle das Muster, verhindere die Wiederholung. Deadlocks werden durch Design gelöst — Ziel ist, ihre Häufigkeit zu senken.

Zuerst den Deadlock-Graph erfassen

Welche zwei (oder mehr) Sessions, welche Ressourcen, welche Sperrmodi sind kollidiert? Ohne das gesehen zu haben keine blinden Korrekturen anwenden.

-- Check the trace file referenced in the alert log (deadlock graph). For history:
SELECT * FROM dba_hist_active_sess_history WHERE event LIKE 'enq: TX%' ORDER BY sample_time DESC FETCH FIRST 20 ROWS ONLY;

• Graph liegt vor — zwei Transaktionen sperren Ressourcen in umgekehrter Reihenfolge
• Viele Transaktionen stauen sich auf einer einzigen Zeile/Tabelle (Hotspot)
• Es gibt breite Bereichssperren (viele Zeilen werden gesperrt)

Nutzt die sperrende Abfrage einen Index?

Ohne Index sperrt ein UPDATE/DELETE viele Zeilen (sogar die ganze Tabelle), um die WHERE-Klausel zu erfüllen → eine Quelle von Deadlocks. Prüfe den Plan.

EXPLAIN <the UPDATE/DELETE involved in the deadlock>;  -- type=ALL means a full scan, no index

• Kein Index / macht einen Full Scan
• Es gibt einen Index, aber es kollidiert trotzdem

Ursache: umgekehrte Sperrreihenfolge

Die häufigste Deadlock-Ursache: Zwei Transaktionen greifen in unterschiedlicher Reihenfolge auf Ressourcen zu. Laufen A→B und B→A gleichzeitig, entsteht ein Deadlock.

Ursache: fehlender Index → breite Sperren

Ein UPDATE/DELETE ohne Index sperrt mehr Zeilen als nötig und macht Deadlocks weit wahrscheinlicher.

Ursache: Hotspot

Viele Transaktionen stauen sich gleichzeitig auf einer einzigen Ressource wie einer Zählerzeile/einem Key.