Ein Dirty Read (deutsch etwa „schmutziges Lesen") ist eine Anomalie, bei der eine Transaktion Daten liest, die eine andere Transaktion geändert, aber noch nicht festgeschrieben (committet) hat. „Dirty" bedeutet hier: unbestätigt, möglicherweise nie dauerhaft.
Beispiel
Ein Kontostand beträgt 100 Euro. Transaktion A zieht 40 Euro ab und hat den neuen Stand von 60 Euro noch nicht committet. Transaktion B liest jetzt den Stand von 60 Euro und verarbeitet ihn (etwa für eine Kreditentscheidung). Führt A danach ein Rollback aus, existierte der Wert 60 nie: B hat mit einer Zahl gearbeitet, die nur als Zwischenzustand existierte — der wahre Stand ist weiterhin 100 Euro.
Wann tritt er auf?
Der Dirty Read ist die einzige Anomalie, die bereits die zweitniedrigste Stufe verhindert: Read Committed erlaubt ausschließlich das Lesen bereits festgeschriebener Daten. Möglich ist er nur bei READ UNCOMMITTED — der niedrigsten Isolationsebene. In den üblichen MVCC-Systemen ist der Dirty Read praktisch ausgeschaltet: PostgreSQL, InnoDB und Oracle arbeiten mit MVCC und lesen grundsätzlich nur committete Versionen.
Formale Einordnung
In der Kritik am ANSI-SQL-Standard von Berenson, Bernstein, Gray, Melton und O'Neil (SIGMOD 1995) ist der Dirty Read die Anomalie P1 beziehungsweise A1 — je nachdem, ob man die Phänomen-Definition oder die Sperr-basierte Interpretation zugrunde legt. Die ANSI-Formulierungen sind nachweislich mehrdeutig; Read Committed verhindert den Dirty Read aber in jeder Interpretation.
Gegenmittel
- Isolationsebene mindestens Read Committed wählen.
- Langlaufende Transaktionen vermeiden — je kürzer die einzelne Transaktion, desto kleiner das Fenster, in dem andere auf Zwischenstände treffen.
- ACID-konforme Systeme stellen die Isolation als Standard sicher (I in ACID).
Verwandte Grundlagen: Isolationsebene, Read Committed, Repeatable Read, Phantom Read, Write Skew.