Probleme im Mehrbenutzerbetrieb

⭐ Laut Dozent: Mehrbenutzer-Probleme + Beispiel-Schedules lesen können — Dirty Read, Lost Update, Non-repeatable & Phantom Read sicher erkennen!

Zusammenfassung

Im Mehrbenutzerbetrieb greifen mehrere Transaktionen parallel (verzahnt) auf dieselbe Datenbasis zu, wodurch ohne Synchronisation vier klassische Anomalien entstehen: Dirty Read, Non-Repeatable Read, Phantom-Problem und Lost Update. Diese Probleme verletzen das Isolations-Prinzip von ACID und führen zu inkonsistenten Zuständen. Das DBMS verhindert sie durch Synchronisationsmechanismen wie Sperren und Isolationslevel.

Kernkonzepte

Dirty Read (Schmutziges Lesen)

T2 liest einen von T1 geänderten Wert, bevor T1 endgültig festgeschrieben (commit) hat. Fällt T1 später mit abort/rollback zurück, hat T2 mit einem ungültigen Wert weitergerechnet und ggf. eigene Werte darauf basierend geschrieben. Das Ergebnis ist eine Inkonsistenz, denn der ursprüngliche Dirty-Wert existiert offiziell nie in der Datenbank. Erkennungsmerkmal in einer T1/T2-Tabelle: T2 führt read(A) aus, nachdem T1 write(A) gemacht hat, aber bevor T1 commit oder abort ausgeführt hat.

Dirty Read = Lesen von noch nicht committeten Änderungen einer anderen Transaktion.

Lost Update (Verlorengegangene Änderung)

Zwei Transaktionen lesen denselben Wert, berechnen unabhängig neue Werte und schreiben sie nacheinander zurück. Die spätere Schreiboperation überschreibt die frühere ohne sie zu berücksichtigen, sodass eine der Änderungen verloren geht. Typisches Muster: T1 read(A) - T2 read(A) - T1 write(A) - T2 write(A). Der klassische Ablauf im Skript zeigt A=10, T1 macht x:=x+5 und T2 macht x:=x+1, am Ende steht 11 statt 16, da T1s Änderung überschrieben wird.

Lost Update = Zwei write-Operationen auf demselben Datum, wobei die zweite die erste komplett auslöscht.

Non-Repeatable Read (Nicht-wiederholbares Lesen)

Innerhalb derselben Transaktion T2 wird zweimal dasselbe Objekt gelesen, liefert jedoch unterschiedliche Werte, weil eine andere Transaktion T1 zwischen den beiden Lesevorgängen den Wert geändert und committed hat. Anders als beim Dirty Read ist die Änderung von T1 hier bereits gültig, dennoch bricht die Lesekonsistenz innerhalb von T2. Beispiel: T2 macht zwei SELECT guthaben-Statements, zwischendrin führt T1 ein UPDATE Konten aus. Erkennung: gleiches SELECT in einer Transaktion, unterschiedliche Ergebnisse.

Non-Repeatable Read = Zweimal lesen, zweimal anderer Wert, weil jemand zwischendrin geschrieben hat.

Phantom-Problem (Phantom Read)

T1 führt eine mengenbasierte Abfrage aus, z.B. SELECT COUNT(*) FROM Mitarbeiter. Während T1 noch läuft, fügt T2 mit INSERT einen neuen Datensatz ein und committed. Wenn T1 dann darauf basierend weiterarbeitet (z.B. UPDATE ... SET Gehalt = Gehalt + 10000/X), rechnet T1 mit einer falschen Grundgesamtheit. Das Phantom ist der neue Satz, der plötzlich erscheint (oder verschwindet bei DELETE). Unterschied zum Non-Repeatable Read: hier verändert sich die Menge der Datensätze, nicht der Wert eines einzelnen Satzes.

Phantom = neuer Datensatz erscheint (Insert) oder verschwindet (Delete) zwischen zwei mengenbasierten Zugriffen.

Inconsistent Analysis (Inkonsistente Analyse)

Sammelbegriff für statistische bzw. aggregierende Auswertungen (z.B. Summen, Durchschnitte) einer Transaktion, während eine andere Transaktion nebenläufig Werte auf denselben Daten ändert. Das Ergebnis der Analyse ist verfälscht, obwohl jeder Einzelwert korrekt geschrieben wurde. Im DHBW-Skript unter Beispielszenarien als Statistische Datenbankoperationen genannt: Ergebnisse sind verfälscht, wenn während der Berechnung Daten geändert werden. Kann durch Phantom oder Non-Repeatable Read entstehen.

Inconsistent Analysis = Aggregation liest Teilwerte aus verschiedenen Konsistenzzuständen.

Isolation als ACID-Lösung

Isolation aus ACID besagt, dass jede Transaktion den Eindruck hat, allein auf der Datenbank zu arbeiten. Genau diese Eigenschaft wird durch die vier Anomalien verletzt. SQL definiert vier Isolationslevel: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ und SERIALIZABLE, die schrittweise mehr Probleme verhindern. SERIALIZABLE verhindert alle vier Anomalien, kostet aber Parallelität.

Isolation ist das I in ACID und der Gegenspieler zu allen Nebenläufigkeitsproblemen.

Zeitachsen-Notation T1/T2

In Klausuraufgaben werden die Probleme in einer zweispaltigen Tabelle mit T1 links und T2 rechts dargestellt, die Zeit läuft von oben nach unten. Typische Operationen: read(A,x) lädt Wert A in Variable x, write(x,A) schreibt Variable x nach A, x:=x+5 rechnet, commit und abort/rollback beenden die Transaktion. Zur Erkennung eines Problems: Sequenz der read/write-Operationen genau nachverfolgen und prüfen, wer wann welchen Wert sieht und schreibt.

read/write auf denselben Daten in verzahnter Reihenfolge - dann Muster gegen die vier Anomalien prüfen.

Wichtige Details

Die vier klassischen Probleme laut Skript: (1) Dirty Read, (2) Non-Repeatable Read, (3) Phantom-Problem, (4) Lost Update.
Dirty Read setzt zwingend einen abort/rollback von T1 nach dem write voraus, damit die Inkonsistenz sichtbar wird - ohne rollback wäre es nur ein normaler Lesevorgang.
Lost Update erkennt man an zwei read(A) gefolgt von zwei write(A) ohne dazwischen liegende Synchronisation.
Non-Repeatable Read betrifft denselben Datensatz mit verändertem Wert; Phantom betrifft die Anzahl bzw. Menge der Datensätze.
Phantom entsteht durch INSERT oder DELETE einer Fremd-Transaktion, nicht durch UPDATE.
Isolationslevel READ UNCOMMITTED erlaubt Dirty Read; READ COMMITTED verhindert Dirty Read; REPEATABLE READ verhindert zusätzlich Non-Repeatable Read; SERIALIZABLE verhindert auch Phantoms.
Notation im Skript: read(A,x) bedeutet lese Datenobjekt A in lokale Variable x; write(x,A) schreibt Variable x zurück nach A.
Bankkonto-Beispiel: read(A,a); a:=a-50; write(A,a); read(B,b); b:=b+50; write(B,b) - klassische Überweisung, sechs Schritte.
Das Platzbuchungs-Beispiel (Flug/Reisebüro) illustriert das grundsätzliche Problem der Nebenläufigkeit ohne Synchronisation.
Lösung aller Probleme: Transaktionen mit BOT, commit/rollback und Sperrprotokolle (Locking) im DBMS.
Konsistenz der Datenbank ist umso aufwändiger zu wahren, je mehr Redundanz die Datenbank enthält.
Mehrbenutzerbetrieb bedingt Konsistenz - Transaktionen kapseln Benutzer gegeneinander ab.

Beispiele

Dirty Read - Ablauf aus dem Skript

T2 liest den von T1 geschriebenen A-Wert, T1 macht danach abort. T2 rechnet mit ungültigem Wert weiter und schreibt B falsch.

T1: read(A,x); x:=x+100; write(x,A); ... ; abort
T2:                                     read(A,x); read(B,y); y:=y+x; write(y,B); commit
Problem: T2 hat den nicht-committeten Wert von A gelesen und B damit verfaelscht - Inkonsistenz.

Lost Update - Ablauf aus dem Skript mit A=10

Beide Transaktionen lesen A=10, T1 addiert 5, T2 addiert 1. T1 schreibt 15, danach überschreibt T2 mit 11. Die +5 sind verloren.

T1: read(A,x)          -> x=10
T2:              read(A,x)  -> x=10
T1: x:=x+5
T2:              x:=x+1
T1: write(x,A)         -> A=15
T2:              write(x,A) -> A=11
Erwartet waere A=16, tatsaechlich A=11.

Non-Repeatable Read - Kontostand-Beispiel

T2 fragt zweimal denselben Kontostand ab; T1 updated dazwischen. Zwei identische SELECTs liefern unterschiedliche Werte.

T2: SELECT guthaben FROM Konten WHERE iban=4711;
T1: UPDATE Konten SET guthaben=guthaben+100 WHERE iban=4711; commit;
T2: SELECT guthaben FROM Konten WHERE iban=4711;
-> zweites SELECT liefert um 100 hoeheren Wert.

Phantom-Problem - Gehaltsaufteilung

T1 zählt Mitarbeiter (X), T2 fügt neuen Mitarbeiter ein und committed, T1 verteilt Bonus mit falschem X.

T1: SELECT COUNT(*) INTO X FROM Mitarbeiter;
T2:                                        INSERT INTO Mitarbeiter VALUES ('Meier',50000,...); COMMIT;
T1: UPDATE Mitarbeiter SET Gehalt=Gehalt+10000/X; COMMIT;
Der Phantom-Mitarbeiter Meier bekommt Bonusanteil, war aber nicht in X mitgezaehlt.

Visualisierung der vier Anomalien

FAQ

Was ist der Unterschied zwischen Dirty Read und Non-Repeatable Read?

Dirty Read liest einen noch nicht committeten Wert (T1 macht evtl. rollback). Non-Repeatable Read liest zweimal, dazwischen committed eine andere Transaktion. Beim Non-Repeatable Read ist der neue Wert also bereits gültig.

Wodurch unterscheidet sich das Phantom-Problem vom Non-Repeatable Read?

Non-Repeatable Read betrifft den Wert eines bereits gelesenen Satzes (UPDATE). Phantom betrifft die Menge der Sätze - ein neuer Satz erscheint (INSERT) oder verschwindet (DELETE) zwischen zwei mengenbasierten Abfragen.

Wie erkenne ich Lost Update in einer T1/T2-Tabelle?

Muster: T1 read(A) -> T2 read(A) -> T1 write(A) -> T2 write(A). Beide lesen den alten Wert, beide schreiben, die zweite Schreiboperation überschreibt die erste vollständig.

Welches ACID-Prinzip wird durch die vier Probleme verletzt?

Isolation (das I in ACID). Transaktionen sollen den Eindruck haben, allein zu arbeiten - genau das ist bei diesen Anomalien nicht mehr gegeben.

Wie löst das DBMS diese Probleme?

Durch Synchronisationsmechanismen wie Sperrprotokolle (Locking) und Isolationslevel (READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE). SERIALIZABLE verhindert alle vier Anomalien.

Was bedeutet Inconsistent Analysis?

Eine Transaktion führt eine Auswertung (SUM, AVG, COUNT) aus, während eine andere Transaktion die zugrunde liegenden Daten ändert. Die Aggregation basiert dann auf einer Mischung aus altem und neuem Zustand.

Muss beim Dirty Read T1 zwingend abbrechen?

Damit die Inkonsistenz sichtbar wird, ja - im Skript ist genau das das Problem: T2 rechnet mit dem A-Wert weiter, obwohl T1 danach abort ausführt und der Wert nie gültig war.

Warum sind statistische Berechnungen besonders anfällig?

Weil sie viele Datensätze lesen. Während die Berechnung läuft, kann eine andere Transaktion einzelne Werte ändern oder neue Sätze einfügen, sodass das Aggregat inkonsistent wird.

Prüfungsfragen

0 von 12 beantwortet