9. Transaktionsverwaltung Der Scheduler Architektur der Transaktionsverwaltung Sperrende und nicht-sperrende Verfahren Transaktionen in SQL-Systemen Transaktionsmonitore T 1 T T 2 n Transaktions- Manager (TM) Scheduler (SC) korrekter Schedule (bestehend aus r, w, c, a) Speicher Manager (SM) Recovery Manager (RM) Puffer Manager (PM) DB VL Datenbank-Implementierungstechniken 9 1 VL Datenbank-Implementierungstechniken 9 2 Transaktionsoperationen Zustände einer Transaktion Transaktionsklammern active BOT (Begin of Transaction) EOT (End of Transaction) Schritte: r (read), initial BOT execute running delay restart delayed w (write), a (abort), und c (commit). retry stop reject aborted EOT committed t = {r w} (a c) stopped VL Datenbank-Implementierungstechniken 9 3 VL Datenbank-Implementierungstechniken 9 4
Behandlung eines Schritts ausführen (execute) Transaktion Zustand running. verzögern (delay) Transaktion Zustand delayed zurückweisen (reject) Transaktion Zustand aborted Aggressive Scheduler ein Scheduler ist aggressiv, wenn er Konflikte zuläßt und dann versucht, aufgetretene Konflikte zu erkennen und aufzulösen maximiert die Parallelität von Transaktionen Risiko: Transaktionen werden erst am Ende ihrer Ausführung zurückgesetzt VL Datenbank-Implementierungstechniken 9 5 VL Datenbank-Implementierungstechniken 9 6 Konservative Scheduler ein Scheduler arbeitet konservativ, wenn er Konflikte möglichst vermeidet, dafür aber Verzögerungen von Transaktionen in Kauf nimmt erlauben nur eine geringe Parallelität von Transaktionen minimieren den Rücksetzungsaufwand für abgebrochene Transaktionen im Extremfall findet keine Parallelisierung von Transaktionen mehr statt, d.h., es werden immer alle Transaktionen bis auf eine verzögert Sperrmodelle Schreib- und Lesesperren in folgender Notation: rl(x): Lesesperre (engl. read lock) auf einem Objekt x wl(x): Schreibsperre (engl. write lock) auf einem Objekt x Entsperren ru(x) und wu(x), oft zusammengefaßt u(x) für engl. unlock VL Datenbank-Implementierungstechniken 9 7 VL Datenbank-Implementierungstechniken 9 8
Sperrdisziplin Schreibzugriff w(x) nur nach Setzen einer Schreibsperre wl(x) möglich Lesezugriffe r(x) nur nach d rl(x) oder wl(x) erlaubt nur Objekte sperren, die nicht bereits von einer anderen Transaktion gesperrt nach rl(x) nur noch wl(x) erlaubt, danach auf x keine Sperre mehr; Sperren derselben Art werden maximal einmal gesetzt nach u(x) durch t i darf t i kein erneutes rl(x) oder wl(x) ausführen vor einem commit müssen alle Sperren aufgehoben werden Verklemmungen Alternativen: delay t 1 t 2 wl(x) wl(y) wl(y) wl(x) Verklemmung! delay Verklemmungen werden erkannt und beseitigt Verklemmungen werden von vornherein vermieden VL Datenbank-Implementierungstechniken 9 9 VL Datenbank-Implementierungstechniken 9 10 Erkennung und Auflösung Wartegraph 6 5 1 2 3 Auflösen durch Abbruch einer Transaktion, Kriterien: Anzahl der aufgebrochenen Zyklen, Länge einer Transaktion, Rücksetzaufwand einer Transaktion, Wichtigkeit einer Transaktion,... 4 neue Sperre Livelock-Problem 1. T 1 sperrt A 2. T 2 will A sperren, muß aber warten 3. T 3 will danach A sperren, muß auch warten 4. T 1 gibt A frei 5. T 3 kommt vor T 2 an eine Zeitscheibe, sperrt A 6. T 2 will weiterhin A sperren, muß aber warten 7. T 4 will danach A sperren, muß auch warten 8. T 3 gibt A frei 9. T 4 kommt vor T 2 an die nächste Zeitscheibe... VL Datenbank-Implementierungstechniken 9 11 VL Datenbank-Implementierungstechniken 9 12
Sperrprotokolle: Notwendigkeit Zwei-Phasen-Sperr-Protokoll T 1 T 2 wl(x) w(x) u(x) wl(y) w(y) u(y) wl(x) w(x) u(x) wl(y) w(y) u(y) #Sperren Freigabe- Phase Zeit Anforderungs- Phase 2PL VL Datenbank-Implementierungstechniken 9 13 VL Datenbank-Implementierungstechniken 9 14 Konflikt bei Nichteinhaltung des 2PL Striktes Zwei-Phasen-Sperr-Protokoll T 1 T 2 u(x) wl(y). wl(x) wl(y). u(x) u(y) #Sperren S2PL Anforderungs- Phase Freigabe-Phase vermeidet kaskadierende Abbrüche! Zeit VL Datenbank-Implementierungstechniken 9 15 VL Datenbank-Implementierungstechniken 9 16
Konservatives 2PL-Protokoll Sperrgranulate #Sperren Freigabe- Phase C2PL Zeit #Sperren CS2PL Zeit Granularitätshierarchien in Datenbanken Hierarchische Sperren Baumprotokolle für Baumindexe Anforderungs- Phase vermeidet Deadlocks! Anforderungs- Phase Freigabe- Phase VL Datenbank-Implementierungstechniken 9 17 VL Datenbank-Implementierungstechniken 9 18 Granularitätshierarchien in RDBS Granularitätshierarchien Datenbank Datenbank Relation Datei Tupel Cluster Attribut Seite Logisch Physisch Hierarchische Sperren Sperren pflanzen sich nach unten (in Richtung der Blätter) fort Sperren dürfen nicht von oben (von der Wurzel her) überschrieben werden Zusätzlich: intentionale Sperren (engl. intentional locks) Warnungen vor Sperren, die sich in der Hierarchie weiter unten befinden irl (intentionale Lesesperre) und iwl (intentionale Schreibsperre) VL Datenbank-Implementierungstechniken 9 19 VL Datenbank-Implementierungstechniken 9 20
Kompatibilitätsmatrix für elementare Sperren rl i (x) wl i (x) rl j (x) wl j (x) Kompatibilitätsmatrix für hierarchische Sperren rl i (x) wl i (x) irl i (x) iwl i (x) riwl i (x) rl j (x) wl j (x) irl j (x) iwl j (x) riwl j (x) VL Datenbank-Implementierungstechniken 9 21 VL Datenbank-Implementierungstechniken 9 22 Ablauf des hierarchischen Sperren 1. Sperren werden auf einem Pfad in der Reihenfolge von der Wurzel zum Zielobjekt gesetzt 2. Datenobjekt, auf dem gearbeitet werden soll, wird gesperrt: Schreib- oder Lesesperre (dabei Sperrenverträglichkeitsmatrix beachten!) 3. Alle anderen Knoten auf dem Pfad bekommen intentionale Sperren 4. Sperren können verschärft werden, das heißt ein rl kann zum wl werden, ein irl zum rl und ein irl zum iwl 5. Freigabe erfolgt in umgekehrter Reihenfolge Hierarchisches Sperren: Beispiel I T 1 T 2 BetriebsDB Datenbank BetriebsDB irl (explizit) (BetriebsDB) iwl (explizit) Mitarbeiter Relation... Relation Mitarbeiter rl (explizit) (Mitarbeiter) (Projekt) iwl (explizit) Tamara,..., Mario Tupel... Tupel rl (implizit) (Tamara Jagellowsk) (Mario De Monti) Gehalt,..., Telefon Attribut... Attribut rl (implizit) (Gehalt) (Telefon) VL Datenbank-Implementierungstechniken 9 23 VL Datenbank-Implementierungstechniken 9 24
Hierarchisches Sperren: Beispiel II Hierarchisches Sperren: riwl T 1 T 2 T 1 sperrt T 2 sperrt BetriebsDB irl (explizit) Datenbank (BetriebsDB) BetriebsDB iwl (explizit) BetriebsDB riwl (explizit) Datenbank (BetriebsDB) BetriebsDB irl (explizit) Mitarbeiter irl (explizit) Relation (Mitarbeiter)... Relation (Projekt) Mitarbeiter iwl (explizit) Mitarbeiter riwl (explizit) Relation (Mitarbeiter)... Relation (Projekt) Mitarbeiter irl (explizit) Tamara irl (explizit) Tupel (Tamara Jagellowsk)... Tupel (Mario De Monti) Tamara iwl (explizit) Tamara,..., Mario rl (implizit) Tamara wl (explizit) Tupel (Tamara Jagellowsk)... Tupel (Mario De Monti) Mario rl (explizit) Gehalt rl (explizit) Attribut... (Gehalt) Attribut (Telefon) Telefon wl (explizit) VL Datenbank-Implementierungstechniken 9 25 VL Datenbank-Implementierungstechniken 9 26 Sperren in Indexstrukturen Baumprotokoll 1. Objekt o kann nur dann von T gesperrt werden, wenn sein direkter Vorgänger bereits von T gesperrt ist 2. erste Regel gilt nicht für die erste Sperre einer Transaktion 3. Sperren können jederzeit wieder freigegeben werden 4. Kein Objekt kann innerhalb einer Transaktion T zweimal gesperrt werden Beispiel Baumprotokoll lock A; lock B; unlock A; lock D A B D E C F G VL Datenbank-Implementierungstechniken 9 27 VL Datenbank-Implementierungstechniken 9 28
Ablauf im Baumprotokoll T 1 T 2 T 3 lock A lock B lock D unlock B lock B lock C lock E unlock D lock F unlock A lock G unlock C unlock E lock E unlock F unlock B unlock G unlock E Baumprotokolleigenschaften Baumprotokoll erzwingt nicht 2PL! Falls alle Transaktionen dem Baum-Protokoll genügen, ist jeder korrekte Schedule serialisierbar. VL Datenbank-Implementierungstechniken 9 29 VL Datenbank-Implementierungstechniken 9 30 Nicht-sperrende Verfahren Zeitstempelbasierte Verfahren erzwingen eine korrekte Reihenfolge der Bearbeitungsschritte mittels geeigneter Markierungen der Transaktionen Serialisierbarkeitstester verwalten einen Konfliktgraphen, und realisieren daher eine direkte Überprüfung der Konfliktserialisierbarkeit Zertifikatoren führen zunächst die kompletten Transaktion aus und versuchen erst am Ende festzustellen, ob die Transaktion gemäß dem Serialisierbarkeitsbegriffs abgelaufen sind Zeitmarkenverfahren Zeitmarken sind eindeutig und werden fortlaufend vergeben. Für jedes Datenobjekt x werden zwei Werte geführt: max-r-scheduled[x]: Variable, die den Zeitstempel der letzten Leseoperation auf x enthält max-w-scheduled[x]: Variable, die den Zeitstempel der letzten Schreiboperation auf x enthält VL Datenbank-Implementierungstechniken 9 31 VL Datenbank-Implementierungstechniken 9 32
Timestamp-Ordering-Regel Eine Operation p i [x] wird vor q k [x] genau dann ausgeführt, wenn ts(t i ) < ts(t k ) gilt. p und q: inkompatible Operationen der Transaktionen T i bzw. T k (i k) auf einem Objekt x ts(t i ) bzw. ts(t k ) sind Zeitstempel der Transaktionen T i bzw. T k Formal: Sind p i (x) und q j (x) in Konflikt, so gilt: p i (x) wird vor q j (x) ausgeführt ts(t i ) < ts(t j ). Basis-TO-Algorithmus if p i [x] ist eingetroffen then if p i [x] ist r i [x] then if ts(t i ) < max-w-scheduled[x] then weise Operation zurück; else max-r-scheduled[x] := max(max-r-scheduled[x], ts(t i )); gebe Operation weiter; else /* p i [x] ist w i [x] */ if ts(t i ) < max-w-scheduled[x] or ts(t i ) < max-r-scheduled[x] then weise Operation zurück; else max-w-scheduled[x] := ts(t i ); gebe Operation weiter; VL Datenbank-Implementierungstechniken 9 33 VL Datenbank-Implementierungstechniken 9 34 Nachteile und Vorteile der TO-Verfahren Nachteil: Anfälligkeit gegen stark variierende Laufzeiten von Transaktionen lang andauernde Transaktionen bearbeiten ihre letzten Schritte längere Zeit nach der Vergabe der Zeitmarke kommen damit mit diesen Schritten mit größerer Wahrscheinlichkeit zu spät Vorteil: einfache Realisierung in verteilten Systemen Zeitmarkenverfahren: Ablauf T 1 T 2 T 3 A B C mrs mws mrs mws mrs mws ts = 200 ts = 150 ts = 175 0 0 0 0 0 0 read B 0 0 200 0 0 0 read A 150 0 200 0 0 0 read C 150 0 200 0 175 0 write B 150 0 200 200 175 0 write A 150 200 200 200 175 0 write C 150 200 200 200 175 abort 150 200 200 200 175 0 VL Datenbank-Implementierungstechniken 9 35 VL Datenbank-Implementierungstechniken 9 36
Optimiertes Zeitmarkenverfahren Optimierte BTO-Regel: bei negativen Ausgang des Vergleichs einer schreibenden Transaktion mit der max-w-scheduled-marke wird das Schreiben ignoriert sofern kein Konflikt mit der max-w-scheduled-marke auftritt alter Wert von max-w-scheduled wird übernommen und die Transaktion läuft weiter Opt. Zeitmarkenverfahren: Ablauf T 1 T 2 T 3 A C mrs mws mrs mws ts = 200 ts = 150 ts = 175 0 0 0 0 read A 150 0 0 0 read C 150 0 175 0 write A 150 200 175 0 write A 150 200 ( ) 175 0 Optimierung für blindes Schreiben VL Datenbank-Implementierungstechniken 9 37 VL Datenbank-Implementierungstechniken 9 38 Livelocks im Zeitmarkenverfahren T 1 T 2 T 1 T 2 A B mrs mws mrs mws ts = 100 ts = 110 ts = 120 ts = 130 0 0 0 0 write B 0 0 0 100 write A 0 110 0 100 read A 0 110 0 100 write B 0 110 0 120 read B 0 110 0 120 write A 0 130 0 120 read A 0 130 0 120 Serialisierbarkeitsgraphentester Problem: Bereinigen des Konfliktgraphens r 0 (x) w 1 (x)w 1 (y 1 )c } {{ } 1... w n (x)w n (y n )c n w } {{ } 0 (z) T 1 T n t 0 t 1 t 2. t n VL Datenbank-Implementierungstechniken 9 39 VL Datenbank-Implementierungstechniken 9 40
Optimistische Verfahren: Phasen 1. Ausführungsphase (execute): Transaktion wird ausgeführt, d.h. alle Lese- und Schreiboperationen; Schreiboperationen jedoch nicht in der Datenbank, sondern auf einer lokalen Kopie des Datenbankobjekts im Puffer 2. Validierung (validate) für jede Transaktion, die commit ausführen will, wird geprüft, ob sie im Sinne der Konfliktserialisierbarkeit korrekt abgelaufen ist 3. Persistenzphase (persist): falls keine Konflikte aufgetreten sind, Zurückschreiben aller geänderten Datenbankobjekte in den stabilen Speicher (d.h. in die Datenbank) Validierungskriterium Transaktionszähler T C T i, T j : n(t i ) < n(t j ) mit n(t i ) =Wert von TC nach der Validierung von T i : 1. T i beendet seine valpersist-phase, bevor T j diese beginnt. 2. x ws(t i ) rs(t j ) T i beendet valpersist-phase, bevor T j x liest. 3. x rs(t i ) ws(t j ) T i liest x vor Beginn der valpersist-phase von T j ws(t i ) ist write-set von T i (alle von T i geschriebenen DB-Objekte) rs(t i ) ist read-set von T i (gelesene DB-Objekte) VL Datenbank-Implementierungstechniken 9 41 VL Datenbank-Implementierungstechniken 9 42 Optimistische Scheduler Optimistische Scheduler (II) T 1 T 2 T 3 execute execute validate persist execute validate persist validate persist Rückwärtsvalidierung Rückwärtsvalidierung: Test von rs(t i ) gegen ws(t j ) für bereits abgeschlossene T j ausgenommen davon sind T j, die bereits vor Beginn von T i ein commit ausgeführt haben T 1 execute validate persist bei Konflikt: Zurücksetzen von T i im Beispiel: Test von rs(t 1 ) gegen ws(t 2 ) und ws(t 3 ) T 2 T 3 execute execute Vorwärtsvalidierung Vorwärtsvalidierung Test von ws(t i ) gegen rs(t j ) für Transaktionen T j, die aktiv sind (also in der Ausführungsphase) bei Konflikt: Zurücksetzen von T j im Beispiel: ws(t 1 ) gegen rs(t 2 ) und rs(t 3 ) VL Datenbank-Implementierungstechniken 9 43 VL Datenbank-Implementierungstechniken 9 44
Multiversionen-Synchronisation engl. multiversion concurrency control (MVCC) Umsetzung in Oracle, InterBase, PostgreSQL,... Motivation Geg. Schedule s: s = r 1 (x)w 1 (x)r 2 (x)w 2 (y)r 1 (y)w 1 (z)c 1 c 2 s CSR aber tolerierbar, wenn r 1 (y) alte Version von y lesen könnte, so dass r 1 (y) konsistent zu r 1 (x) ist dann: s äquivalent zu s = t 1 t 2 VL Datenbank-Implementierungstechniken 9 45 MVCC: Prinzip jede Änderungsoperation w erzeugt neue Version des Datenobjektes Leseoperationen können Version wählen Versionen sind transparent für Applikationen Vorteile: Entkopplung von Lese- und Änderungsoperationen Lesetransaktion hat Sicht auf Datenbank wie bei BOT keine Synchronisation von Lesetransaktionen sowie gegen Lesetransaktionen notwendig Reduzierung der Konfliktwahrscheinlichkeit Synchronisation von Änderungsoperationen durch andere Verfahren (Sperrverfahren, Zeitstempel) VL Datenbank-Implementierungstechniken 9 46 MVCC: Beispiel T 1 T 2 T R w(x 0 x 1 ) w(y 0 y 1 ) commit w(x 1 x 2 ) commit r(y 0 ) r(x 0 ) MVCC: Versionenverwaltung Aufgabe: Bestimmung der zu lesenden Version globaler Transaktionszähler T NC (transaction number count) Commit-Zeitstempel cts und BOT-Zeitstempel bts für Transaktion Schreibzeitstempel wts(x) für Objekt x VL Datenbank-Implementierungstechniken 9 47 VL Datenbank-Implementierungstechniken 9 48
MVCC: Versionenverwaltung (II) Commit einer Änderungstransaktion T U : aktueller T NC-Wert als Commit-Zeitstempel cts sowie Inkrementieren von T NC modifiziertes Objekt: Schreibzeitstempel wts(x) = cts(t U ) Lesetransaktion T R : aktueller T NC-Wert als BOT-Zeitstempel: bts(t R ) = T NC hat Zugriff auf jüngste Version von x mit: MVCC: Versionenverwaltung (III) Aufgabe: Freigabe nicht mehr benötigter Versionen (garbage collection) BOT-Zeitstempel der ältesten Lesetransaktion: bts_min Version x i von Objekt x kann gelöscht werden, falls neuere Version x j existiert, so dass gilt: wts(x i ) < wts(x j ) < bts_min wts(x) < bts(t R ) VL Datenbank-Implementierungstechniken 9 49 VL Datenbank-Implementierungstechniken 9 50 Transaktionen in SQL-DBS Aufweichung von ACID in SQL-92: Isolationsebenen set transaction [ { read only read write }, ] [isolation level { read uncommitted read committed repeatable read serializable }, ] [ diagnostics size...] Standardeinstellung: set transaction read write, isolation level serializable Bedeutung der Isolationsstufen read uncommitted schwächste Stufe: Zugriff auf nicht geschriebene Daten, nur für read only Transaktionen statistische und ähnliche Transaktionen (ungefährer Überblick, nicht korrekte Werte) keine Sperren effizient ausführbar, keine anderen Transaktionen werden behindert read committed nur Lesen endgültig geschriebener Werte, aber nonrepeatable read möglich repeatable read kein nonrepeatable read, aber Phantomproblem kann auftreten serializable garantierte Serialisierbarkeit VL Datenbank-Implementierungstechniken 9 51 VL Datenbank-Implementierungstechniken 9 52
Isolationsebenen II Isolationsebenen: read committed Isolationsebene Dirty Unrepeatable Phantom Read Read Read Read Uncommitted + + + Read Committed + + Repeatable Read + Serializable T 1 T 2 select A from R alter Wert select A from R alter Wert select A from R neuer Wert update R set A = neu commit VL Datenbank-Implementierungstechniken 9 53 VL Datenbank-Implementierungstechniken 9 54 Isolationsebenen: serializable T 1 T 2 set transaction isolation level serializable update R set A = neu where C = 42 Fehler set transaction... update R set A = neu where C = 42 commit Oracle I Unterstützung der Isolationsebenen Read Committed und Serializable darüber hinaus: Read-Only-Modus (nicht Bestandteil von SQL-92) set transaction isolation level read committed; set transaction isolation level serializable; set transaction isolation level read only; VL Datenbank-Implementierungstechniken 9 55 VL Datenbank-Implementierungstechniken 9 56
Oracle II Isolationsebenen für eine Menge von Transaktionen alter session set isolation_level Isolationsebene; Explizite Kommandos zum Setzen von Sperren lock table Tabelle in row share mode; lock table Tabelle in share mode; lock table Tabelle in row exclusive mode; lock table Tabelle in share row exclusive mode; lock table Tabelle in exclusive mode; Transaktionsmonitore Presentation Server Presentation Server Workflow Controller Transaction Server Transaction Server VL Datenbank-Implementierungstechniken 9 57 VL Datenbank-Implementierungstechniken 9 58 Transaktionsmonitore: Architektur Präsentations-Server, engl. presentation server realisiert als Client die Kommunikation mit dem Anwender (Kommandosprache oder Menü-gesteuerte Oberflächen zum Absetzen von Transaktionen etc.) Workflow-Kontroller (engl. workflow controller) erzwingt die Zuteilung (engl. routing) der Transaktionsanforderungen an verschiedenen DBMS und realisiert z.b. das Zwei-Phasen-Commit-Protokoll Transaktions-Server (engl. transaction server) realisieren die Kopplung der lokalen DBMS mit dem Transaktionsmonitor VL Datenbank-Implementierungstechniken 9 59 Vorteile eines Transaktionsmonitors bietet eine einheitliche Schnittstelle für die Transaktionsprogrammierung auf verschiedenen DBMS bei verteilter Verarbeitung Übernahme der Routing der Transaktionen und der Erzwingung von Commit-Protokollen Übernahme von Systemfunktionen wie Lastbalancierung, Fehlerkontrolle und Systemkonfiguration kann Funktionen wie das Schreiben eines Log-Buchs oder die Kommunikationsüberwachung übernehmen Transaktions-Server eines TP-Monitors kann auch Daten einkapseln, die nicht von einem DBMS mit voller Transaktionsfunktionalität verwaltet werden VL Datenbank-Implementierungstechniken 9 60