Alle Tabs der Lerneinheit (Erklärung · Matrix · Praxis-Übung · Klausur-Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur, und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).
Erklärung
Strenge Isolation = sicher, aber langsam. Lockere Isolation = schnell, aber riskant. Der Isolation Level ist der Knopf, mit dem du diese Trade-off-Achse einstellst. SQL-Standard definiert 4 Stufen, von "alles erlaubt" bis "wie nacheinander". Klausur-Pflicht: welcher Level verhindert welche Anomalie?
Die 4 Isolation Levels (SQL-92)
Von schwächster (1) bis stärkster (4):
| # | Level | Dirty Read | Non-Repeatable Read | Phantom Read |
|---|---|---|---|---|
| 1 | Read Uncommitted | ✗ erlaubt | ✗ erlaubt | ✗ erlaubt |
| 2 | Read Committed | ✓ verhindert | ✗ erlaubt | ✗ erlaubt |
| 3 | Repeatable Read | ✓ verhindert | ✓ verhindert | ✗ erlaubt |
| 4 | Serializable | ✓ verhindert | ✓ verhindert | ✓ verhindert |
(Lost Update wird in den meisten DBs zusätzlich behandelt, kein Standard-Anomalie-Test.)
Klausur-Trick: je höher der Level, desto mehr Anomalien verhindert, aber desto mehr Performance-Kosten durch Sperren / Versionierung.
Was sind die Anomalien?
Drei aus Welle 8.4 plus eine neue:
1. Dirty Read
Eine Transaktion liest einen Wert, der noch nicht committed wurde. Wenn der Schreiber zurückrollt, hat der Leser einen "schmutzigen" Wert.
2. Non-Repeatable Read
Eine Transaktion liest denselben Wert zweimal und bekommt verschiedene Ergebnisse, weil zwischen den Lesezugriffen jemand committet hat.
3. Phantom Read (neu)
Eine Transaktion führt zweimal denselben Range-Query aus (z.B. SELECT WHERE Note < 2,0) und bekommt unterschiedliche Mengen zurück, weil eine andere Transaktion zwischendurch Zeilen eingefügt hat, die jetzt in den Range passen.
T1: SELECT COUNT(*) WHERE Note < 2,0 → 5
T2: INSERT (..., 1.7), COMMIT
T1: SELECT COUNT(*) WHERE Note < 2,0 → 6 ← Phantom!
Unterschied zu Non-Repeatable Read: Non-Repeatable Read = bestehende Zeile ändert sich. Phantom Read = neue Zeilen tauchen auf.
Die 4 Levels im Detail
1. Read Uncommitted
Eine Transaktion darf alles lesen, auch noch nicht committete Schreibvorgänge.
Wann sinnvoll: Reporting-Queries auf großen Datenmengen, wo es nicht auf 100 % Genauigkeit ankommt (z.B. "wie viele User sind ungefähr online?"). Sehr schnell, weil keine Sperren beim Lesen.
Beispiel-Anomalie: Dirty Read voll erlaubt.
2. Read Committed (Default in vielen DBs, z.B. PostgreSQL, Oracle)
Eine Transaktion sieht nur committed Daten. Verhindert Dirty Read.
Wie? Beim Lesen wird die letzte committete Version geliefert. Schreibsperren bleiben bis COMMIT.
Beispiel-Anomalie: Non-Repeatable Read noch möglich, wenn T1 zweimal liest und T2 dazwischen committet, sieht T1 zwei verschiedene Werte.
3. Repeatable Read
Eine Transaktion sieht über ihre gesamte Laufzeit den gleichen Stand der gelesenen Zeilen.
Wie? Beim ersten Lesen wird die Version "eingefroren" (in MVCC: Snapshot). Spätere Reads in derselben Transaktion sehen dieselben Werte, auch wenn andere committen.
Beispiel-Anomalie: Phantom Read möglich, neue Zeilen können dazukommen, weil nur gelesene Werte eingefroren sind, nicht das ganze Schema.
4. Serializable (strengster Level)
Es ist als wären alle Transaktionen streng nacheinander ausgeführt worden.
Wie? Range-Locks oder Serializable Snapshot Isolation (SSI). Sehr teuer.
Beispiel-Anomalie: Alle drei verhindert. Aber: viele Transaktionen werden bei Konflikten abgebrochen und müssen neu gestartet werden.
Wann welcher Level?
| Anwendung | Empfohlener Level |
|---|---|
| Banking, Abrechnung, Buchungen | Serializable oder Repeatable Read |
| Klassisches OLTP (CRUD) | Read Committed (Standard) |
| Reporting, Dashboards | Read Uncommitted oder Read Committed |
| Hochfrequenz-Schreibung (z.B. Logging) | Read Committed mit optimistischen Updates |
Visualisierung
Klicke auf eine Zelle in der Matrix, um eine konkrete Szenario-Animation zu sehen:
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
Klausur-Faustregeln
- 4 Levels auswendig, in der Reihenfolge der Stärke: Read Uncommitted → Read Committed → Repeatable Read → Serializable.
- 3 Anomalien auswendig: Dirty Read, Non-Repeatable Read, Phantom Read.
- Matrix-Frage: "Welcher Level verhindert Anomalie X?" → finde den ersten Level (von oben), der X verhindert.
- Default ist Read Committed in PostgreSQL/Oracle. SQL-Server: Read Committed. MySQL InnoDB: Repeatable Read.
- Stärkster Level = langsam. Serializable kommt mit hohem Lock-/Abort-Overhead. Nur einsetzen, wenn nötig.
Typische Stolpersteine
1. Phantom Read mit Non-Repeatable Read verwechseln. Beide ähneln sich, aber: Non-Repeatable Read = einzelne Zeile ändert sich. Phantom Read = neue Zeilen tauchen in einem Range auf.
2. Read Committed verhindert Lost Update, falsch. Lost Update ist eine andere Anomalie, die meistens durch zusätzliche Mechanismen (SELECT ... FOR UPDATE, optimistic locking) verhindert wird, nicht durch den Standard-Isolation-Level.
3. MVCC vs. Locking. Modern DBs implementieren Isolation meist über MVCC (Multi-Version Concurrency Control) statt klassischer Sperren. Effekt ist derselbe, aber Performance besser.
4. Serializable ≠ "physisch nacheinander". Es heißt nur: das Ergebnis muss aussehen, als wäre es eine serielle Ausführung gewesen. Intern können die Transaktionen parallel laufen, solange das Resultat dem entspricht.
Matrix
Isolation-Level-Matrix
Klicke eine Zelle (Level × Anomalie), um zu sehen, ob die Anomalie in diesem Level auftreten kann, und welcher Klausur-Standardablauf das illustriert.
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
Klausur-Tipp: Bei "Welcher Level reicht für X?", wähle den niedrigsten Level, der X verhindert. Höhere Levels haben unnötigen Performance-Aufwand.
Praxis-Übung
Isolation Levels, Praxis-Übung
Sechs Aufgaben zu den 4 Levels und 3 Anomalien.
Klausurfragen mit Lösungen (6)
- F1.Welcher Isolation Level erlaubt Dirty Reads?
Antwort: Read Uncommitted
Erklärung: Read Uncommitted ist der schwächste Level, Dirty Read, Non-Repeatable Read und Phantom Read sind alle erlaubt. Sehr selten in Praxis nützlich (vielleicht für rasche Reports).
- F2.Welcher Level ist der STRENGSTE?
Antwort: Serializable
Erklärung: Serializable garantiert: die Transaktionen sehen aus als wären sie nacheinander ausgeführt worden. Verhindert alle drei klassischen Anomalien, aber teuer durch Range-Locks oder Abbrüche.
- F3.PostgreSQL Default Isolation Level ist:
Antwort: Read Committed
Erklärung: Read Committed ist Standard in PostgreSQL, Oracle und SQL Server. MySQL InnoDB ist anders: Repeatable Read als Default. Bei DB-Tools immer prüfen.
- F4.Wenn T1 SELECT * FROM Kurse WHERE Note < 2.0 zweimal ausführt und beim zweiten Mal eine zusätzliche Zeile zurückbekommt, welche Anomalie?
Antwort: Phantom Read
Erklärung: Phantom Read: eine zusätzliche Zeile taucht in einem Range-Query auf. Verhindert NUR durch Serializable. Repeatable Read würde die bereits gelesenen Zeilen einfrieren, aber neue Inserts in den Range nicht blockieren.
- F5.Ordne die Level der Anomalie-Verhinderung zu:
Zuordnungen:
- Read Uncommitted → verhindert NICHTS
- Read Committed → verhindert NUR Dirty Read
- Repeatable Read → verhindert Dirty + Non-Repeatable
- Serializable → verhindert ALLE Anomalien
Erklärung: Standard-Matrix. Jeder höhere Level fügt die Verhinderung der nächsten Anomalie hinzu. Merke: Phantom Read braucht den STRENGSTEN Level.
Typ: Zuordnung
- F6.Serializable garantiert, dass alle Transaktionen physisch sequenziell ausgeführt werden.
Antwort: Falsch
Erklärung: FALSCH. Serializable garantiert nur, dass das Endergebnis dasselbe ist, als wären sie sequenziell gewesen. Intern können sie parallel laufen, solange keine Konflikte entstehen. Wenn doch, wird eine abgebrochen.
Typ: Wahr/Falsch
Klausur-Quiz
Klausurfragen mit Lösungen (6)
- F1.Eine Banking-App will Lost Update sicher verhindern. Welche Strategie ist KORREKT?
Antwort: SELECT ... FOR UPDATE explizit nutzen (Pessimistic Lock)
Erklärung: Lost Update ist keine Standard-Isolation-Anomalie und wird unterschiedlich behandelt. Saubere Lösung: SELECT ... FOR UPDATE (sperrt die Zeile für Schreibzugriff, andere müssen warten). Alternative: Version-Counter + UPDATE ... WHERE version=X (Optimistic Locking).
- F2.Welche Anomalien sind in Repeatable Read NOCH möglich?
Antwort: Nur Phantom Read
Erklärung: Repeatable Read verhindert Dirty Read und Non-Repeatable Read. Phantom Read ist noch möglich, weil neue Zeilen (Inserts in einen Range) nicht von 'eingefrorenen' bestehenden Zeilen erfasst werden.
- F3.Sortiere die Isolation Levels von SCHWÄCHSTEM (am meisten Anomalien erlaubt) zu STRENGSTEM:
Richtige Reihenfolge:
- Read Uncommitted
- Read Committed
- Repeatable Read
- Serializable
Erklärung: Standard-SQL-92-Reihenfolge. Mit jedem Schritt nach oben kommt eine Anomalie-Verhinderung dazu: Read Uncommitted → +DirtyRead → +NonRepeatable → +Phantom.
Typ: Reihenfolge
- F4.Welche Implementation realisiert Repeatable Read in modernen DBs (PostgreSQL, MySQL InnoDB)?
Antwort: MVCC mit Snapshot beim Transaction-Start
Erklärung: MVCC (Multi-Version Concurrency Control): jede Transaktion bekommt einen 'Snapshot' der DB beim Start. Spätere Reads sehen dieselbe Version, auch wenn andere committen. Performance besser als Sperren, weil keine wartenden Transaktionen.
- F5.Phantom Read kann durch Repeatable Read mit MVCC verhindert werden.
Antwort: Falsch
Erklärung: FALSCH per SQL-92-Standard. Aber: PostgreSQL und MySQL InnoDB verhindern Phantom Read tatsächlich schon im Repeatable Read (durch erweiterte MVCC-Implementation). SQL-Standard sagt: nur Serializable. In der Klausur folge dem Standard.
Typ: Wahr/Falsch
- F6.Der niedrigste Level ist {{1}}, der höchste ist {{2}}. PostgreSQL Default ist {{3}}.
Lösungen pro Lücke:
- {{1}}: Read Uncommitted
- {{2}}: Serializable
- {{3}}: Read Committed
Erklärung: Auswendig-Fakten für die Klausur. Read Uncommitted ist schwächster, Serializable stärkster. PG/Oracle/MSSQL nutzen Read Committed als Default; MySQL InnoDB ist Repeatable Read.
Typ: Lückentext
