Transaktions-Isolation und Anomalien

In den vorherigen Lektionen haben wir Transaktionen und ihre ACID-Garantien kennengelernt. Das „I" – Isolation – haben wir bisher nur grob skizziert: parallel laufende Transaktionen sollen sich nicht gegenseitig stören. Was passiert wenn sie es doch tun, ist Thema dieser Lektion.

Wenn zwei oder mehr Transaktionen gleichzeitig auf dieselben Daten zugreifen, können Probleme entstehen, die unter normaler sequentieller Ausführung nicht passieren würden. Die Datenbank-Community hat vier klassische dieser Probleme katalogisiert – die Anomalien. SQL bietet vier Isolationsstufen, die jeweils einen bestimmten Satz dieser Anomalien verhindern. Wer eine strengere Stufe wählt, bekommt mehr Sicherheit – zahlt aber mit Performance.

1) Warum Isolation ein Trade-off ist

Im Prinzip könnte das DBMS einfach alle Transaktionen seriell nacheinander ausführen – eine nach der anderen, perfekt isoliert, null Konflikte. Das wäre allerdings furchtbar langsam: kein Webshop, in dem 1000 Kunden parallel klicken, würde das aushalten. Stattdessen lässt das DBMS Transaktionen parallel laufen und führt nur dort Sperren oder Versionen ein, wo es zwingend nötig ist.

Die Frage ist: wie viel Konflikt-Vermeidung ist nötig? Die Antwort hängt davon ab welche Konflikte (Anomalien) auftreten können – und welche du dir leisten kannst. Für eine Likes-Tabelle einer Social-Media-App reichen lockere Garantien. Für ein Buchhaltungssystem braucht es die strengsten.

2) Die vier klassischen Anomalien

Klick eine Anomalie, um zu sehen wie sie konkret entsteht. Jede zeigt ein Zwei-Sessions-Szenario mit Zeitachse:

Die vier Anomalien interaktiv

Dirty Read

Non-Repeatable Read

Phantom Read

Lost Update

Session 1

Session 2

Beachte: alle vier Anomalien können auftreten weil zwei oder mehr Transaktionen parallel laufen. Eine einzelne Transaktion allein erzeugt keine dieser Probleme. Die Schwere reicht von „peinlich" (Dirty Read zeigt Daten, die später gar nicht gespeichert werden) bis „katastrophal" (Lost Update löscht stille Änderungen). Mehr zu echten Sperr-Konflikten, die zum Deadlock führen können, in Lektion 8.

3) Die vier Isolationsstufen im SQL-Standard

Der SQL-Standard definiert vier Isolationsstufen, die unterschiedlich viele Anomalien verhindern. Die Reihenfolge geht von locker zu streng – und parallel von schnell zu langsam:

Die vier Isolationsstufen

READ UNCOMMITTED
Schwächste Stufe. Eine Transaktion sieht auch nicht-committed Änderungen anderer. Erlaubt alle vier Anomalien.
Schnell, gefährlich. In MySQL/InnoDB unterstützt, in PostgreSQL als READ COMMITTED behandelt.
READ COMMITTED
Eine Transaktion sieht nur committed Daten anderer. Verhindert Dirty Reads. Non-Repeatable Read, Phantom Read und Lost Update bleiben möglich.
Default in PostgreSQL und Oracle. Guter Kompromiss für die meisten Webanwendungen.
REPEATABLE READ
Wenn eine Zeile innerhalb einer Transaktion zweimal gelesen wird, ist das Ergebnis identisch. Verhindert Dirty & Non-Repeatable Read. Phantom Reads bleiben (theoretisch) möglich.
Default in MySQL/InnoDB. InnoDB verhindert zusätzlich Phantom Reads per Gap-Locking.
SERIALIZABLE
Strengste Stufe. Verhält sich so als würden alle Transaktionen seriell nacheinander laufen. Verhindert alle Anomalien.
Langsam, blockiert häufig oder bricht mit Serialization-Failure ab. Nur für kritische Operationen einsetzen.

Achtung: real existierende DBMS halten sich nicht immer exakt an die Standard-Definition. PostgreSQL implementiert REPEATABLE READ via MVCC-Snapshots und verhindert dabei auch Phantom Reads (über das Standard-Verhalten hinaus). MySQL/InnoDB tut Ähnliches per Gap-Locks. Wenn du portable Code schreiben willst, verlass dich nicht auf undokumentierte „Extras" – wähle die Stufe, deren Standard-Garantie deinem Bedarf entspricht.

4) Welche Stufe verhindert welche Anomalie?

Die offizielle Matrix aus dem SQL-Standard. Sie ist die wichtigste Tabelle dieser Lektion und ein Klassiker in IHK-Prüfungen:

Isolation Level × Anomalien

Isolation Level	Dirty Read	Non-Repeatable Read	Phantom Read	Lost Update
READ UNCOMMITTED	möglich	möglich	möglich	möglich
READ COMMITTED	verhindert	möglich	möglich	möglich
REPEATABLE READ	verhindert	verhindert	möglich*	verhindert
SERIALIZABLE	verhindert	verhindert	verhindert	verhindert

* In MySQL/InnoDB & PostgreSQL verhindert REPEATABLE READ in der Praxis auch Phantom Reads. Im strikten SQL-Standard wären sie aber theoretisch möglich. Lost Update ist im Standard nicht explizit aufgeführt – wird aber praktisch ab REPEATABLE READ verhindert.

5) Wie man die Isolationsstufe setzt

Die Stufe wird pro Sitzung oder pro Transaktion gesetzt. Die SQL-Syntax ist standardisiert:

-- Für die nächste Transaktion in dieser Session
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN;
-- ... Operationen ...
COMMIT;

-- Default für die ganze Session ändern (MySQL)
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;

-- Globalen Default ändern (vorsichtig!)
SET GLOBAL TRANSACTION ISOLATION LEVEL REPEATABLE READ;

-- Aktuelle Stufe abfragen (MySQL)
SELECT @@transaction_isolation;

In Anwendungs-Code findet man das oft direkt an der Connection-Konfiguration: in JDBC connection.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_READ), in Python/SQLAlchemy engine = create_engine(..., isolation_level="REPEATABLE READ"). Die Stufe wirkt dann für alle Transaktionen, die auf dieser Connection laufen.

6) Wie verhindert das DBMS die Anomalien?

Hinter den Kulissen gibt es zwei Hauptstrategien: Sperren (Locking) und MVCC (Multi-Version Concurrency Control). Die meisten modernen DBMS nutzen eine Kombination.

Locking: Bevor eine Transaktion auf eine Zeile schreibt, holt sie sich eine exklusive Sperre. Andere Transaktionen müssen warten bis die Sperre freigegeben ist (beim COMMIT oder ROLLBACK). Beim Lesen gibt es Shared Locks, die parallel mehrere zulassen aber Schreiber blockieren.
MVCC: Statt zu sperren, hält das DBMS mehrere Versionen einer Zeile gleichzeitig. Jede Transaktion bekommt einen Snapshot der Datenbank zu ihrem Startzeitpunkt. Schreibvorgänge erzeugen neue Versionen, alte werden nicht überschrieben sondern verworfen wenn keine Transaktion sie mehr braucht. PostgreSQL ist ein Paradebeispiel für MVCC.

Vorteil MVCC: Leser blockieren keine Schreiber, Schreiber blockieren keine Leser. Das macht Lesen sehr schnell. Nachteil: Datenbank wächst kurzfristig, weil mehrere Versionen vorgehalten werden. Aufräumarbeiten (Vacuum) sind nötig.

7) Praktische Wahl der Stufe

Die ehrliche Empfehlung – aus der Praxis, nicht aus dem Lehrbuch:

READ COMMITTED ist für 90% aller Webanwendungen die richtige Wahl. PostgreSQL und Oracle nutzen sie als Default, das ist kein Zufall. Sie verhindert das Schlimmste (Dirty Reads) und ist gleichzeitig schnell genug für hohe Last.
REPEATABLE READ ist sinnvoll wenn du in einer Transaktion mehrfach dieselben Zeilen liest und dich darauf verlässt, dass sie sich nicht ändern. Berichte, Auswertungen, Konsistenzprüfungen über mehrere Tabellen.
SERIALIZABLE für hochkritische Operationen wo absolute Korrektheit wichtiger ist als Performance: Buchhaltungs-Abschlüsse, Audit-Verarbeitung, Geld-Transfers in hochskalierten Systemen. Sei bereit mit Serialization-Failures (Retry-Logik) umzugehen.
READ UNCOMMITTED – Finger weg. Außer du baust ein Read-Only-Reporting-Tool wo Konsistenz zweitrangig ist.

Eine elegante Alternative zur strengen SERIALIZABLE-Stufe ist optimistic locking auf Anwendungsebene: jede Zeile hat eine Versionsspalte, beim Update prüft die Anwendung dass die Version noch dieselbe ist (UPDATE ... WHERE id = ? AND version = ?). Wenn nicht, wurde die Zeile parallel geändert – Conflict, Retry. Das hat ähnliche Effekte wie strenge Isolation, aber bricht später und gezielter ab.

Zusammenfassung

Bei parallel laufenden Transaktionen können vier klassische Anomalien auftreten: Dirty Read (Lesen nicht-committed Daten), Non-Repeatable Read (gleiche Zeile zweimal gelesen, unterschiedliches Ergebnis), Phantom Read (neue Zeilen erscheinen beim zweiten Lesen), Lost Update (zwei parallele Updates überschreiben sich). SQL bietet vier Isolationsstufen: READ UNCOMMITTED (alles erlaubt), READ COMMITTED (kein Dirty Read), REPEATABLE READ (auch kein Non-Repeatable Read und kein Lost Update), SERIALIZABLE (alle verhindert). Setzen per SET TRANSACTION ISOLATION LEVEL …. Realisiert intern durch Locking (Sperren) und/oder MVCC (Snapshots, mehrere Versionen pro Zeile). Praxis-Tipp: READ COMMITTED reicht für die meisten Webanwendungen; SERIALIZABLE nur für kritische Operationen. Strengere Stufen = mehr Sicherheit, weniger Performance. Mehr zu Sperrkonflikten in Lektion 8 (Deadlocks).