Statt Datensätze direkt zu ändern 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 gültig 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 Lesevorgänge 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 abgelöst ist. Eine Transaktion T mit Zeitstempel ts sieht genau die Version, für die gilt begin-ts <= ts und (end-ts unbekannt oder end-ts > ts).
Der praktische Kernvorteil von MVCC gegenüber 2PL: Lesetransaktionen brauchen keine Sperre. Auch während ein Schreiber eine Zeile modifiziert, sehen andere Transaktionen ungestört die alte Version. In OLTP-Systemen und bei Reporting-Queries neben laufendem Tagesgeschäft 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 später durch VACUUM aufgeräumt. 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 (löschen bedeutet eine Version mit end-ts markieren, nicht physisch entfernen). Ein Umstieg auf MVCC kann nicht rückwirkend gemacht werden.
Beim Two-Phase-Locking fordern Transaktionen S- und X-Sperren an. Sperren sind pessimistisch: sie verhindern Konflikte durch Blockieren, können aber zu Deadlocks führen. MVCC ist demgegenüber optimistisch für Reads: statt zu sperren wird eine neue Version angelegt. Write-Write-Konflikte müssen aber weiterhin erkannt werden.
Klassisches Beispiel aus der Vorlesung: T1 liest A während T2 A parallel ändert. 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 führt Überweisung durch, T2 macht parallel Bilanzsumme. Bei 2PL würde T2 warten, mit MVCC liest T2 einen konsistenten Snapshot.
T1 (Überweisung 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 Überweisung.
Unter 2PL wäre in Read Committed ein Nonrepeatable Read möglich. 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 gültig war)
COMMIT
=> Repeatable Read wird durch MVCC automatisch erreicht.
Anschauliches Verhalten in konkreten DBMS. In Postgres ist Read Committed Default und funktioniert komplett über 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 für 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;