KAPITEL 6 TRANSAKTIONSVERWALTUNG UND RECOVERY

Transkript

1 KAPITEL 6 TRANSAKTIONSVERWALTUNG UND RECOVERY h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 1

2 Recovery Transaktionsverwaltung Einordnung in die 5-Schichten-Architektur Datensystem Mengenorientierte Schnittstelle Satzorientierte Schnittstelle Zugriffssystem Speichersystem Pufferverwaltung Betriebssystem Externspeicher Interne Satzschnittstelle Systempufferschnittstelle Dateischnittstelle Geräteschnittstelle h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 2

3 Transaktionsverwaltung und Recovery Inhalte des Kapitels Transaktionsverwaltung Transaktionsbegriff (ACID) Synchronisation und Sperren Wiederholung DB (Bachelor) Isolation Level in SQL MVCC Hierarchische Sperren Isolation Level und Sperren in relationalen DBMS Recovery Fehlerklassen Recovery-Strategien Lernziele Verständnis für Synchronisationsbegriff Kenntnis verschiedener Sperrverfahren Kenntnis der Fehlerklassen und der unterschiedlichen Recovery-Strategien Verständnis der Auswirkungen der Recovery-Anforderungen auf den Puffer-Manager h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 3

4 Wiederholung DB (Bachelor) Transaktionsbegriff Transaktionen Eine Transaktion ist eine Folge von Operationen (Aktionen), welche die Datenbank von einem konsistenten Zustand in einen konsistenten, eventuell veränderten, Zustand überführt, wobei das ACID-Prinzip eingehalten werden muss. Aspekte: Semantische Integrität: Korrekter (konsistenter) DB-Zustand nach Ende der Transaktion Ablaufintegrität: Fehler durch gleichzeitigen Zugriff mehrerer Benutzer auf dieselben Daten vermeiden h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 4

5 Wiederholung DB (Bachelor) ACID-Eigenschaften Atomicity (Atomarität): Transaktion wird entweder ganz oder gar nicht ausgeführt Mechanismen zur Fehlerbehandlung notwendig. Consistency (Konsistenz oder auch Integritätserhaltung): Datenbank ist vor Beginn und nach Beendigung einer Transaktion jeweils in einem konsistenten Zustand Mechanismen zur Konsistenzsicherung und Fehlerbehandlung notwendig. Isolation (Isolation): Nutzer, der mit einer Datenbank arbeitet, sollte den Eindruck haben, dass er mit dieser Datenbank alleine arbeitet Mechanismen zur Mehrbenutzersynchronisation notwendig. Durability (Dauerhaftigkeit / Persistenz): nach erfolgreichem Abschluss einer Transaktion muss das Ergebnis dieser Transaktion dauerhaft in der Datenbank gespeichert werden Mechanismen zur Fehlerbehandlung notwendig. h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 5

6 Wiederholung DB (Bachelor) Mehrbenutzerbetrieb Probleme im (unkontrolliertem) Mehrbenutzerbetrieb Verlorengegangenes Ändern (lost update) Abhängigkeiten von nicht freigegebenen Daten (dirty read) Inkonsistentes Lesen (non repeatable read) Phantom-Problem h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 6

7 Wiederholung DB (Bachelor) Verlorengegangene Änderungen (lost update) Zwei Programme ( Überweisung und Zinsgutschrift ) arbeiten gleichzeitig auf der Datenbank: Zeit Transaktion 1 Transaktion 2 1 read (A,a1) 2 a1 := a read (A,a2) 4 a2 = a2 * write (A, a2) 6 commit 7 write (A,a1) 8 read (B,b1) 9 b1 := b write (B,b1) 11 commit Zustand von A auf der Datenbank h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 7

8 Wiederholung DB (Bachelor) Abhängigkeit von nicht freigegebenen Änderungen (dirty read) Der neue Mitarbeiter B soll 10% mehr als Mitarbeiter A verdienen. Mitarbeiter A erhält eine Gehaltserhöhung um 100 Euro. Diese Transaktion wird abgebrochen, da am Ende der Transaktion die Verletzung einer Integritätsbedingung festgestellt wird (z.b. Maximalgrenze für Gehalt einer bestimmten Tarifgruppe verletzt). Zeit Transaktion 1 Transaktion 2 1 read (A,a1) 2 a1 := a write (A,a1) 4 read (A,a2) 5 b1 = a2 * write (B, b1) 7 commit 9 abort A B Problem? h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 8

9 Inkonsistente Analyse (non repeatable read) Die Summe der Gehälter aller Mitarbeiter wird ermittelt. Parallel dazu werden die Gehälter der Mitarbeiter um jeweils Euro erhöht. Wiederholung DB (Bachelor) Zeit Transaktion 1 Transaktion 2 1 read (A, a1) 2 summe = summe + a1 3 read (A, a2) 4 a2 = a write (A, a2) 6 read (B, b2) 7 b2 = b write (B, b2) 9 commit 10 read (B, b1) 11 summe = summe + b1 12 commit Problem? h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 9

10 Wiederholung DB (Bachelor) Phantom-Problem Ein Bonus von Euro soll gleichmäßig auf alle Mitarbeiter der Firma verteilt werden. Parallel dazu wird ein neuer Mitarbeiter eingefügt. Zeit Transaktion 1 Transaktion 2 1 select count(*) into X from Mitarbeiter; 2 insert into Mitarbeiter values (Meier, , ); 3 commit; 4 update Mitarbeiter set Gehalt = Gehalt /X; 5 commit; Problem? h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 10

11 Synchronisation von Transaktionen: Modell Ziel der Synchronisation: Vermeidung aller Mehrbenutzeranomalien Wiederholung DB (Bachelor) Modell Wenn Transaktionen seriell ausgeführt werden, dann bleibt die Konsistenz der DB erhalten. Transaktion: BOT, Folge von READ- und WRITE-Anweisungen, EOT Die Ablauffolge von Transaktionen mit ihren Operationen kann durch einen Schedule beschrieben werden (BOT ist implizit, EOT wird durch c i (commit) oder a i (abort) dargestellt): Beispiel: r 1 (x), r 2 (x), r 3 (y), w 1 (x), w 3 (y), r 1 (y), c 1, r 3 (x), w 2 (x), a 2, w 3 (x), c 3,... Beispiel eines seriellen Schedules : r 1 (x), w 1 (x), r 1 (y), c 1, r 3 (y), w 3 (y), r 3 (x), c 3, r 2 (x), w 2 (x), c 2,... h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 11

12 Wiederholung DB (Bachelor) Korrektheitskriterium der Synchronisation: Serialisierbarkeit 1(2) Ziel der Synchronisation: logischer Einbenutzerbetrieb, d.h. Vermeidung aller Mehrbenutzeranomalien Gleichbedeutend mit formalem Korrektheitskriterium der Serialisierbarkeit: Die parallele Ausführung einer Menge von n Transaktionen ist serialisierbar, wenn es eine serielle Ausführung derselben Transaktionen gibt, die den gleichen DB-Zustand und die gleichen Ausgabewerte wie die ursprüngliche Ausführung erzielt. Hintergrund: serielle Ablaufpläne sind korrekt jeder Ablaufplan, der denselben Effekt wie ein serieller erzielt, ist akzeptierbar h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 12

13 Wiederholung DB (Bachelor) Korrektheitskriterium der Synchronisation: Serialisierbarkeit 2(2) Transaktion 1 Transaktion 2 Transaktion 3 T 1-1 T 1-2 T 1-3 T 2-1 T 3-1 T 2-2 T 3-2 T 2-3 (Quasi-) parallele Ausführung T 1-1 T 2-1 T 3-1 T 1-2 T 1-3 T 2-2 T 2-3 T 3-2 Die parallele Ausführung einer Menge von n Transaktionen ist serialisierbar, wenn es eine serielle Ausführung derselben Transaktionen gibt, die den gleichen DB-Zustand und die gleichen Ausgabewerte wie die ursprüngliche Ausführung erzielt. T 2-1 T 2-2 T 2-3 T 3-1 T 3-2 T 1-1 T 1-2 T 1-3 h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 13

14 Wiederholung DB (Bachelor) Nachweis der Serialisierbarkeit 1(2) Ansatz: Führen von zeitlichen Abhängigkeiten zwischen Transaktionen in einem Abhängigkeitsgraphen (Konfliktgraphen) Abhängigkeit (Konflikt) besteht, wenn zwei Transaktionen auf dasselbe Objekt mit nicht reihenfolgeunabhängigen Operationen zugreifen. Konfliktarten: Schreib-/Lese-Konflikt w(x) r(x) Lese-/Schreib-Konflikt r(x) w(x) Schreib-/Schreib-Konflikt w(x) w(x) h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 14

15 Wiederholung DB (Bachelor) Nachweis der Serialisierbarkeit 2(2) w (y) r (x) T 1 r (y) w (x)? T 2 T 2 T 3 w (x) T 1 T 3 Serialisierbarkeit liegt vor, wenn der Abhängigkeitsgraph keine Zyklen enthält Abhängigkeitsgraph beschreibt partielle Ordnung zwischen Transaktionen, die sich zu einer vollständigen erweitern lässt (Serialisierungsreihenfolge) im Beispiel: T 3 T 1 T 2 h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 15

16 Wiederholung DB (Bachelor) Sperren Berechnung des Abhängigkeitsgraphen ist für den Korrektheitsnachweis von Synchronisationsverfahren interessant, aber weniger für den direkten Einsatz im DBMS geeignet (Ausnahme: optimistische Sperrverfahren) Praktische Umsetzung in DBMS: Sperren Zwei Arten von Sperren rl(x) Lesesperre (read lock bzw. shared lock) auf Objekt x wl(x) Schreibsperre (write lock bzw. exclusive lock) Kompatibilitätsmatrix h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 16

17 Zwei-Phasen-Sperrprotokolle (2 Phase Locking, 2PL) Einhaltung folgender Regeln gewährleistet Serialisierbarkeit: 1. Vor jedem Objektzugriff muss Sperre mit ausreichendem Modus angefordert werden Schreibzugriff w(x) nur nach Setzen einer Schreibsperre wl(x) möglich Lesezugriffe r(x) nur nach rl(x) oder wl(x) erlaubt 2. Gesetzte Sperren anderer Transaktionen sind zu beachten Nur Lesesperren sind verträglich Wiederholung DB (Bachelor) 3. Zweiphasigkeit: Anfordern von Sperren erfolgt in einer Wachstumsphase Freigabe der Sperren in Schrumpfungsphase Sperrfreigabe kann erst beginnen, wenn alle Sperren gehalten werden 4. Spätestens bei EOT sind alle Sperren freizugeben h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 17

18 Wiederholung DB (Bachelor) Zwei-Phasen-Sperrprotokoll (2PL) 2PL garantiert Serialisierbarkeit in einer fehlerfreien Umgebung aber: Fehler während Schrumpfungsphase können zu dirty read führen! Lösungsalternativen Lesen schmutziger Daten und Abhängigkeiten bei commit überprüfen (Problem: kaskadierende Rollbacks). Besser: Strikte Zwei-Phasen-Sperrverfahren mit Sperrfreigabe nach commit. #Sperren 2PL BOT Wachstum Schrumpfung EOT Zeit h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 18

19 Wiederholung DB (Bachelor) Striktes Zwei-Phasen-Sperrprotokoll (S2PL) alle Sperren werden bis EOT gehalten damit ist kaskadierendes Rücksetzen ausgeschlossen Nachteil? #Sperren S2PL BOT EOT Zeit h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 19

20 Wiederholung DB (Bachelor) Verklemmungen (deadlocks) T 1 T 2 Bemerkung wl(x) wl(y) wl(y) wl(x) T 1 muss auf T 2 warten T 2 muss auf T 1 warten deadlock DBMS muss deadlock erkennen und eine der beiden Transaktionen abrechen verschiedene Strategien: ältere Transaktion oder jüngere Transaktion Analyse des Wartegraphens (minimale Auswirkungen berechnen) Timeout-Verfahren... h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 20

21 Wiederholung DB (Bachelor) Konservative Sperrprotokolle (C2PL, C2PL) Alternative Variante: Preclaiming in Verbindung mit dem strikten 2PL oder S2PL C2PL bzw. CS2PL Problem? #Sperren CS2PL BOT EOT Zeit h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 21

22 Phantom-Problem: Sperren als Lösung? Ein Bonus von Euro soll gleichmäßig auf alle Mitarbeiter der Firma verteilt werden. Parallel dazu wird ein neuer Mitarbeiter eingefügt. Wiederholung DB (Bachelor) Zeit T 1 T 2 1 select count(*) into X from Mitarbeiter; 2 insert into Mitarbeiter values (Meier, , ); 3 commit; 4 update Mitarbeiter set Gehalt = Gehalt /X; 5 commit; Sperren? Lösung? h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 22

23 Wiederholung DB (Bachelor) Phantom-Problem: Lösung Zusätzlich zu den Tupeln muss auch der Zugriffweg, auf dem man zu den Objekten gelangt ist, gesperrt werden. Beispiel: select count(*) into X from Mitarbeiter; alle Mitarbeiter (bzw. deren Primärschlüssel-Index) müssen mit einer RL-Sperre belegt werden beim Einfügen eines neuen Mitarbeiter wird dies erkannt und T 2 muss warten Sperre kann ggf. auch selektiver sein z.b.: select count(*) into X from Mitarbeiter where PNr between 1000 and 2000 nur die Mitarbeiter mit der entsprechenden PNr müssen gesperrt werden (z.b. Index-Bereich von PNr[1000,2000]) h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 23

24 Wiederholung DB (Bachelor) Isolation Level in SQL set transaction [ { read only read write }, ] [ isolation level { read uncommitted read committed repeatable read serializable } ] Beispiel (erstes Statement innerhalb der Transaktion) set transaction read only, isolation level read committed; select...; commit; h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 24

25 Wiederholung DB (Bachelor) Bedeutung der Isolationsstufen read uncommitted schwächste Stufe: Zugriff auf nicht geschriebene Daten, nur für read only Transaktionen (sonst wäre lost update möglich!) 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 h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 25

26 Wiederholung DB (Bachelor) Auswirkung der Isolationsstufen Konsistenzebene Anomalie dirty read non repeatable read Phantome read uncommitted read committed repeatable read serializable h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 26

27 Transaktionsverwaltung und Recovery Transaktionsverwaltung Transaktionsbegriff Synchronisation und Sperren Isolation Level in SQL MVCC Hierarchische Sperren Isolation Level und Sperren in relationalen DBMS Recovery Fehlerklassen Recovery-Strategien h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 27

28 MVCC: Motivation Vorbetrachtung T 1 liest x ( r 1 (x) c 1 ) T 2 schreibt x ( w 2 (x) c 2 ) T 1 und T 2 werden gleichzeitig gestartet Was kann passieren? Komplexeres Beispiel: r 1 (x) w 1 (x) r 2 (x) w 2 (y) r 1 (y) w 1 (z) c 1 c 2 nicht konfliktserialisierbar aber: wenn r 1 (y) eine alte Version von y lesen könnte äquivalent zu r 1 (x) w 1 (x) r 1 (y) r 2 (x) w 2 (y) w 1 (z) c 1 c 2 konfliktserialisierbar! h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 28

29 MVCC: Idee Multiversionen-Synchronisation (Multiversion Concurrency Control, MVCC) Prinzip: jede Änderungsoperation w erzeugt eine neue Version des geänderten Datenbankobjekts Leseoperationen können nun auf passender ( alter ) Version lesen realisiert z.b. in Oracle, PostgreSQL, MS SQL Server (seit V 2005), IBM DB2 (seit V ), diversen analytischen DBMS und verschiedenen NoSQL-DBMS h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 29

30 Vorteile MVCC: Vorteile MVCC führt zur Entkopplung von Lese- und Änderungsoperationen Eine Lesetransaktion hat eine Sicht auf die Datenbank, als ob alle Daten am Beginn der Transaktion atomar gelesen werden Keine Synchronisation gegen Lesetransaktionen notwendig Reduktion der Konfliktwahrscheinlichkeit Beispiel: T 1 T 2 T R T R T 1 T 2 BOT w(x 0 x 1 ) w(y 0 y 1 ) commit BOT w(x 1 x 2 ) commit BOT r(y 0 ) r(x 0 ) h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 30

31 MVCC: Realisierung Änderungsoperationen müssen wie bisher synchronisiert werden Für jede Transaktion muss die (korrekte) zu lesende Version des Objekts bestimmt werden: globaler Transaktionszähler (transaction number count, TNC) für jede Transaktion: BOT-Zeitstempel bts (= aktueller TNC) und commit- Zeitstempel (dann gültiger TNC + 1) Schreibzeitstempel wts für jede Version eines geänderten Objekts (wird beim commit auf commit-zeitstempel der Transaktion gesetzt) Lesetransaktion T R hat Zugriff auf die jüngste Version von x für die gilt: wts (x) < bts (T R ) also die letztgültige Version des Objektes vor Beginn der Transaktion Effiziente Versionenverwaltung notwendig z.b. Verwaltung der Versionen der Objekte in einem Ringpuffer garbage collection (wts(x i ) < wts(x j ) < bts_min x i kann gelöscht werden) h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 31

32 Transaktionsverwaltung und Recovery Transaktionsverwaltung Transaktionsbegriff Synchronisation und Sperren Isolation Level in SQL MVCC Hierarchische Sperren Isolation Level und Sperren in relationalen DBMS Recovery Fehlerklassen Recovery-Strategien h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 32

33 Motivation Hierarchisches Sperren: Motivation Welche Probleme können bei sehr feingranularen Sperren und sehr vielen gleichzeitig aktiven Transaktionen auftreten? Sperrgranulate in relationalen DBMS: h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 33

34 Hierarchisches Sperren: Prinzip Hierarchisches Sperren (multi granularity locking, MGL) 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) h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 34

35 Hierarchisches Sperren: Ablauf 1. Sperren werden auf einem Pfad in der Reihenfolge von der Wurzel zum Zielobjekt gesetzt 2. Datenobjekt, auf dem gearbeitet werden soll, wird gesperrt: Schreiboder 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, falls keine Konflikte zu anderen Transaktionen vorhanden sind. 5. Freigabe erfolgt in umgekehrter Reihenfolge Kompatibilitätsmatrix h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 35

36 Hierarchisches Sperren: Beispiel 1(2) T 1 : Durchschnittspreis aller Produkte T 2 : Update MinMenge für Produkt New York Espresso 1 1 = 2 explizite Sperren für T 1 Quelle: Saake/Heuer/Sattler:2005 h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 36

37 Hierarchisches Sperren: Beispiel 2(2) T 1 : Durchschnittspreis aller Produkte T 2 : Update MinMenge für Produkt New York Espresso 1 1 Produkt n n = 2n + 2 explizite Sperren für T 1 (mit n = Anzahl Tupel in Relation Produkt) Quelle: Saake/Heuer/Sattler:2005 h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 37

38 Hierarchische Sperren: (De-)Escalation Lock Escalation Falls Transaktion sehr viele Sperren benötigt dynamisches Umschalten auf gröberes Granulat Beispiel: nach 1000 Satzsperren auf einer Tabelle 1 Tabellensperre erwerben Schranke ist typischer Tuning-Parameter Manchmal kann auch Lock De-Escalation sinnvoll sein Erwerbe grob-granulare Sperre (z.b. für Tabelle) vermerke referenzierte Objekte auf fein-granularer Ebene (z.b. Sätze) bei Konflikt(en): Umschalten auf feine Sperren Anmerkung: In DBMS i.a. auch explizites Sperren von Tabellen durch Benutzer / Anwendungsprogramm möglich h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 38

39 Transaktionsverwaltung und Recovery Transaktionsverwaltung Transaktionsbegriff Synchronisation und Sperren Isolation Level in SQL MVCC Hierarchische Sperren Isolation Level und Sperren in relationalen DBMS Recovery Fehlerklassen Recovery-Strategien h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 39

40 Isolation Level und Sperren in Oracle MVCC Unterstützung der IL read committed und serializable SQL set transaction [ { read only read write } ] [ isolation level Oracle set transaction [ { read only read write } ] [ isolation level { read uncommitted read committed { read committed repeatable read serializable } ] serializable } ] Isolationsebenen für eine Menge von Transaktionen alter session set isolation_level <isolation_level> Hierarchische Sperren Tabellen und Zeilen Für Tabellen explizites Sperren möglich (5 verschiedene Lock-Modi) lock table <table_name> <lock_mode> h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 40

41 Isolation Level und Sperren in IBM DB2 Unterstützung aller SQL-Isolationsebenen (leider mit anderen Namen) SQL set transaction [ { read only read write } ] [ isolation level { read uncommitted read committed repeatable read serializable } ] Seit 9.7 Standardverhalten im Isolation Level CS (Cursor Stability) MVCC: currently committed semantics (implementiert mit Hilfe des Transaktionslogs) kann deaktiviert werden: update db cfg using CUR_COMMIT DISABLED Hierarchische Sperren Tabellen und Zeilen Für Tabellen explizites Sperren möglich (2 verschiedene Lock-Modi) DB2 change isolation to [ { UR CS RS RR } ] Uncommitted Read Cursor Stability Read Stability Repeatable Read lock table <table-name > in { SHARE MODE EXCLUSIVE MODE } h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 41

42 Weitere Isolationsverfahren Nicht-sperrende Verfahren Zeitstempelverfahren Optimistische Sperrverfahren Hier nicht betrachtet: Sperren in Indexstrukturen Alternative Konsistenzmodelle (BASE) siehe Kapitel Verteilte Datenbankarchitekturen h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 42

43 Zusammenfassung Transaktionsverwaltung Transaktionsbegriff Notwendigkeit der Synchronisation Serialisierbarkeitstheorie Sperrmodelle Transaktionen in SQL h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 43

44 Transaktionsverwaltung und Recovery Transaktionsverwaltung Transaktionsbegriff Synchronisation und Sperren Isolation Level in SQL MVCC Hierarchische Sperren Isolation Level und Sperren in relationalen DBMS Recovery Fehlerklassen Recovery-Strategien h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 44

45 Fehlerklassifikation 1. Transaktionsfehler 2. Systemfehler 3. Externspeicherfehler Fehlerklassifikation unterschiedliche Recovery-Maßnahmen je nach Fehlerart h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 45

46 Transaction-Recovery: Beispiel Szenario: T 1 A A B B commit T 2 C C abort Zeitachse Transaction-Recovery C muss wieder auf C zurückgesetzt werden (UNDO). h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 46

47 Transaktionsfehler ( Transaction-Recovery) Typische Transaktionsfehler Fehler im Anwendungsprogramm Transaktionsabbruch explizit durch den Benutzer Transaktionsabbruch durch das System Charakteristika Abbruch einer einzelnen(!) Transaktion kein Einfluss auf den Rest des Systems auch: lokaler Fehler Behandlung (Transaction-Recovery) Isoliertes Zurücksetzen aller Änderungen der abgebrochenen Transaktionen = lokales UNDO bzw. R1-Recovery Wichtig: von dieser Transaktion veränderte Blöcke können sich sowohl im Datenbank-Puffer als auch bereits in der materialisierten Datenbank (also auf dem Externspeicher) befinden! h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 47

48 Protokollierung von Änderungsinformation Durchgeführte Änderungen werden von den meisten DBMS in einem Log bzw. Log-Dateien protokolliert. Ein Log besteht aus Einträgen der Form: { LSN, TA, PageID, Undo, Redo PrevLSN } LSN: Log-Sequence Number = eindeutige und aufsteigende Nummerierung der Log-Einträge TA: Transaktionskennung (Nummer) PageID: Seitennummer Undo: UNDO-Information Redo: REDO-Information PrevLSN: LSN des letzten Eintrags der selben Transaktion Außerdem wird Beginn und Ende einer Transaktion vermerkt (BOT, commit, abort) h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 48

49 Log-Einträge: Beispiel LSN TA PageID Undo Redo PrevLSN #1 T 1 BOT 0 #2 T 1 27 [. A.] [. A.] #1 #3 T 2 BOT 0 #4 T 2 40 [. C.] [. C.] #3 #5 T 1 70 [. B.] [. B.] #2 #6 T 1 commit #5 Physische vs. logische Protokollierung h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 49

50 Transaction-Recovery: Beispiel (Forts.) Transaction-Recovery alle Log-Einträge von T 2 werden in umgekehrter Reihenfolge ihrer ursprünglichen Ausführung gelesen und rückgängig gemacht, d.h. die Undo- Information (alter Zustand der Seite) in die Datenbank eingebracht. LSN TA PageID Undo Redo PrevLSN #1 T 1 BOT 0 #2 T 1 27 [. A.] [. A.] #1 #3 T 2 BOT 0 #4 T 2 40 [. C.] [. C.] #3 #5 T 1 70 [. B.] [. B.] #2 #6 T 1 commit #5 #7 T 2 abort #4 h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 50

51 Systemfehler ( Crash Recovery) Typische Systemfehler DBMS-Fehler Betriebssystemfehler Hardware-Fehler Charakteristika die im DB-Puffer befindlichen Daten sind zerstört die auf dem Externspeicher befindlichen Daten (also die materialisierte Datenbank) ist jedoch unversehrt! Behandlung (Crash Recovery) Nachvollziehen der von abgeschlossenen Transaktionen nicht in die DB eingebrachten Änderungen = partielles REDO bzw. R2-Recovery Zurücksetzen der von nicht beendeten Transaktionen in die DB eingebrachten Änderungen = globales UNDO bzw. R3-Recovery h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 51

52 Crash-Recovery: Beispiel 1(2) Szenario: Systemfehler T 1 A A B B commit T 2 C C D D T 3 E E commit Zeitachse h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 52

53 Crash-Recovery: Beispiel 2(2) Situation im Puffer bzw. der Datenbank T 1 (committed) : A wurde bereits zurück geschrieben; B nicht(!) T 2 (offen) : C wurde bereits zurück geschrieben(!), D noch nicht T 3 (committed) : E wurde bereits zurück geschrieben Datenbank DB-Puffer A C D B E... h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 53

54 Crash-Recovery 3 Phasen 1. Analyse Das Log wird von Anfang bis zum Ende gelesen und ermittelt, welche Transaktionen erfolgreich beendet (committed) wurden und welche zum Fehlerzeitpunkt offen waren. 2. Wiederholung der Historie (REDO) Es werden alle(!) protokollierten Änderungen in der Reihenfolge ihrer Ausführung in die Datenbank eingebracht. 3. UNDO Die Änderungsoperationen der zum Fehlerzeitpunkt offenen Transaktionen werden rückgängig gemacht. h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 54

55 Analyse Crash-Recovery: Phase 1 Ermittlung aller abgeschlossenen Transaktionen (T 1 und T 3 ) und offenen Transaktionen (T 2 ) LSN TA PageID Undo Redo PrevLSN #1 T 1 BOT 0 #2 T 1 27 [. A.] [. A.] #1 #3 T 2 BOT 0 #4 T 2 40 [. C.] [. C.] #3 #5 T 3 44 [. E.] [. E.] 0 #6 T 3 commit #5 #7 T 1 70 [. B.] [. B.] #2 #8 T 1 commit #7 h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 55

56 Crash-Recovery: Phase 2 und 3 Phase 2 Wiederholung der Historie (REDO) Phase 3 UNDO der offenen Transaktionen A C A C A C D D D B E B E B E Datenbankzustand nach dem Systemfehler h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 56

57 Write-Ahead-Log-Prinzip (WAL) Wir haben in den Beispielen vorausgesetzt, dass die für die Recovery benötigte Information im Log steht (trotz Verlust der Hauptspeicherinformation) ist das gewährleistet? Bevor eine Transaktion festgeschrieben (committed) wird, müssen alle zu ihr gehörenden Log-Einträge ausgeschrieben werden (für das REDO im Fehlerfall). Bevor eine veränderte Seite in die Datenbank eingebracht wird, müssen alle diese Seite betreffenden Log-Einträge ausgeschrieben werden (für das UNDO im Fehlerfall). Diese beiden Forderungen werden als Write-Ahead-Log-Prinzip (WAL) bezeichnet. Anmerkung: Natürlich werden dabei nicht einzelne Log-Einträge, sondern alle Log-Einträg bis zum betroffenen sequentiell ausgeschrieben. h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 57

58 Checkpoints Problem: wenn auf der Datenbank viele Operationen ausgeführt wurden, ist das im Fehlerfall zu verarbeitende Log sehr umfangreich Optimierung: Schreiben von Checkpoints (Sicherungspunkte): Bei einem Checkpoint alle veränderten Datenbankseiten aus dem Puffer in die Datenbank schreiben und dies im Log vermerkt: { #5, CKPT } Log muss im Fehlerfall nur ab dem letzten Checkpoint analysiert werden. Checkpoint-Häufigkeit kann konfiguriert werden und ist kritisch für die Performance des Systems Häufiges Schreiben von Checkpoints: reduziert die Zeit für eine Crash-Recovery, aber kann Performance im laufenden Betrieb beeinträchtigen! h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 58

59 Checkpoints in Oracle 1(2) Parameter zur Beeinflussung der REDO-Dauer: FAST_START_MTTR_TARGET spezifiziert Erwartungswert für mittlere Recovery-Zeit (mean time to recover) früher andere Parameter (inzwischen deprecated): FAST_START_IO_TARGET spezifiziert maximale Anzahl DB-Seiten (Obergrenze) die im Recovery-Fall angewendet werden müssen oder LOG_CHECKPOINT_TIMEOUT Zeitabstand in s zwischen aktuellem Log-Ende und letztem Checkpoint oder LOG_CHECKPOINT_INTERVAL max. Anzahl von Log-Einträgen seit letztem Checkpoint h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 59

60 Checkpoints in Oracle 2(2) Messergebnisse OLTP (Online Transaction Processing), d.h. viele parallele, relativ kurze Transaktionen Puffer-Seiten a 4 Kb FAST_START_IO_TARGET Durchsatz (Transaktionen pro Minute) Crash-Recovery-Zeit disabled min 34 s min 20 s min 10 s s s Einstellung der Parameter muss anwendungsspezifisch (abhängig von Transaktionsprofil und Anforderungen an Recovery) gewählt werden. Quelle: T. Lahiri et al.: Fast-Start: Quick Fault Recovery in Oracle. Proc. ACM SIGMOD Conf., May 2001 h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 60

61 Externspeicherfehler ( Media-Recovery) Typische Externspeicherfehler Hardware-Fehler: Head-Crashes, Controller-Fehler etc. Naturgewalten wie Feuer oder Erdbeben Viren Charakteristika Die Daten der materialisierten Datenbank sind zerstört oder unbrauchbar Behandlung (Media-Recovery) Die Datenbank muss mit Hilfe einer Sicherungskopie (Backup) wiederhergestellt werden. Danach muss der letzte transaktionskonsistente Zustand wiederhergestellt werden, d.h. es alle seit der Erstellung des Backup erfolgreich beendeten Transaktionen nachvollzogen werden. Konsequenz: Die Log-Dateien müssen auf einem anderen Medium gesichert werden (z.b. anderer Rechner, Magnetband o.ä.)! h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 61

62 Media-Recovery Wichtige Unterscheidung: In welchem Zustand ist die Datenbank bei der Sicherung? Variante 1: Es sind keine Transaktionen auf der Datenbank während der Sicherung aktiv = Offline-Backup (consistent backup) Vorteil: Datenbankkopie ist in transaktionskonsistentem Zustand! Nachteil: Während der Sicherung darf keine (Schreib-)Transaktion auf der Datenbank aktiv sein! (vielfach nicht akzeptabel, z.b. 24h Betrieb im Internet bzw. bei weltweit agierenden Unternehmen) Variante 2: Es können Transaktionen auf der Datenbank während der Sicherung aktiv sein = Online-Backup (inconsistent backup) Vorteil: Datenbankbetrieb wird nicht (oder kaum) beeinträchtigt Nachteil: Datenbankkopie ist nicht in transaktionskonsistentem Zustand Wiederherstellung (Recovery) aufwändiger Kommerzielle DBMS unterstützen heute meist(!) beide Varianten. h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 62

63 Media-Recovery: Grundprinzip 1(2) Gesicherte Daten (Offline-Backup): Offline- Log-Datei n-4 Log-Datei n-3 Backup x Log-Datei n-2 Log-Datei n-1 Log-Datei n Offline- Backup x-1 Media-Recovery Letzte Sicherungskopie der Datenbank wird eingespielt Nach der letzten Sicherung erstellte Log-Dateien werden analysiert und die Änderungen erfolgreich beendeter Transaktionen nachvollzogen (REDO) (Bemerkung: aus Performance-Gründen kann auch eine Vorgehensweise analog zur Crash-Recovery gewählt werden: komplette Historie wiederholen und danach Undo der Änderungen offener Transaktionen.) Zeit Offline- Backup x Log-Datei n-2 Log-Datei n-1 Log-Datei n h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 63 Zeit

64 Media-Recovery: Grundprinzip 2(2) Gesicherte Daten (Online-Backup): Online- Log-Datei n-4 Log-Datei n-3 Backup x Log-Datei n-2 Log-Datei n-1 Log-Datei n Online- Backup x-1 Media-Recovery Letzte Sicherungskopie der Datenbank wird eingespielt Es müssen auch Log-Dateien vor dem letzten Backup betrachtet werden, da die Sicherungskopie u.u. Änderungen von später nicht erfolgreich beendeten Transaktionen enthält. Die Undo-Information dieser Transaktionen wird benötigt. Recovery zeitaufwändiger und Administration (Aufbewahren der Log- Dateien) aufwändiger Zeit Log-Datei n-4 Log-Datei n-3 Online- Backup x Log-Datei n-2 Log-Datei n-1 Log-Datei n h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 64 Zeit

65 Inkrementelles Backup Bei großen Datenbanken ist eine Komplettsicherung sehr(!) zeitaufwändig Sicherung der veränderten Datenbankseiten = inkrementelles Backup Bei der Wiederherstellung wird das letzte Full Backup und alle danach erstellten inkrementellen Backups eingespielt und danach nur die Log-Dateien (Annahme: offline Backup) nach dem letzten inkrementellen Backup angewandt: h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 65

66 Weitere Backup-Varianten Die bereits aufgeführten Backup-Varianten Online vs. Offline Backup Komplettes Backup vs. inkrementelles Backup können orthogonal mit weiteren Backup-Varianten kombiniert werden: Partielles Backup (Backup von Teilen der Datenbank z.b. Tablespaces) Paralleles Backup h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 66

67 Point-In-Time-Recovery Szenario: Bestimmte Datensätze wurden versehentlich durch einen Anwender oder Administrator gelöscht (und die Transaktion committed!). Wie kann dieses Löschen (oder falsches Verändern o.ä.) rückgängig gemacht werden? Ansatz 1: Undo-Information der entsprechenden Transaktion anwenden. Probleme? Ansatz 2: Wiederherstellung der Datenbank bis zu einem definierten Zeitpunkt vor dem Fehler ( Simulation eines Systemfehlers zu diesem Zeitpunkt) = Point-In-Time-Recovery Probleme? h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 67

68 Backup und Recovery Backup- und Recovery-Kommandos in Datenbanksystemen sind nicht standardisiert. Es gibt eine Vielzahl von Parameter (Ausgabekanäle, Parameter für Größe von Log-Dateien und Häufigkeit der Sicherung, Checkpoint- Parameter etc.) Die Wahl dieser Parameter und der Sicherungsstrategie hat erhebliche(!) Auswirkungen sowohl auf die Performance im laufenden Betrieb als auch auf die Wiederherstellungszeit im Fehlerfall. Wichtig: Spiegelung bzw. RAID-Systeme sind kein ausreichender Ersatz für regelmäßige Backups! Warum? h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 68

69 Backup und Recovery in Oracle Log-Dateien (Oracle: Redo-Log-Dateien) mehrere Redo-Log-Gruppen die zirkular beschrieben werden Parameter MAXLOGFILES (Anzahl Gruppen) und MAXLOGMEMBERS (Anzahl Log-Dateien pro Gruppe) Archivierung möglich (notwendig für Media Recovery) Wiederverwendung (überschreiben), sobald die Inhalte nicht mehr für Crash Recovery gebraucht werden und sobald Log-Datei archiviert Backup komplett und inkrementell (full vs. incremental) offline und online (consistent vs. inconsistent) partielles Backup (einzelner Tablespace oder einzelne Datei) Recovery komplette oder partielle Recovery (analog zum Backup) Point-In-Time-Recovery (incomplete recovery) für ganze Datenbank oder einzelnen Tablespace h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 69

70 Log-Dateien Backup und Recovery in IBM DB2 Log-Dateien werden entweder zirkular überschrieben oder sequentiell erzeugt und gefüllt: logarchmeth1 = off [logretain] Parameter zum Archivieren der Log-Dateien: userexit, disk, tsm, vendor Backup komplett und inkrementell offline und online partielles Backup (Tablespace) Recovery Wiedereinspielen eines Backup (restore) Anwenden der Log-Dateien (rollforward) bis zu einem bestimmten Zeitpunkt ( Point-In-Time-Recovery) oder bis zum Ende h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 70

71 Fehlerklassen Zusammenfassung Recovery Recovery-Strategien Protokollierung und Sicherungspunkte (Checkpoints) Backup-Varianten h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 71

72 Architektur von Datenbanksystemen Architektur von Datenbanksystemen Verwaltung des Hintergrundspeichers Dateiorganisation und Zugriffsstrukturen Basisalgorithmen für Datenbank-Operationen Anfrageoptimierung Transaktionsverwaltung und Recovery Verteilte Datenbankarchitekturen h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 6: Transaktionsverwaltung und Recovery 72