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).
Teil 1·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?
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.
Anmelden, um den Fortschritt zu speichern.
Nächster Schritt
Aktives Abrufen festigt Wissen schneller als nochmal lesen.
Diese Lerneinheit wurde für typische Bachelor-Klausuren konzipiert. So prüfen wir · Fehler entdeckt? Melde ihn uns oder markiere die fragliche Stelle direkt im Text oben.
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).
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?
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.
Drei aus Welle 8.4 plus eine neue:
Eine Transaktion liest einen Wert, der noch nicht committed wurde. Wenn der Schreiber zurückrollt, hat der Leser einen "schmutzigen" Wert.
Eine Transaktion liest denselben Wert zweimal und bekommt verschiedene Ergebnisse, weil zwischen den Lesezugriffen jemand committet hat.
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.
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.
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.
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.
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.
| 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 |
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.
- 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.
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.
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.
Sechs Aufgaben zu den 4 Levels und 3 Anomalien.
Klausurfragen mit Lösungen (6)
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).
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.
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.
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.
Zuordnungen:
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
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
Klausurfragen mit Lösungen (6)
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).
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.
Richtige Reihenfolge:
Erklärung: Standard-SQL-92-Reihenfolge. Mit jedem Schritt nach oben kommt eine Anomalie-Verhinderung dazu: Read Uncommitted → +DirtyRead → +NonRepeatable → +Phantom.
Typ: Reihenfolge
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.
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
Lösungen pro Lücke:
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