Transaktionsverwaltung Beispiel einer typischen Transaktion in einer Bankanwendung: 1.Lese den Kontostand von A in die Variable a: read(A,a); 2.Reduziere den Kontostand um 50.- CHF: a:= a – 50; 3.Schreibe den neuen Kontostand in die Datenbasis: write(A,a); 4.Lese den Kontostand von B in die Variable b: read(B,b); 5.Erhöhe den Kontostand um 50,- CHF: b := b + 50; 6.Schreibe den neuen Kontostand in die Datenbasis: write(B, b);

Eigenschaften von Transaktionen: ACID  Atomicity (Atomarität)  Alles oder nichts  Undo bei Problemen  Consistency  Konsistenter Zustand der DB  k. Zustand  Überprüfe Integritätsbedingungen am Ende  Isolation  Jede Transaktion hat die DB „für sich allein“  Synchronisation von nebenläufigen Transaktionen  Durability (Dauerhaftigkeit)  Änderungen dürfen nie verloren gehen  Redo bei Problemen (z.B. Erdbeben)

Eigenschaften von Transaktionen Abb.: Transaktionsbeginn und –ende relativ zu einem Systemabsturz Zeitachse T2T2 T1T1 t1t1 t2t2 t3t3 Absturz

Operationen auf Transaktions-Ebene  begin of transaction (BOT): Mit diesem Befehl wird der Beginn einer eine Transaktion darstellende Befehlsfolge gekennzeichnet.  commit: Hierdurch wird die Beendigung der Transaktion eingeleitet. Alle Änderungen der Datenbasis werden durch diesen Befehl festgeschrieben, d.h. sie werden dauerhaft in die Datenbank eingebaut.  abort: Dieser Befehl führt zu einem Selbstabbruch der Transaktion. Das Datenbanksystem muss sicherstellen, dass die Datenbasis wieder in den Zustand zurückgesetzt wird, der vor Beginn der Transaktionsausführung existierte. In den klassischen Transaktionssystemen:

Erweiterte Operationen auf Transaktions-Ebene  define savepoint: Hierdurch wird ein Sicherungspunkt definiert, auf den sich die (noch aktive) Transaktion zurücksetzen lässt. Das DBMS muss sich dazu alle bis zu diesem Zeitpunkt ausgeführten Änderungen an der Datenbasis „merken“. Diese Änderungen dürfen aber noch nicht in der Datenbasis festgeschrieben werden, da die Transaktion durch ein abort immer noch gänzlich aufgegeben werden kann  backup transaction: Dieser Befehl dient dazu, die noch aktive Transaktion auf den jüngsten – also den zuletzt angelegten – Sicherungspunkt zurückzusetzen. Es hängt von der Funktionalität des Systems ab, ob auch ein Rücksetzen auf weiter zurückliegende Sicherungspunkte möglich ist. Um diese Funktionalität zu realisieren, benötigt man selbstverständlich entsprechend mehr Speicherkapazität, um die Zustände mehrerer Sicherungspunkte temporär abzuspeichern – oder wie wir in Kapitel 10 sehen werden, mehr Zeit, um die ausgeführten Operationen rückgängig zu machen. Zusätzlich in neuen Datenbankanwendungen:

Abschluss einer Transaktion Für den Abschluss einer Transaktion gibt es zwei Möglichkeiten: 1.Den erfolgreichen Abschluss durch ein commit. 2.Den erfolglosen Abschluss durch ein abort.

Transaktionsverwaltung in SQL  commit work: Die in der Transaktion vollzogenen Änderungen werden – falls keine Konsistenzverletzung oder andere Probleme aufgedeckt werden – festgeschrieben. Das Schlüsselwort work ist optional, d.h. das Transaktionsende kann auch einfach mit commit „befohlen“ werden.  rollback work: Alle Änderungen sollen zurückgesetzt werden. Anders als der commit-Befehl muss das DBMS die „erfolgreiche“ Ausführung eines rollback-Befehls immer garantieren können.

Transaktionsverwaltung in SQL Beispielsequenz auf Basis des Universitätsschemas: insert into Vorlesungen values (5275, `Kernphysik`, 3, 2141); insert into Professoren values (2141, `Meitner`, `C4`, 205); commit work

Zustandsübergangs-Diagramm für Transaktionen potentiellaktivwartend gescheitert aufgegeben wiederholbar abgeschlossen persistent einbringen verdrängen beenden inkarnieren abbrechen festschreiben neustarten abbrechen zurücksetzten

Fehlerbehandlung (Recovery) 1.Lokaler Fehler in einer noch nicht festgeschriebenen (committed) Transaktion  Wirkung muss zurückgesetzt werden  R1-Recovery 2.Fehler mit Hauptspeicherverlust  Abgeschlossene TAs müssen erhalten bleiben (R2-Recovery)  Noch nicht abgeschlossene TAs müssen zurückgesetzt werden (R3-Recovery) 3.Fehler mit Hintergrundspeicherverlust  R4-Recovery Fehlerklassifikation

Mehrbenutzersynchronisation Ausführung der drei Transaktionen T 1, T 2 und T 3 : (a) im Einzelbetrieb und (b) im (verzahnten) Mehrbenutzerbetrieb (gestrichelte Linien repräsentieren Wartezeiten) Zeitachse T1T1 T2T2 T3T3 T1T1 T2T2 T3T3

Fehler bei unkontrolliertem Mehrbenutzerbetrieb I Verlorengegangene Änderungen (lost update) write(A,a 2 ) a 2 := a 2 * 1.03 read(A,a 2 ) T2T2 write(B,b 1 ) b 1 := b read(B,b 1 ) write(A,a 1 ) a 1 := a 1 – 300 read(A,a 1 ) T1T Schritt

Fehler bei unkontrolliertem Mehrbenutzerbetrieb II Abhängigkeit von nicht freigegebenen Änderungen read(A,a 1 )write(A,a 2 ) a 2 := a 2 * 1.03 read(A,a 2 ) T2T2 abort... read(B,b 1 ) write(A,a 1 ) a 1 := a 1 – 300 T1T Schritt

Fehler bei unkontrolliertem Mehrbenutzerbetrieb III Phantomproblem T1T1 T2T2 select sum(KontoStand) from Konten insert into Konten values (C,1000,...) select sum(Kontostand) from Konten

Serialisierbarkeit  Historie ist „äquivalent“ zu einer seriellen Historie  dennoch parallele (verzahnte) Ausführung möglich Serialisierbare Historie von T 1 und T 2 SchrittT1T1 T2T2 1.BOT 2.read(A) 3.BOT 4.read(C) 5.write(A) 6.write(C) 7.read(B) 8.write(B) 9.commit 10.read(A) 11.write(A) 12.commit

Äquivalenz von Historien  Zwei Historien sind äquivalent, wenn  Leseoperationen von nicht abgebrochenen Transaktionen sehen denselben Wert.  Am Ende der Ausführung beider Historien ist der Zustand der Datenbasis identisch  Grenzfall: R 1 (x) W 2 (x) R 1 (x) A 1 C 2 Nach Definition ist diese Historie äquivalent zu R 1 (x) R 1 (x) A 1 W 2 (x) C 2

Serielle Ausführung von T 1 vor T 2, also T 1 | T 2 SchrittT1T1 T2T2 1.BOT 2.read(A) 3.write(A) 4.read(B) 5.write(B) 6.commit 7.BOT 8.read(C) 9.write(C) 10.read(A) 11.write(A) 12.commit

Nicht serialisierbare Historie SchrittT1T1 T3T3 1.BOT 2.read(A) 3.write(A) 4.BOT 5.read(A) 6.write(A) 7.read(B) 8.write(B) 9.commit 10.read(B) 11.write(B) 12.commit

Zwei verzahnte Überweisungs-Transaktionen SchrittT1T1 T3T3 1.BOT 2.read(A,a 1 ) 3.a 1 := a 1 – 50 4.write(A,a 1 ) 5.BOT 6.read(A,a 2 ) 7.a 2 := a 2 – write(A,a 2 ) 9.read(B,b 2 ) 10.b 2 := b write(B,b 2 ) 12.commit 13.read(B,b 1 ) 14.b 1 := b write(B,b 1 ) 16.commit

Eine Überweisung (T 1 ) und eine Zinsgutschrift (T 3 ) SchrittT1T1 T3T3 1.BOT 2.read(A,a 1 ) 3.a 1 := a 1 – 50 4.write(A,a 1 ) 5.BOT 6.read(A,a 2 ) 7.a 2 := a 2 * write(A,a 2 ) 9.read(B,b 2 ) 10.b 2 := b 2 * write(B,b 2 ) 12.commit 13.read(B,b 1 ) 14.b 1 := b write(B,b 1 ) 16.commit

Theorie der Serialisierbarkeit „Formale“ Definition einer Transaktion Operationen einer Transaktion T i  r i (A) zum Lesen des Datenobjekts A,  w i (A) zum Schreiben des Datenobjekts A,  a i zur Durchführung eines aborts, implizites Schreiben aller vorher geschriebenen Objekte  c i zur Durchführung des commit.

Theorie der Serialisierbarkeit Konsistenzanforderung einer Transaktion T i  entweder abort oder commit aber nicht beides!  Falls T i ein abort durchführt, müssen alle anderen Operationen p i (A) vor a i ausgeführt werden, also p i (A) < i a i.  Analoges gilt für das commit, d.h. p i (A) < i c i falls T i „committed“.  Wenn T i ein Datum A liest und auch schreibt, muss die Reihenfolge festgelegt werden, also entweder r i (A) < i w i (A) oder w i (A) < i r i (A).

Theorie der Serialisierbarkeit II Historie  r i (A) und r j (A): In diesem Fall ist die Reihenfolge der Ausführungen irrelevant, da beide TAs in jedem Fall denselben Zustand lesen. Diese beiden Operationen stehen also nicht in Konflikt zueinander, so dass in der Historie ihre Reihenfolge zueinander irrelevant ist.  r i (A) und w j (A): Hierbei handelt es sich um einen Konflikt, da T i entweder den alten oder den neuen Wert von A liest. Es muss also entweder r i (A) vor w j (A) oder w j (A) vor r i (A) spezifiziert werden.  w i (A) und r j (A): analog  w i (A) und w j (A): Auch in diesem Fall ist die Reihenfolge der Ausführung entscheidend für den Zustand der Datenbasis; also handelt es sich um Konfliktoperationen, für die die Reihenfolge festzulegen ist.

Theorie der Serialisierbarkeit II Historie  r i (A) und a j : Hierbei handelt es sich um einen Konflikt, wenn T j vorher Objekt A geschrieben hat.  w i (A) und a j : analog - Konflikt, falls T j vorher Objekt A geschrieben hat. Ein Lesen von Objekt A in T j ist beim Abort von T j irrelevant.

Formale Definition einer Historie  H =  < H ist verträglich mit allen < i -Ordnungen, d.h.:  Für zwei Konfliktoperationen p,q  H gilt entweder -p < H q oder -q < H p.

Historie für drei Transaktionen Beispiel-Historie für 3 TAs r 3 (B)w 3 (A)w 3 (B)c3c3 w 3 (C) r 1 (A)w 1 (A)c1c1 r 2 (A)w 2 (B)c2c2 w 2 (C) H =

Äquivalenz zweier Historien  H  H‘ wenn sie die Konfliktoperationen der nicht abgebrochenen Transaktionen in derselben Reihenfolge ausführen. Des Weiteren müssen die schreibenden (und ggf. abort) Konflikttransaktionen aller Transaktionen in derselben Reihenfolge ausgeführt werden. r 1 (A)  r 2 (C)  w 1 (A)  w 2 (C)  r 1 (B)  w 1 (B)  c 1  r 2 (A)  w 2 (A)  c 2 r 1 (A)  w 1 (A)  r 2 (C)  w 2 (C)  r 1 (B)  w 1 (B)  c 1  r 2 (A)  w 2 (A)  c 2 r 1 (A)  w 1 (A)  r 1 (B)  r 2 (C)  w 2 (C)  w 1 (B)  c 1  r 2 (A)  w 2 (A)  c 2 r 1 (A)  w 1 (A)  r 1 (B)  w 1 (B)  c 1  r 2 (C)  w 2 (C)  r 2 (A)  w 2 (A)  c 2

Serialisierbare Historie Eine Historie ist serialisierbar wenn sie äquivalent zu einer seriellen Historie Hs ist. Historie und zugehöriger Serialisierbarkeitsgraph r 1 (A)w 1 (A)w 1 (B) r 3 (A)w 3 (A)c3c3 r 2 (A) w 2 (B)c2c2 H = c1c1

Serialisierbarkeitsgraph SG(H )= T3T3 T1T1 T2T2  w 1 (A)  r 3 (A) der Historie H führt zur Kante T 1  T 3 des SG  weitere Kanten analog  „Verdichtung“ der Historie

Serialisierbarkeitstheorem Eine Historie H ist genau dann serialisierbar, wenn der zugehörige Serialisierbarkeitsgraph SG(H) azyklisch ist. Historie H = w 1 (A)  w 1 (B)  c 1  r 2 (A)  r 3 (B)  w 2 (A)  c 2  w 3 (B)  c 3 Serialisierbarkeitsgraph Topologische Ordnung(en) SG(H )= T2T2 T3T3 T1T1

Isolation Level in SQL92 set transaction [read only, |read write,] [isolation level read uncommitted, | read committed,| repeatable read,| serializable,] [diagnostic size...,]

Isolation Level in SQL92  read uncommitted: Dies ist die schwächste Konsistentstufe. Sie darf auch nur für read only-Transaktionen spezifiziert werden. Eine derartige Transaktion hat Zugriff auf noch nicht festgeschriebene Daten. Zum Beispiel ist folgender Schedule möglich: T1T1 T2T2 read(A)... write(A) read(A)... rollback

Isolation Level in SQL92  read committed: Diese Transaktionen lesen nur festgeschriebene Werte. Allerdings können sie unterschiedliche Zustände der Datenbasis-Objekte zu sehen bekommen: T1T1 T2T2 read(A) write(A) write(B) commit read(B) read(A)...

Isolation Level in SQL92  repeatable read: Das oben aufgeführte Problem des non repeatable read wird durch diese Konsistenzstufe ausgeschlossen. Allerdings kann es hierbei noch zum Phantomproblem kommen. Dies kann z.B. dann passieren, wenn eine parallele Änderungstransaktion dazu führt, dass Tupel ein Selektionsprädikat erfüllen, das sie zuvor nicht erfüllten.  serializable: Diese Konsistenzstufe fordert die Serialisierbarkeit. Dies ist der Default.