Probleme im Mehrbenutzerbetrieb

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 fuehren zu inkonsistenten Zustaenden. Das DBMS verhindert sie durch Synchronisationsmechanismen wie Sperren und Isolationslevel.

Kernkonzepte

Dirty Read (Schmutziges Lesen)

T2 liest einen von T1 geaenderten Wert, bevor T1 endgueltig festgeschrieben (commit) hat. Faellt T1 spaeter mit abort/rollback zurueck, hat T2 mit einem ungueltigen Wert weitergerechnet und ggf. eigene Werte darauf basierend geschrieben. Das Ergebnis ist eine Inkonsistenz, denn der ursprungliche Dirty-Wert existiert offiziell nie in der Datenbank. Erkennungsmerkmal in einer T1/T2-Tabelle: T2 fuehrt read(A) aus, nachdem T1 write(A) gemacht hat, aber bevor T1 commit oder abort ausgefuehrt hat.

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

Lost Update (Verlorengegangene Aenderung)

Zwei Transaktionen lesen denselben Wert, berechnen unabhaengig neue Werte und schreiben sie nacheinander zurueck. Die spaetere Schreiboperation ueberschreibt die fruehere ohne sie zu beruecksichtigen, sodass eine der Aenderungen 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 Aenderung ueberschrieben wird.

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

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 Lesevorgaengen den Wert geaendert und committed hat. Anders als beim Dirty Read ist die Aenderung von T1 hier bereits gueltig, dennoch bricht die Lesekonsistenz innerhalb von T2. Beispiel: T2 macht zwei SELECT guthaben-Statements, zwischendrin fuehrt 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 fuehrt eine mengenbasierte Abfrage aus, z.B. SELECT COUNT(*) FROM Mitarbeiter. Waehrend T1 noch laeuft, fuegt 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 pluetzlich erscheint (oder verschwindet bei DELETE). Unterschied zum Non-Repeatable Read: hier veraendert sich die Menge der Datensaetze, nicht der Wert eines einzelnen Satzes.

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

Inconsistent Analysis (Inkonsistente Analyse)

Sammelbegriff fuer statistische bzw. aggregierende Auswertungen (z.B. Summen, Durchschnitte) einer Transaktion, waehrend eine andere Transaktion nebenlaeufig Werte auf denselben Daten aendert. Das Ergebnis der Analyse ist verfaelscht, obwohl jeder Einzelwert korrekt geschrieben wurde. Im DHBW-Skript unter Beispielszenarien als Statistische Datenbankoperationen genannt: Ergebnisse sind verfaelscht, wenn waehrend der Berechnung Daten geaendert werden. Kann durch Phantom oder Non-Repeatable Read entstehen.

Inconsistent Analysis = Aggregation liest Teilwerte aus verschiedenen Konsistenzzustaenden.

Isolation als ACID-Loesung

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 Parallelitaet.

Isolation ist das I in ACID und der Gegenspieler zu allen Nebenlaeufigkeitsproblemen.

Zeitachsen-Notation T1/T2

In Klausuraufgaben werden die Probleme in einer zweispaltigen Tabelle mit T1 links und T2 rechts dargestellt, die Zeit laeuft von oben nach unten. Typische Operationen: read(A,x) laedt 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 pruefen, wer wann welchen Wert sieht und schreibt.

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

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 waere 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 veraendertem Wert; Phantom betrifft die Anzahl bzw. Menge der Datensaetze.
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 zusaetzlich 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 zurueck nach A.
Bankkonto-Beispiel: read(A,a); a:=a-50; write(A,a); read(B,b); b:=b+50; write(B,b) - klassische Ueberweisung, sechs Schritte.
Das Platzbuchungs-Beispiel (Flug/Reisebuero) illustriert das grundsaetzliche Problem der Nebenlaeufigkeit ohne Synchronisation.
Loesung aller Probleme: Transaktionen mit BOT, commit/rollback und Sperrprotokolle (Locking) im DBMS.
Konsistenz der Datenbank ist umso aufwaendiger zu wahren, je mehr Redundanz die Datenbank enthaelt.
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 ungueltigem 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 ueberschreibt 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 zaehlt Mitarbeiter (X), T2 fuegt 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 gueltig.

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 Saetze - 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 ueberschreibt die erste vollstaendig.

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 loest 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 fuehrt eine Auswertung (SUM, AVG, COUNT) aus, waehrend eine andere Transaktion die zugrunde liegenden Daten aendert. 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 ausfuehrt und der Wert nie gueltig war.

Warum sind statistische Berechnungen besonders anfaellig?

Weil sie viele Datensaetze lesen. Waehrend die Berechnung laeuft, kann eine andere Transaktion einzelne Werte aendern oder neue Saetze einfuegen, sodass das Aggregat inkonsistent wird.

Pruefungsfragen

0 von 12 beantwortet