Kapitel 15. Transaktionen, Fehlerbehandlung, Multi-User. Prof. Dr. Wolfgang Weber Vorlesung Datenbanken

Transkript

1 Kapitel 15 Transaktionen, Fehlerbehandlung, Multi-User 1

2 Transaktionen, Fehlerbehandlung, Multi-User Transaktionskonzept Fehlerbehandlung Mehrbenutzersynchronisation 2

3 Transaktionen Warum? Beispiel 1 Was passiert, wenn während der Ausführung des unten stehenden PL/SQL- Programms das DBMS abstürzt / oder das Betriebssystem abstürzt / oder der Strom ausfällt?... begin for ProdRecord in CurProd loop if ProdRecord.MarktPreis < 100 then update Toepferprodukt_Markt set MarktPreis = MarktPreis + 10 where current of CurProd; else update Toepferprodukt_Markt set MarktPreis = MarktPreis + 20 where current of CurProd; end if; end loop; end; / 3

4 Transaktionen Warum? Beispiel 2 Was passiert, wenn während der Ausführung der unten stehenden Überweisung nach Schritt 3 das DBMS abstürzt / oder das Betriebssystem abstürzt / oder der Strom ausfällt? -- Überweisung von 50 Euro von Konto A nach Konto B Lese den Kontostand von A in die Variable a: read(a,a); Reduziere den Kontostand um 50 Euro: a:=a 50; Schreibe den neuen Kontostand in die Datenbasis: write(a,a); Lese den Kontostand von B in die Variable b: read(b,b); Erhöhe den Kontostand um 50 Euro: b:=b+50; Schreibe den neuen Kontostand in die Datenbasis: write(b,b); 4

5 Transaktion Definition Eine Transaktion ist eine Folge von Datenbankoperationen, die eine Datenbank von einem konsistenten Zustand in einen neuen konsistenten Zustand überführt und entweder ganz oder gar nicht ausgeführt wird. Gar nicht bedeutet, dass beim Abbruch einer Transaktion (egal ob explizit oder implizit), diese vollständig zurückgesetzt, d. h. alle ausgeführten Änderungen in der Datenbank rückgängig gemacht werden müssen. Eine Transaktion wird oft auch als logisch atomare Einheit oder logical unit of work bezeichnet. 5

6 Operationen zur Transaktionsverarbeitung Allgemein (unabhängig vom verwendeten Datenmodell oder DBMS): begin of transaction (BOT) Markiert den Beginn einer Transaktion. commit abort Markiert das Ende einer Transaktion. Alle Änderungen werden in der Datenbank festgeschrieben, d. h. dauerhaft in der Datenbank abgelegt. Abbruch der Transaktion (z. B. explizit durch Nutzer oder Programm oder implizit z. B. bei Connection-Verlust). Das DBMS muss sicherstellen, dass die Datenbank wieder in den Zustand zurückgesetzt wird, der vor Beginn der Transaktionsausführung existierte (rollback) auch implizit z. B. durch Trigger durchgeführte Änderungen. 6

7 Anwendung der Operationen Ausgangswerte: A = 100; B = 200 BOT read(a,a); a:=a 50; write(a,a); read(b,b); b:=b+50; write(b,b); commit A = 50; B = 250 BOT read(a,a); a:=a 50; write(a,a); abort oder BOT read(a,a); a:=a 50; write(a,a); read(b,b); b:=b+50; write(b,b); abort A = 100; B = 200 BOT read(a,a); a:=a 50; write(a,a); read(b,b); Fehler A = 100; B = 200 7

8 Transaktionen in SQL SQL-92-Standard Kein separater Befehl für begin of transaction Transaktion beginnt implizit mit der ersten Anweisung commit [ work ] rollback [ work ] -- Transaktion T1 wird implizit geöffnet update Konto set balance = balance-50 where KontoID = A ; update Konto set balance = balance+50 where KontoID = B ; -- T1 wird beendet und die Ergebnisse in der DB festgeschrieben commit work; -- neue Transaktion T2 wird implizit geöffnet insert into Konto (KontoID, Name, balance) values ( C, Meyer, 0); 8

9 Transaktionen in JDBC Transaktionskontrolle durch Methodenaufrufe der Klasse Connection setautocommit true: jedes Statement ist eine eigene Transaktion false: Transaktion wird bei erstem Statement eröffnet und mit commit beendet bzw. rollback abgebrochen commit rollback Connection con = DriverManager.getConnection(url, user, pwd);... try { con.setautocommit (false); //... update... //... update... con.commit (); } catch (SQLException e2) { con.rollback (); } 9

10 Was passiert bei Mehrbenutzerbetrieb? Beispiel 3 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 Sogenannte Lost Update Phänomen (1. write geht verloren) Zustand von A

11 Eigenschaften von Transaktionen (1/3) ACID-Paradigma für Transaktionen [Härder/Reuter:1983] Atomicity (Atomarität) Consistency (Konsistenz oder auch Integritätserhaltung) Isolation (Isolation) Durability (Dauerhaftigkeit) 11

12 Eigenschaften von Transaktionen (2/3) Atomicity (Atomarität) Transaktion wird als kleinste, nicht mehr zerlegbare Einheit behandelt, d.h. entweder werden alle Änderungen der Transaktion in der Datenbank festgeschrieben oder keine. Mechanismen zur Fehlerbehandlung notwendig. Consistency (Konsistenz oder auch Integritätserhaltung) Eine Transaktion überführt die Datenbank von einem konsistenten Zustand in einen neuen konsistenten Datenbankzustand. Zwischenzustände dürfen inkonsistent sein!, aber der resultierende Endzustand (also insbesondere auch nach einem Abbruch) muss die (evtl. im Schema definierten) Konsistenzbedingungen (z. B. referentielle Integrität) erfüllen. Mechanismen zur Konsistenzsicherung und Fehlerbehandlung notwendig. 12

13 Eigenschaften von Transaktionen (3/3) Isolation (Isolation) Nebenläufig (parallel, gleichzeitig) ausgeführte Transaktionen dürfen sich nicht gegenseitig beeinflussen. Jede Transaktion muss logisch gesehen so ausgeführt werden, als wäre sie die einzige Transaktion die während ihrer gesamten Ausführungszeit auf der Datenbank aktiv ist. Mechanismen zur Mehrbenutzersynchronisation notwendig. Durability (Dauerhaftigkeit) Nach dem erfolgreichen Abschluss einer Transaktion muss das Ergebnis dieser Transaktion dauerhaft in der Datenbank gespeichert werden, insbesondere muss eine beendete Transaktion bzw. die von ihr auf der Datenbank ausgeführten Veränderungen auch einen Systemfehler (Hardoder Software) überleben. Mechanismen zur Fehlerbehandlung notwendig. 13

14 Fragen Transaktionen Was ist Consistency? Sind während einer Transaktion Daten der Datenbank konsistent? Was passiert beim Absturz des Rechners nach Beginn, aber vor Ende der Transaktion? Was ist das Lost-Update-Phenomen? Was heißt A C I D Atomicity Consistency Isolation Durability Welche Eigenschaft ist durch das Lost Update Phänomen betroffen? 14

15 Transaktionen, Fehlerbehandlung, Multi-User Transaktionsverwaltung, Fehlerbehandlung und Mehrbenutzerverwaltung Transaktionskonzept Fehlerbehandlung Mehrbenutzersynchronisation 15

16 5.2 Fehlerbehandlung (Recovery) Mechanismen zur Fehlerbehandlung sind notwendig, um die Forderungen nach Atomarität, Konsistenz und Dauerhaftigkeit einer Transaktion zu erfüllen. 16

17 Fehlerklassifikation Lokaler Fehler (oder Abbruch) einer noch nicht festgeschriebenen Transaktion = Transaktionsfehler genau eine Transaktion ist betroffen Transaction-Recovery Fehler mit Hauptspeicherverlust = Systemfehler mehrere Transaktionen sind betroffen Crash-Recovery Fehler mit Externspeicherverlust = Gerätefehler/Medienfehler alle Transaktionen sind betroffen Media-Recovery 17

18 Exkurs Speicherhierarchie eines DBMS (1) Ein DBMS verwaltet die Daten auf sog. Pages (Datenbankseiten) Datenbankseiten haben eine feste Größe (typischerweise zwischen 512 Bytes und 8 KBytes) Datensätze, Indexeinträge etc. einer Datenbank werden in diesen Datenbankseiten gespeichert; ggf. müssen Datensätze auf mehrere Seiten verteilt werden Datenbankseite (Page) Datenbankseite (Page) A D E D G E C H E: Seitenüberspannender Datensatz Eine Datenbankseite ist die kleinste physische Einheit, die vom DBMS in den Hauptspeicher geladen werden kann 18

19 Exkurs Speicherhierarchie eines DBMS (2) Datenbankseiten im Hauptspeicher Datenbankseiten auf dem Externspeicher DB-Puffer (Cache) B A C Einlagerung A D D B E F Auslagerung C... E F A, B, C,... sind Datensätze 19

20 Exkurs Speicherhierarchie eines DBMS (3) Datenbankseiten im Hauptspeicher Datenbankseiten auf dem Externspeicher DB-Puffer (Cache) B A C Einlagerung A D D B E F Auslagerung... C' E F A, B, C,... sind Datensätze 20

21 Recovery nach Transaktionsfehler Charakteristika es ist nur eine einzelne Transaktion betroffen es ist keine Information verloren gegangen Was muss getan werden? alle Änderungen in der Datenbank, die von dieser Transaktion verursacht wurden, müssen rückgängig gemacht werden = lokales Undo bzw. R1-Recovery alle von dieser Transaktion veränderten Seiten müssen wieder in ihren ursprünglichen Zustand gebracht werden Wichtig: solche Seiten können sich sowohl im Datenbank-Puffer als auch bereits in der materialisierten Datenbank (also auf dem Externspeicher) befinden! Wieso? 21

22 Exkurs - Ersetzung von DB-Puffer-Seiten Wann werden Datenbankseiten im Puffer ersetzt? Wenn Platz für neue Datenbankseiten benötigt wird und kein Platz mehr im Puffer ist Welche Seiten werden ersetzt? Verschiedene Verfahren - z.b. die am längsten nicht mehr benutzte Seite* Dürfen Seiten von noch offenen Transaktionen ersetzt werden? Variante 1: Nein ( steal Trans offen -> Änderungen sind nur im Hauptspeicher, so lange Trans offen; force nach Transend muss geschrieben werden) Vorteil: keine Änderungen von noch offenen Transaktionen in der Datenbank auf der Platte (gut im Fehlerfall) Nachteile: Puffergröße reicht u. U. nicht (buffer overflow); Seiten die nicht mehr benötigt werden, blockieren Platz für andere Seiten (Performance ) Variante 2: Ja (steal, force) Vorteil: sehr gut für Performance. (Betriebssystem ersetzt ohne Rücksicht auf DB-System) Nachteil: Änderungen von noch offenen Transaktionen (dirty data) sind in der Datenbank und müssen im Fehlerfall zurückgesetzt werden und nach Transend nicht sofort in DB Die meisten kommerziellen DBMS setzen (heute) Variante 2 (steal) ein. * Anmerkung: Siehe Betriebssysteme. 22

23 Transaction Recovery Beispiel (1) Szenario: T 1 hat erfolgreich von Konto A x Euro auf Konto B gebucht. Parallel dazu bucht T 2 von Konto C y Euro auf Konto D. Transaktionsfehler: nach der Veränderung von C wird T 2 abgebrochen (z. B. weil Konto D gesperrt ist). T 1 A A B B commit T 2 C C abort Zeitachse 23

24 Exkurs Speicherhierarchie eines DBMS (3) Hauptspeicher Datenbankseiten auf dem Externspeicher DB-Puffer (Cache) B A C Einlagerung A D D B E F Auslagerung... C' E F 24

25 Transaction Recovery Beispiel (2) Situation im Puffer bzw. auf der Datenbank zum Fehlerzeitpunkt: T 2 hat C schon verändert (=C ) und C wurde schon in die Datenbank geschrieben. C muss in der Datenbank und Hauptspeicher wieder auf C zurückgesetzt werden (Undo). 25

26 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 (alter Zustand der Seite* = before image) Redo: Redo-Information (neuer Zustand der Seite* = after image) PrevLSN: LSN des letzten Eintrags der gleichen Transaktion Außerdem wird Beginn und Ende einer Transaktion vermerkt (BOT, commit, abort) * Anmerkung: Die Protokollierung von Seiten ist nur eine Realisierungsmöglichkeit für Log-Dateien - weitere Möglichkeiten evtl. später. 26

27 Log-Einträge Beispiel Szenario: T 1 hat erfolgreich von Konto A x Euro auf Konto B gebucht. Parallel soll T 2 von Konto C y Euro auf Konto D buchen. T 2 bricht nach Veränderung von C ab 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 27

28 Transaction Recovery Beispiel (Forts.) Fehlerbehandlung: Wieso in umgekehrter Reihenfolge? 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 und Hauptspeicher 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 28

29 Transaction-Recovery nach Abbruch und nach Zurücksetzen Datenbankzustand nach dem Abbruch der Transaktion Nach Zurücksetzen T 2 27 A 40 C D A C D 70 B E B E 29

30 Fragen Transaction Recovery Was sind Transaktionsfehler? Was ist zu machen? 30

31 Fragen Transaction Recovery Was sind Transaktionsfehler? Was ist zu machen? Genau eine Transaktion ist betroffen. Die Änderungen, die von der abgebrochenen Transaktion in der Datenbank ausgeführt wurden, werden durch sequentielles Anwenden der im Log gespeicherten Undo-Information (in umgekehrter Reihenfolge der ursprünglichen Ausführung) rückgängig gemacht = lokales Undo bzw. R1-Recovery 31

32 Recovery nach Systemfehler (Crash-Recovery) Charakteristika die im Hauptspeicher (d. h. im DB-Puffer) befindliche Information ist zerstört (z.b. Stromausfall, Rechnerabsturz o. ä.) die auf dem Externspeicher befindliche Information (also die materialisierte Datenbank) ist jedoch unversehrt! Was muss getan werden? alle Änderungen abgeschlossener Transaktionen, die noch nicht in die materialisierte Datenbank eingebracht wurden, müssen nachvollzogen werden = partielles Redo = R2-Recovery alle schon in der materialisierten Datenbank befindlichen Änderungen noch nicht abgeschlossener Transaktionen müssen rückgängig gemacht werden = globales Undo = R3-Recovery 32

33 Crash-Recovery Beispiel (1/2) Szenario: T 1 hat erfolgreich A und B verändert und committed. T 2 hat C verändert, D noch nicht. T 3 hat E verändert und committed. Es tritt ein Stromausfall auf = Systemfehler Systemfehler T 1 A A B B commit T 2 C C T 3 E E commit Zeitachse 33

34 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 T 3 (committed) : E wurde bereits zurück geschrieben Wieso nicht, trotz commit? Datenbank DB-Puffer A C D B E... 34

35 Einbringen von Änderungen einer Transaktion Wann werden Änderungen einer Transaktion in die materialisierte Datenbank eingebracht? Wir haben Variante 2! Variante 1: spätestens zum commit-zeitpunkt (force) Vorteil: alle Änderungen erfolgreich beendeter Transaktion sind in der Datenbank enthalten und müssen im Fehlerfall nicht nachvollzogen werden. Nachteil: sehr teuer warten auf viele (langsame) Schreiboperationen auf Externspeicher! Variante 2: irgendwann, d.h. wenn die Datenbankseite durch den Pufferersetzungsalgorithmus d. Betriebssystems im Puffer ersetzt wird ( force) Vorteil: Performance (keine teuren Schreiboperationen beim commit) Nachteil: Änderungen erfolgreich abgeschlossener Transaktionen sind nicht notwendigerweise in der Datenbank enthalten (muss im Fehlerfall beachtet werden!) Die meisten kommerziellen DBMS setzen (heute) Variante 2 ( force) ein. Frage: Wie finde ich heraus, welche Transaktionen beendet sind, aber noch nicht ganz rausgeschrieben -> Zurück zum Anfang der Log-Datei - zu aufwendig 35

36 Savepoints und Checkpoints Savepoints: Es wird gewartet, bis alle Transaktionen beendet sind. Totalsicherung der Datenbank auf sicheres Medium. Sehr aufwendig, man kann diese Totalsicherung nicht sehr häufig durchführen Checkpoints: Bei einem Checkpoint werden alle veränderten Datenbankseiten aus dem Puffer in die Datenbank geschrieben und dies im Log vermerkt: { #5, CKPT } Log muss im Fehlerfall nur ab dem letzten Checkpoint analysiert werden. allerdings: Zum Zeitpunkt des Checkpoints können offene Transaktionen existieren! 36

37 Crash-Recovery nach Savepoint 3 Phasen nach Savepoint 1. Analyse Das Log wird vom letzten Savepoint bis zum Ende gelesen und ermittelt, welche Transaktionen erfolgreich beendet (committed) wurden welche zum Fehlerzeitpunkt offen waren. 2. Die Sicherung wird eingespielt. 3. Wiederholung der Historie (Redo) Es werden die protokollierten Änderungen der abgeschlossenen Transaktionen in der Reihenfolge ihrer Ausführung in die Datenbank eingebracht. (Anfang = letzter Savepoint) 37

38 Crash-Recovery nach Checkpoint 3 Phasen nach Checkpoint 1. Analyse Das Log wird vom letzten Checkpoint bis zum Ende gelesen und ermittelt, welche Transaktionen erfolgreich beendet (committed) wurden 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. (Anfang = letzter Checkpoint) 3. Undo Die Änderungsoperationen der zum Fehlerzeitpunkt offenen Transaktionen werden rückgängig gemacht. (evtl. über den letzten Checkpoint zurück!) 38

39 Crash-Recovery Phase 1: Analyse 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 Analyse #3 T 2 BOT 0 #4 T 3 BOT 0 #4 T 2 40 [. C.] [. C.] #3 #6 T 3 44 [. E.] [. E.] #4 #7 T 3 commit #6 #8 T 1 70 [. B.] [. B.] #2 #9 T 1 commit #8 39

40 Crash-Recovery nach Savepoint Datenbankzustand nach dem Systemfehler Phase 1 Analyse nach Phase 2: Phase 3 Wiederholung der abgeschlossenen Transaktionen (Redo) A C D A C D A C D B E B E B E Frage: Wie wird Crash-Recovery nach Checkpoint durchgeführt? ungleich Zustand vor Crash. (Hauptspeicher ist leer, B' auf Platte!) (offene Transaktionen sind abgebrochen) 40

41 Crash-Recovery nach Checkpoint Phase 2 und 3 Datenbankzustand nach dem Systemfehler Phase 1 Analyse Phase 2 Wiederholung der Historie (Redo) seit Checkpoint Phase 3 Undo der offenen Transaktionen A C D A C D A C' D A C D B E B E B E B E ungleich Zustand vor Crash. (Hauptspeicher ist leer, B' auf Platte!) (offene Transaktionen sind abgebrochen) 41

42 Write-Ahead-Log-Prinzip (WAL) Anmerkung: 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? Wann müssen wir Log-Info schreiben? 1. Bevor eine Transaktion festgeschrieben (committed) wird, müssen alle zu ihr gehörenden Log-Einträge ausgeschrieben werden (für das Redo im Fehlerfall). 2. 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. 42

43 Checkpoints Checkpoint-Häufigkeit kann i. a. durch den DBA konfiguriert werden Häufiges Schreiben von Checkpoints: reduziert die Zeit für eine Crash-Recovery, aber kann Performance im laufenden Betrieb beeinträchtigen! Oracle-Beispiel: siehe nächste Folie Weitere Optimierungsmöglichkeiten (z. B. nicht Seiten Ausschreiben, sondern nur Informationen über den Status des Puffers bzw. des Ausschreibens merken ) 43

44 Checkpoints in Oracle (1/2) 4 (bzw. 3) Parameter können zur Beeinflussung der Redo-Dauer konfiguriert werden: FAST_START_IO_TARGET: spezifiziert maximale Anzahl DB-Seiten (Obergrenze) die im Recovery-Fall wiederhergestellt werden müssen. Dieser Parameter ist inzwischen in Oracle deprecated (nicht mehr angebbar) statt dessen: FAST_START_MTTR_TARGET: spezifiziert Erwartungswert für mittlere Recovery-Zeit (mean time to recover) LOG_CHECKPOINT_TIMEOUT: Zeitabstand in sek. zwischen aktuellem Log- Ende und letztem Checkpoint LOG_CHECKPOINT_INTERVAL: max. Anzahl von Log-Einträgen seit letztem Checkpoint 44

45 Checkpoints in Oracle (2/2) Messergebnisse [1] 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. [1] T. Lahiri et al.: Fast-Start: Quick Fault Recovery in Oracle. Proc. ACM SIGMOD Conf., May

46 Fragen Crash-Recovery Was ist unter dem Begriff Crash-Recovery zu verstehen? Was ist im Fehlerfall zu machen? 46

47 Crash-Recovery Zusammenfassung Was ist unter dem Begriff Crash-Recovery zu verstehen? Was ist im Fehlerfall zu machen? Crash-Recovery wird nach Systemfehler (Hauptspeicherverlust) durchgeführt Nach einem Systemfehler: z. B. Recovery nach Checkpoint: Herausfinden offene Transaktionen alle Änderungen, die noch nicht in die materialisierte Datenbank eingebracht wurden, müssen nachvollzogen werden = partielles Redo = R2-Recovery alle schon in der materialisierten Datenbank befindlichen Änderungen noch nicht abgeschlossener Transaktionen müssen rückgängig gemacht werden = globales Undo = R3-Recovery Dies geschieht durch 1. Analyse der Log-Einträge zur Ermittlung der abgeschlossenen und offenen Transaktionen 2. Wiederholung aller protokollierten Änderungen (Redo) 3. Rücknahme aller Änderungen offener Transaktionen (Undo) 47

48 Recovery nach Externspeicherfehler (Media-Recovery) Charakteristika Durch einen Externspeicherfehler (Hardware-Defekt, Virus, ) ist die materialisierte Datenbank zerstört oder unbrauchbar. Frage: Wie kann man die Datenbank wiederherstellen? Die Datenbank muss mit Hilfe einer Sicherungskopie (Savepoint) wiederhergestellt werden (Backup). Danach muss der letzte transaktionskonsistente Zustand wiederhergestellt werden und es müssen alle seit der Erstellung der Sicherungskopie ausgeführten und erfolgreich beendeten Transaktionen nachvollzogen werden. (wie beim Crash-Recovery nach Savepoint) Die Log-Dateien müssen beim Schreiben automatisch gesichert werden (z.b. auf einen anderen Rechner, ein Magnetband o. ä.)! Frage: Nutzt uns hier ein Checkpoint etwas? Nein 48

49 Media-Recovery - Sicherung 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 (wie auf vorhergehenden Folien angenommen) = 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. 49

50 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 nach Externspeicherfehler: 1. Letzte Sicherungskopie der Datenbank wird eingespielt 2. Nach der letzten Sicherung (Savepoint) erstellte Log-Dateien werden analysiert und die Änderungen erfolgreich beendeter Transaktionen nachvollzogen (Redo) Frage: Kann auch eine Vorgehensweise analog zur Crash-Recovery nach Checkpoint gewählt werden: komplette Historie wiederholen und danach Undo der Änderungen offener Transaktionen. Nein, Daten auf Externspeicher sind ja weg Zeit Offline- Backup x Log-Datei n-2 Log-Datei n-1 Log-Datei n Keine Trasaktionen offen! 50 Zeit

51 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 nach Externspeicherfehler: 1. Letzte Sicherungskopie der Datenbank wird eingespielt 2. 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 Beginn Trans. 1 Zeit Trans. 1 noch nicht beendet Log-Datei n-4 Log-Datei n-3 Online- Backup x Log-Datei n-2 Log-Datei n-1 Log-Datei n 51 Zeit

52 Inkrementelles Backup Bei großen Datenbanken ist eine Komplettsicherung sehr(!) zeitaufwändig 1. Full Backup später: Sicherung der veränderten Datenbankseiten =. inkrementelles Backup, Delta-Sicherung 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: 52

53 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? 53

54 Backup- und Recovery-Kommandos Sind nicht standardisiert (weder in SQL noch JDBC o. ä.) Syntax ist in jedem DBMS anders, insbesondere gibt es 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. 54

55 Frage Welche Arten von Fehlern gibt es? Was wird durch die Fehlerbereinigung erreicht? Nach dem Auftreten eines Fehlers wird die DB wieder in einen konsistenten Zustand gebracht. Wie geschieht dies? Fragen Media Recovery: Was ist Media Recovery? Was ist zu machen bei Wiederherstellung (Verfahren)? Was ist offline Backup? /online-backup? Was ist Inkrementelles Backup? 55

56 Transaktionen, Fehlerbehandlung, Multi-User Transaktionsverwaltung, Fehlerbehandlung und Mehrbenutzerverwaltung Transaktionskonzept Fehlerbehandlung Mehrbenutzersynchronisation Frage: Was ist das ACID-Paradigma für Transaktionen? (S. 9) Welche Punkte von ACID sind bereits behandelt, welche fehlen? 56

57 Eigenschaften von Transaktionen Was heist ACID? Atomicity (Atomarität) Transaktion wird als kleinste, nicht mehr zerlegbare Einheit behandelt, d.h. entweder werden alle Änderungen der Transaktion in der Datenbank festgeschrieben oder keine. Consistency (Konsistenz oder auch Integritätserhaltung) Eine Transaktion überführt die Datenbank von einem konsistenten Zustand in einen neuen konsistenten Datenbankzustand, d.h. der resultierende Endzustand (also insbesondere auch nach einem Abbruch) muss die im Schema definierten Konsistenzbedingungen erfüllen.? Isolation (Isolation) Nebenläufig (parallel, gleichzeitig) ausgeführte Transaktionen dürfen sich nicht gegenseitig beeinflussen, d.h. jede Transaktion muss logisch gesehen so ausgeführt werden, als wäre sie die einzige Transaktion die während ihrer gesamten Ausführungszeit auf der Datenbank aktiv ist. Durability (Dauerhaftigkeit) Nach dem erfolgreichen Abschluss einer Transaktion muss das Ergebnis dieser Transaktion dauerhaft in der Datenbank gespeichert werden, insbesondere muss eine beendete Transaktion bzw. die von ihr auf der Datenbank ausgeführten Veränderungen auch einen Systemfehler (Hard- oder Software) überleben. 57

58 5.3 Mehrbenutzersynchronisation Bei der gleichzeitigen Ausführung mehrerer Transaktionen können verschiedene Effekte (Anomalien) auftreten, die für den Anwender i.a. nicht akzeptabel sind Klassifikation dieser Anomalien und Identifikation von Mechanismen, um diese zu vermeiden. 58

59 Verlorengegangene Änderungen (Lost Update) Zwei Programme ( Überweisung und Zinsgutschrift ) arbeiten gleichzeitig auf der Datenbank: (S. 10) 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 Problem? 59

60 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? 60

61 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? 61

62 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. Problem? 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 62

63 Modell der Serialisierbarkeit (1/2) Wie können die aufgezeigten Anomalien vermieden werden? Ansatz 1: Transaktionen werden nacheinander (seriell) ausgeführt Performance Ansatz 2: Transaktionen werden so ausgeführt, dass das Ergebnis auf der Datenbank das gleiche ist, wie bei einer Ausführung nacheinander (logischer Einbenutzerbetrieb) = Serialisierbarkeit: Definition: 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. 63

64 Modell der 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 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. Wie garantieren wir, dass bei paralleler Ausführung gleiche Werte entstehen wie bei Hintereinanderausführung? Sperren von Objekten, so dass Transaktionen sich nicht "in die Quere kommen". T 2-1 T 2-2 T 2-3 T 3-1 T 3-2 T 1-1 T 1-2 T

65 Zwei-Phasen-Sperrprotokoll (2PL) (1/2) Jedes Objekt, das von einer Transaktion benutzt werden soll, muss vorher entsprechend gesperrt werden. Eine Transaktion fordert eine Sperre, die sie schon besitzt, nicht erneut an. Eine Transaktion muss die Sperren anderer Transaktionen auf dem von ihr benötigten Objekt gemäß der Verträglichkeitstabelle beachten. Wenn die Sperre nicht gewährt werden kann, wird die Transaktion in eine entsprechende Warteschlange eingereiht bis die Sperre gewährt werden kann. Jede Transaktion durchläuft zwei Phasen: Eine Wachstumsphase, in der sie Sperren anfordern, aber keine freigeben darf und eine Schrumpfphase, in der sie ihre bisher erworbenen Sperren freigibt, aber keine weiteren anfordern darf. Bei EOT (Transaktionsende) muss eine Transaktion alle ihre Sperren zurückgeben. 65

66 Zwei-Phasen-Sperrprotokoll (2PL) (2/2) #Sperren Kein Lost Update BOT Wachstum Schrumpfung EOT Zeit 66

67 Verzahnung zweier TAs gemäß 2PL T 1 modifiziert nacheinander die Datenobjekte A und B (z. B. eine Überweisung) T 2 liest nacheinander dieselben Datenobjekte A und B (z. B. zur Aufsummierung der beiden Kontostände). 67

68 2PL Beispiel Zeit T 1 T 2 Bemerkung 1 BOT 2 lockx(a) 3 read(a) 4 write(a) 5 BOT 6 locks(a) T 2 muss warten 7 lockx(b) 8 read(b) 9 unlockx(a) T 2 wecken 10 read(a) 11 locks(b) T 2 muss warten Frage: Welche Transaktion wurde logisch zuerst ausgeführt? 12 write(b) 13 unlockx(b) T 2 wecken 14 read(b) 15 commit Bem: lockx= Exclusive Lock, locks = Shared Lock 16 unlocks(a) 17 unlocks(b) 18 commit 68

69 Probleme bei 2PL 2PL garantiert Serialisierbarkeit in einer fehlerfreien Umgebung. Frage: Ist Dirty Read gelöst? Was passiert, wenn T 1 nach Schritt 11 zurück gesetzt wird? Fehler während Schrumpfungsphase können zu Dirty Read (Schritt 10) etc. führen. Lösungsalternativen zur Vermeidung von Dirty Reads Variante 1: Lesen schmutziger Daten und Abhängigkeiten bei commit überprüfen (Problem: kaskadierende Rollbacks). Variante 2 (besser): Strenges Zwei-Phasen-Sperrverfahren mit Sperrfreigabe nach commit. 69

70 Strenges Zwei-Phasen Sperrprotokoll 2PL schließt kaskadierendes Rücksetzen nicht aus => Erweiterung: strenges 2PL: alle Sperren werden bis EOT gehalten damit ist kaskadierendes Rücksetzen ausgeschlossen #Sperren Kein Lost Update, kein Dirty Read BOT EOT Zeit 70

71 Verklemmungen (Deadlocks) (1/3) T 1 modifiziert nacheinander die Datenobjekte A und B. T 2 liest nacheinander dieselben Datenobjekte B und A. Zeit T 1 T 2 Bemerkung 1 BOT 2 lockx(a) 3 BOT 4 locks(b) 5 read(b) 6 read(a) 7 write(a) 8 lockx(b) T 1 muss auf T 2 warten 9 locks(a) T 2 muss auf T 1 warten Deadlock 71

72 Verklemmungen (Deadlocks) (2/3) Deadlocks können anhand von Wartegraphen erkannt werden T 1 modifiziert nacheinander die Datenobjekte A und B. T 2 liest nacheinander dieselben Datenobjekte B und A. T 1 muss auf T 2 warten T 2 muss auf T 1 warten => ZYKLUS! T 1 T 2 Durch Abbruch von T 1 oder T 2 kann die Verklemmung aufgelöst werden Generell: Zyklenerkennung durch Tiefensuche im Wartegraphen. Verschiedene Strategien, welche Transaktion abgebrochen wird (ältere, jüngere, ). 72

73 Verklemmungen (Deadlocks) (3/3) Alternative Variante zur Vermeidung von Verklemmung: Preclaiming in Verbindung mit dem strengen 2 PL-Protokoll Lost Update gelöst? Dirty Read gelöst? Phantom-Problem gelöst? #Sperren Kein Lost Update kein Dirty Read, kein Deadlock BOT EOT Zeit 73

74 Phantom-Problem Sperren als Lösung? Problem: Ein Objekt, das es noch gar nicht gibt kann auch nicht gesperrt werden. 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; Lösung? 74

75 Phantom-Problem Lösung Zusätzlich zu den Tupeln muss auch den Zugriffweg, auf dem man zu den Objekten gelangt ist, gesperrt werden Beispiel: select count(*) into X from Mitarbeiter; alle Mitarbeiter und deren Primärschlüssel-Index müssen mit einer S-Sperre belegt werden beim Einfügen eines neuen Mitarbeiters wird dies erkannt und T2 muss warten Sperre kann ggf. auch selektiver sein z.b.: select count(*) into X from Mitarbeiter where PNr between 1000 and 2000 Kein Lost Update kein Dirty Read, kein Deadlock keine Phantome nur die Mitarbeiter mit der entsprechenden PNr müssen gesperrt werden (z.b. Index-Bereich von PNr[1000,2000]) 75

76 Isolation Level in SQL92 (1/4) set transaction [read only, read write,] [isolation level read uncommitted read committed repeatable read serializable] Default- Werte nach SQL92 Beispiel (erstes Statement innerhalb der Transaktion!) set transaction read only, isolation level read committed; select...; commit; 76

77 Isolation Level in SQL92 (2/4) read uncommitted Schwächste Konsistenzstufe. Read-Operationen ignorieren jegliche Sperre Eine derartige Transaktion hat Zugriff auf noch nicht festgeschriebene Daten, z.b.: T 1 T 2 read(a) read(a)... write(a) Lost Update, Dirty Read, Unrepeatable Read und Phantome möglich.... rollback 77

78 Isolation Level in SQL92 (3/4) read committed Solche Transaktionen lesen nur festgeschriebene Werte. Setzt Schreibsperren ein, Lesesperren nur beim tatsächlichen Lesen. kein Dirty Read möglich. Allerdings kann eine solche Transaktion u.u. unterschiedliche Zustände der Datenbank-Objekte sehen: T 1 T 2 read(a) write(a) write(b) commit read(b) read(a)... Lost Update, Unrepeatable Read und Phantome möglich. 78

79 Isolation Level in SQL92 (4/4) repeatable read strenges 2PL-Protokoll und Sperren für Lese- und Schreiboperationen. Unrepeatable Read wird durch diese Konsistenzstufe ausgeschlossen. Phantome sind in dieser Konsistenzstufe immer noch möglich. serializable Diese Konsistenzstufe garantiert die Serialisierbarkeit = default. Abbruch von Transaktion durch DBS möglich (bei Deadlock) 79

80 Zusammenfassung Isolation Level in SQL92 Isolationsebene Lost Updates Dirty Read Non- Repeatable Read Phantom Read Uncommitted Read Committed Repeatable Read möglich möglich möglich möglich möglich unmöglich möglich möglich unmöglich unmöglich unmöglich möglich Serializable unmöglich unmöglich unmöglich unmöglich 80

81 Sperren Wie löse ich das Problem, ohne strenge Serialisierung von Transaktionen? Lösungsansatz: Sperren Zwei Sperrmodi S (shared, read lock, Lesesperre): X (exclusive, write lock, Schreibsperre): Verträglichkeitsmatrix (Kompatibilitätsmatrix) S X S ok ok? X ok? ok? 81

82 Isolation Level in Oracle / SQL92-Standard Oracle set transaction [read only, read write,] [isolation level read committed serializable] SQL92 set transaction [read only, read write,] [isolation level read uncommitted read committed repeatable read serializable] 82

83 Isolation Level in JDBC Isolation Level können durch die Methode settransactionisolation() der Klasse Connection gesetzt werden: TRANSACTION_NONE TRANSACTION_READ_UNCOMMITTED TRANSACTION_READ_COMMITTED TRANSACTION_REPEATABLE_READ TRANSACTION_SERIALIZABLE Connection con = DriverManager.getConnection(url, user, pwd);... try { con.settransactionisolation (TRANSACTION_SERIALIZABLE); //... update... WICHTIG: Natürlich muss das angesprochene DBMS die entsprechenden Isolation Level unterstützen bzw. geeignet abbilden! JDBC bietet Methoden der DatabaseMetaData Klasse zur Ermittlung der Eigenschaften des DBMS, u.a. getdefaulttransaction-isolation( ) supportstransactions( ) supportstransactionisolationlevel( ) 83