Write Skew ist eine Datenbank-Anomalie, bei der zwei parallele Transaktionen überlappende Daten lesen, aber disjunkte Zeilen schreiben, und dadurch gemeinsam eine Invariante verletzen, obwohl keine der beiden Transaktionen für sich genommen etwas Falsches tut. Die Anomalie wurde 1995 von Berenson, Bernstein, Gray, Melton, O'Neil und O'Neil in ihrer Kritik des ANSI-SQL-Standards benannt (A Critique of ANSI SQL Isolation Levels, SIGMOD); die ursprüngliche Standard-Liste der Anomalien hatte sie übersehen.
Das klassische Beispiel: der Notdienst
Zwei Ärzte teilen sich den Bereitschaftsdienst. Die Regel lautet: Ein Arzt darf sich nur abmelden, wenn mindestens einer der anderen verfügbar ist. Transaktion T1 liest, dass Dr. B verfügbar ist, und meldet Dr. A ab. Transaktion T2 liest, dass Dr. A verfügbar ist, und meldet Dr. B ab. Beide committen, und plötzlich ist niemand mehr im Dienst. Jede Prüfung war im Moment ihrer Ausführung korrekt; weil beide auf demselben Snapshot arbeiteten, sah jede den anderen als verfügbar.
Warum Snapshot Isolation und Repeatable Read betroffen sind
MVCC-basierte Verfahren wie die Snapshot Isolation erkennen Konflikte nur, wenn zwei Transaktionen dieselbe Zeile schreiben (First-Commiter-Wins). Schreiben zwei Transaktionen verschiedene Zeilen, gibt es keinen sichtbaren Konflikt, auch wenn die gelesenen Daten überlappen. Deshalb verhindert Snapshot Isolation Dirty Reads, Non-Repeatable Reads und Phantom-Reads, ist aber trotzdem nicht serialisierbar. Auch Repeatable Read mit MVCC, etwa in PostgreSQL, lässt Write Skew zu.
Wie Serializable und Sperren helfen
Serializable verhindert Write Skew. PostgreSQL setzt die Stufe als Serializable Snapshot Isolation (SSI) um: SSI beobachtet gefährliche Abhängigkeiten zwischen Transaktionen und bricht eine der beiden ab, bevor die Invariante kippen kann. Klassisches Sperren mit Two-Phase-Locking verhindert Write Skew ebenfalls, weil gemeinsame Lese-Sperren auf den überlappenden Daten die Transaktionen zwangsläufig serialisieren.
Abgrenzung zu anderen Anomalien
Write Skew ist kein Lost Update, bei dem eine Transaktion die Änderung einer anderen auf derselben Zeile überschreibt, und kein Deadlock, bei dem sich Transaktionen gegenseitig blockieren. Das Tückische an Write Skew: Beide Transaktionen committen erfolgreich, die Datenbank meldet keinen Konflikt, nur die Anwendungs-Invariante ist verletzt, also genau das, was ACID eigentlich absichern soll.
Verwandte Grundlagen: Transaktion und ACID; wer Garantien vergleichen will, findet in Linearisierbarkeit das stärkste Konsistenzmodell für einzelne Objekte.