Statt Datensaetze direkt zu aendern legt das DBMS bei jedem Write eine neue Version des Datenobjekts an. Jedes logische Objekt existiert also physisch in mehreren Versionen gleichzeitig. Ein Lesen greift immer auf die Version zu, die zu Beginn der eigenen Transaktion gueltig war. Damit blockieren sich Leser und Schreiber nie gegenseitig.
Snapshot Isolation ist die Isolationsstufe, die MVCC praktisch umsetzt. Zu Beginn einer Transaktion bekommt diese einen logischen Zeitstempel, ihren Snapshot. Alle Lesevorgaenge sehen den Datenbankzustand exakt so, wie er zu diesem Zeitstempel committed war. Snapshot Isolation ist NICHT identisch zu Serializable, das write-skew Problem kann noch auftreten.
Jede physische Version einer Zeile bekommt zwei Zeitstempel: begin-ts markiert, ab wann sie sichtbar wird, end-ts markiert, ab wann sie durch eine neuere Version abgeloest ist. Eine Transaktion T mit Zeitstempel ts sieht genau die Version, fuer die gilt begin-ts <= ts und (end-ts unbekannt oder end-ts > ts).
Der praktische Kernvorteil von MVCC gegenueber 2PL: Lesetransaktionen brauchen keine Sperre. Auch waehrend ein Schreiber eine Zeile modifiziert, sehen andere Transaktionen ungestoert die alte Version. In OLTP-Systemen und bei Reporting-Queries neben laufendem Tagesgeschaeft ist das der entscheidende Durchsatz-Vorteil.
Postgres implementiert MVCC direkt in den Heap-Tuples: jede Zeile hat xmin und xmax als versteckte Systemspalten. Updates erzeugen physisch eine neue Zeile, alte Zeilen werden spaeter durch VACUUM aufgeraeumt. Oracle nutzt stattdessen Undo-Segmente: alte Werte landen im Rollback-Segment, aus dem Leser bei Bedarf die passende alte Version rekonstruieren.
MVCC ist mehr als ein Sperr-Protokoll und wirkt sich auf mehrere Komponenten aus: Concurrency Control Protocol, Version Storage, Garbage Collection, Index Management und Deletes (loeschen bedeutet eine Version mit end-ts markieren, nicht physisch entfernen). Ein Umstieg auf MVCC kann nicht rueckwirkend gemacht werden.
Beim Two-Phase-Locking fordern Transaktionen S- und X-Sperren an. Sperren sind pessimistisch: sie verhindern Konflikte durch Blockieren, koennen aber zu Deadlocks fuehren. MVCC ist demgegenueber optimistisch fuer Reads: statt zu sperren wird eine neue Version angelegt. Write-Write-Konflikte muessen aber weiterhin erkannt werden.
Klassisches Beispiel aus der Vorlesung: T1 liest A waehrend T2 A parallel aendert. Beide blockieren sich nicht.
Zustand: A0 (begin-ts=0, end-ts=inf, value=123)
Historie:
T1: BEGIN (ts=1)
T1: R(A) -> liest A0 = 123
T2: BEGIN (ts=2)
T2: W(A) -> DBMS erzeugt neue Version A1 (begin-ts=2, value=456)
alte Version A0 bekommt end-ts=2
T1: R(A) -> liest weiterhin A0 = 123 (Snapshot bei ts=1)
T1: COMMIT
T2: COMMIT
Ergebnis Datenbanktabelle:
A0: begin-ts=0, end-ts=2, value=123
A1: begin-ts=2, end-ts=-, value=456
=> T1 blockiert nicht, sieht konsistenten Snapshot
T1 fuehrt Ueberweisung durch, T2 macht parallel Bilanzsumme. Bei 2PL wuerde T2 warten, mit MVCC liest T2 einen konsistenten Snapshot.
T1 (Ueberweisung 50 von A nach B) T2 (Reporting: Sum(A)+Sum(B))
BEGIN ts=10 BEGIN ts=11
read(A) -> 1000
A := A - 50
write(A) -> neue Version A_v11=950
read(A) -> sieht alte Version=1000
read(B) -> sieht alte Version=500
read(B) -> 500 Summe=1500 (konsistent zum Zeitpunkt ts=11)
B := B + 50 COMMIT
write(B) -> neue Version B_v12=550
COMMIT
=> Keine Sperren, keine Wartezeit, T2 sieht konsistenten Zustand vor der Ueberweisung.
Unter 2PL waere in Read Committed ein Nonrepeatable Read moeglich. Mit MVCC/Snapshot Isolation wird dies verhindert.
T1 (Kontostand lesen) T2 (Update)
BEGIN (Snapshot bei ts=5)
SELECT guthaben FROM Konten
WHERE iban=4711 -> 1000
BEGIN
UPDATE Konten SET guthaben=guthaben+100
WHERE iban=4711
COMMIT (neue Version bei ts=8)
SELECT guthaben FROM Konten
WHERE iban=4711 -> immer noch 1000
(liest weiter die Version, die bei ts=5 gueltig war)
COMMIT
=> Repeatable Read wird durch MVCC automatisch erreicht.
Anschauliches Verhalten in konkreten DBMS. In Postgres ist Read Committed Default und funktioniert komplett ueber MVCC.
Postgres Session 1: Postgres Session 2:
BEGIN;
SELECT balance FROM konto
WHERE id=1; -- 100
BEGIN;
UPDATE konto SET balance=200
WHERE id=1;
-- kein Blockieren fuer Leser
SELECT balance FROM konto
WHERE id=1; -- 100 (Session 1 wartet NICHT)
COMMIT;
SELECT balance FROM konto
WHERE id=1; -- unter READ COMMITTED: 200
-- unter REPEATABLE READ: 100
COMMIT;