Wiederanlauf (Recovery)

Transkript

1 DEVO 8.1 Wiederanlauf (Recovery)

2 DEVO 8.2 Ziele Wiederherstellung eines konsistenten Datenbankzustandes nach einem Fehler. Fehler: Transaktionsabbruch: eine Transaktion muß nach einem logischen Fehler (z.b. Konto nicht gedeckt ) abgebrochen werden. Systemfehler: alle Änderungen, die nur im Hauptspeicher, aber noch nicht auf der Festplatte durchgeführt wurden, gehen verloren. Plattenfehler: alle Änderungen, die seit der letzten Sicherung auf der Festplatte durchgeführt wurden, gehen verloren.

3 DEVO 8.3 Korrektes Wiederanlaufverfahren garantiert Dauerhaftigkeit und Atomarität. Abbruch von Transaktionen: selbst (z.b. durch Programmierer oder durch Laufzeitfehler im Anwendungsprogramm) oder durch DBMS (z.b. durch Concurrency Control oder bei Auftreten von Deadlocks). Teilweise durchgeführte Transaktionen soll keinerlei Effekt auf die Datenbank haben. (Rückwärts-Recovery, Rollback) Synchronisationspunkte: Punkte innerhalb einer Transaktion, Rückgängigmachen nur bis zu diesem Punkt nötig.

4 DEVO 8.4 Beispiel 1 Bankenszenario (Umbuchung) Datenstruktur: SPARBUCH (SPNR, EINLAGE, BESITZER) KONTO (KNR, KSTAND) SPAREINLAGEN GESAMT Integritätsbedingung: KSTAND >= 0 EINLAGE > 0 SPAREINLAGEN GESAMT = Summe EINLAGE

5 DEVO 8.5 Transaktion: Umbuchung von 50 ÖS von Konto 123 auf das Sparbuch 321 begin transaction update KONTO set KSTAND=KSTAND-50 where KNR=123; update SPARBUCH set EINLAGE=EINLAGE+50 where SPNR=321 SPAREINLAGEN_GESAMT:= SPAREINLAGEN_GESAMT+50 end transaction Systemabsturz während einer Umbuchung: einseitige Buchung möglich. Systemanlauf: konsistenter DB-Zustand (d.h. Buchungen werden vollständig durchgeführt oder gar nicht) muß hergestellt werden.

6 DEVO 8.6 Beispiel 2 T1, T2 und T3 sind beim Systemabsturz abgeschlossen Dauerhaftigkeit muß gewährt sein. Für Atomarität: T4 und T5 müssen rückgängig gemacht werden, da sie nicht abgeschlossen sind. T1 T2 T3 T4 T5 Zeit Absturz

7 DEVO 8.7 Reihenfolge von Ausführungen Eine Transaktion Tj liest X von einer Transaktion Ti falls: 1. Tj liest X zum Zeitpunkt t j, Ti schreibt X zum Zeitpunkt ti, und ti < t j. 2. Ti wird nicht vor t j abgebrochen, 3. jede Transaktion Tk, die X zum Zeitpunkt tk,ti < tk < t j schrieb, wurde vor t j abgebrochen.

8 DEVO 8.8 Beispiel 3 kein Tk schreibt auf X Ti write(x) Tj read(x)

9 DEVO 8.9 Nichtwiederherstellbare Ausführung Beispiel 4 Systemabsturz Zurücksetzung von T3 Da x bereits freigegeben und von T1 und T2 gelesen wurde, müssen T1 und T2 wegen Atomarität zurückgesetzt werden (Cascading Abort). T1 und T2 waren erfolgreich abgeschlossen Verletzung der Dauerhaftigkeit. T1 read x read y T2 read x write y T3 write x read y Zeit Absturz

10 DEVO 8.10 Problem: Zurücksetzen von Transaktionen: Bereits erfolgreich abgeschlossene Transaktionen werden kaskadenartig zurückgesetzt Dauerhaftigkeit wird verletzt. Lösung: Transaktion gibt Änderungen erst frei, wenn sichergestellt ist, daß die Transaktion ordnungsgemäß beendet werden kann (Isolation). Praxis: Einführung der Isolation um Widerspruch zwischen Dauerhaftigkeit und Zurücksetzen zu verhindern Widerherstellbarkeit ist garantiert.

11 DEVO 8.11 ACA Ausführung Problem: kaskadierendes Zurücksetzen Beispiel 5 T2 muß bei einem COMMIT-Request abbrechen. T1 T2 1. WRITE(X) 2. READ(X) 3. ABORT Ausführung I verhindert kaskadierendes Zurücksetzen (avoids cascading abort, ACA), wenn für jedes Ti und Tj, i j gilt: wenn Ti X von Tj liest, dann ist Tj bereits erfolgreich abgeschlossen, i.e. Commit von Tj kommt vor READi(X) von Ti in I.

12 DEVO 8.12 Zurücksetzen einer Transaktion Typische Implementierungsmöglichkeit: Merken des alten Wertes bei WRITE (Before Image) Restaurieren des alten Wertes nach dem Before Image nur korrekt, wenn Transaktionen Objekte nur dann schreiben, wenn sie zuletzt von erfolgreich abgeschlossenen Transaktionen geschrieben wurden.

13 DEVO 8.13 Beispiel 6 Before Image für X in T1 ist 1, Before Image für X in T2 ist 2. ABORT von T1: Undo von WRITE(X,2) setzt X:=1 Danach ABORT von T2: Undo von WRITE(X,3) setzt X:=2 Reihenfolge der Rücksetzung abhängig vom Startzeitpunkt. T1 WRITE(X,2) T2 WRITE(X,3) x=1 x=2 x=3 x=3

14 DEVO 8.14 Strikte Ausführung Eine Ausführung I von Transaktionen ist strikt (ST), wenn für jede Transaktion gilt: Ti liest und schreibt nur Objekte X, die zuletzt von erfolgreich abgeschlossenen Transaktionen Tj geschrieben wurden. Praxis: (2-Phasen Sperrverfahren garantiert Strictness) Alle WRITE-Befehle werden bis zum locked point verzögert UNLOCK-Befehle werden bis Transaktionsende verzögert alle UNLOCKs werden zu einem Befehl (COMMIT) zusammengefaßt COMMIT = Ende der Transaktion.

15 DEVO 8.15 Es gilt folgende Beziehung: seriell ST ACA Ausführungen serialisierbar ACA ST seriell Ab hier wird immer Strictness angenommen.

16 DEVO 8.16 Pufferverwaltung Drei Arten von Speicher: Hauptspeicher (volatile storage) Hintergrundspeicher (non-volatile storage): z.b.: Festplatte Stabiler Speicher (stable storage): Information geht nicht verloren. (Annahme!)

17 DEVO 8.17 T 1 T 2... Tn READ, WRITE, COMMIT, ABORT TRANSACTION MANAGER READ, WRITE, COMMIT, ABORT SCHEDULER RESTART (SYSTEMFEHLER) READ, WRITE, COMMIT, ABORT FETCH, FLUSH RECOVERY MANAGER READ, WRITE Persistenter Speicher INPUT, OUTPUT CACHE MANAGER INPUT, OUTPUT Hauptspeicher (CACHE) Stabiler Speicher (LOG) DATA MANAGER

18 DEVO 8.18 Zugriff auf Blöcke des Hintergrundspeichers input(a) A B B output(b) Hauptspeicher Platte input(x) überträgt den physischen Block, der das Datenobjekt X enthält, in den Hauptspeicher (Puffer). output(x) überträgt den Pufferblock, der das Datenobjekt X enthält, auf die Festplatte und ersetzt dort den entsprechenden physischen Block.

19 DEVO 8.19 Programmzugriff auf DB read(x,xi) weist den Wert des Datenobjekts X der Programmvariable xi zu. 1. Ist der Block, auf dem sich X befindet, noch nicht im Hauptspeicher, dann führe input(x) aus. 2. Weise xi den Wert von X im Pufferblock zu. write(x,xi) weist den Wert der Programmvariable xi dem Datenobjekt X im Pufferblock zu. 1. Ist der Block, auf dem sich X befindet, noch nicht im Hauptspeicher, dann führe input(x) aus. 2. Ersetze den Wert von X im Pufferblock durch den Wert von xi.

20 DEVO 8.20 Puffer als Cache Änderungen im Puffer werden nicht immer sofort auf Hintergrundspeicher übertragen. Effizienz: Datenobjekt, auf das oft zugegriffen wird, länger im Puffer behalten. Übertragung des Pufferblocks vom Pufferverwalter auf die Festplatte wenn 1. Puffer wird zu klein, 2. vom Wiederanlaufverwalter verlangt (forced write).

21 DEVO 8.21 Absturz Mögliche inkonsistente Datenbankzustände: Änderungen abgeschlossener Transaktionen nur im Puffer, aber noch nicht auf der Festplatte. Änderungen noch nicht abgeschlossener Transaktionen bereits auf der Festplatte.

22 DEVO 8.22 Beispiel 7 T: read(a,a1) a1:=a1-50 write(a,a1) read(b,b1) b1:=b write(b,b1) A=1000 A=1000 B=2000 Hauptspeicher Platte

23 DEVO 8.23 A=950 A=1000 B=2000 B=2000 Hauptspeicher Platte A=950 A=1000 B=2050 B=2000 Hauptspeicher Platte Nach Abschluß der Transaktion: Änderungen nur im Hauptspeicher, aber nicht auf der Platte.

24 DEVO 8.24 Privater Arbeitsbereich Pufferverwaltung: separater Puffer für jede Transaktion. Effekte einer Transaktion T : Begin Transaction T : T wird privater Arbeitsbereich als Puffer für Datenbankobjekte zugeordnet. Read Object X: Suche in privatem Arbeitsbereich von T nach X. X nicht gefunden Übertrag von X von Festplatte in Arbeitsbereich.

25 DEVO 8.25 Write Object X: X im Arbeitsbereich gefunden überschreibe X. Sonst: trage neuen Wert im Arbeitsbereich ein. End Transaction T: Übertrage alle im Arbeitsbereich geänderten oder neu geschaffenen Werte von Objekten auf die Festplatte. spezielles Protokoll garantiert, daß entweder alle oder keine Werte übertragen werden. Freigabe des privaten Arbeitsbereichs.

26 DEVO 8.26 Write Ahead-Protokoll Realisiert privaten Arbeitsbereich. Annahme: ab hier strikte und serialisierbare Ausführung. 1. Phase: Alle zu ändernden Werte werden aus dem privaten Arbeitsbereich in stabilen Speicherbereich (Log) übertragen (gefolgt von einem speziellen Commit Record). 2. Phase: Die geänderten Werte werden in die Datenbank auf der Festplatte eingetragen. Systemausfall während 1. Phase: die Transaktion gilt als nicht durchgeführt. Die Festplatte ist und bleibt unverändert. Systemausfall während 2. Phase: DBS muß beim Wiederanlauf alle Updates aus dem stabilen Speicher übernehmen.

27 DEVO 8.27 Wiederanlaufverfahren mit Logprotokoll Private Speicherverwaltung kann kompliziert sein. Sofortige Eintragung aller Änderungen und aller für korrekten Wiederanlauf nötigen Informationen ins Logprotokoll. Kein privater Speicher mehr notwendig, alle Daten im globalen Cache. Logprotokoll enthält Logeinträge als Vermerk von Start (begin transaction), Ende (commit transaction), Abbruch (abort transaction) einer Transaktion, Standard-Logeinträge, registrieren alle durchgeführte Änderungen.

28 DEVO 8.28 Standardeintrag im Logprotokoll 1. ID der Transaktion 2. ID des geänderten Datensatzes 3. Art der Änderung (insert, delete, update) 4. alter Wert (für UNDO) 5. neuer Wert (für REDO) 6. Hilfsinformation (Zeiger auf vorigen Logeintrag der Transaktion, etc.)

29 DEVO 8.29 Transaktionsrecovery vom Logprotokoll um Transaktionen rückgängig zu machen (Rollback, backward recovery): UNDO(T ) um Transaktionen nachzufahren (forward recovery): REDO(T ). Fehler auch während des Wiederanlaufs möglich UNDO und REDO müssen idempotent sein: UNDO(UNDO(T )) = UNDO(T ) und REDO(REDO(T )) = REDO(T )

30 DEVO 8.30 UNDO / REDO alter Wert DO neuer Wert Logprotokoll neuer Wert UNDO alter Wert Logprotokoll alter Wert REDO neuer Wert Logprotokoll

31 DEVO 8.31 Wiederanlauf nach einem Transaktionsabbruch Voraussetzung: Logprotokoll mit den alten Werten ist vorhanden. Algorithmus: UNDO(T): Lies das Logprotokoll vom letzen Eintrag in Richtung Anfang bis zum Eintrag begin transaction T und ersetze sämtliche Änderungen von T in der Datenbank durch die alten Werte. RESTART(T): Starte T neu.

32 DEVO 8.32 Wiederanlauf nach einem Systemabsturz Voraussetzung: Logprotokoll mit den alten Werten ist vorhanden. Algorithmus: 1. Baue UndoListe und RedoListe auf: Lies Logprotokoll vorwärts, bei begin transaction Ti füge Ti zur UndoListe hinzu. bei commit transaction Ti füge Ti zur RedoListe hinzu und streiche Ti von der UndoListe. 2. Lies Logprotokoll rückwärts und führe das UNDO für Ti in UndoListe. 3. Lies Logprotokoll rückwärts, bis alle begin transaction-einträge für Ti in RedoListe gefunden wurden. 4. Lies das Logprotokoll vorwärts und führe ein REDO für Ti RedoList 5. Restart Ti in UndoListe

33 DEVO 8.33 Beispiel 8 T1 T2 T3 T4 UNDO Zeit Transaktionsabbruch UNDO T4 RESTART T4

34 DEVO 8.34 Beispiel 9 Bei einem Systemabsturz müssen alle Transaktionen, auch jene, die zum Zeitpunkt des Absturzes nicht mehr aktiv waren nachgefahren werden. T1 T2 T3 T4 REDO UNDO REDO REDO Zeit Systemabsturz UNDO T4 REDO T1,T2,T3 RESTART T4

35 DEVO 8.35 Checkpoints Erzwingen der Übereinstimmung von Platte und Hauptspeicher für schnelleren Wiederanlauf. Checkpoint: 1. alle schmutzigen Pufferblöcke auf Platte schreiben 2. spezieller Logeintrag, checkpoint L, auf stabilen Speicher schreiben, (L... Menge der zum Zeitpunkt des Checkpoints aktiven Transaktionen). Bis zum nächsten Checkpoint: vermerke alle Änderungen im Logprotokoll. Änderungen werden unter Umständen nur im Hauptspeicher und nicht in der Datenbank vorgenommen.

36 DEVO 8.36 Wiederanlauf nach einem Systemabsturz Voraussetzung: Logprotokoll ist ab dem Startzeitpunkt der ältesten beim letzten Checkpoint aktiven Transaktionen auf stabilen Speicher vorhanden. Algorithmus: 1. Baue UndoListe und RedoListe auf: Suche den letzten Checkpoint-Eintrag checkpoint L; UndoListe:= L, RedoListe:= {} lies von L an vorwärts (in Richtung des letzten Eintrags). wird ein Logeintrag commit transaction Ti gefunden, füge Ti zur RedoListe hinzu und streiche Ti von der UndoListe. wird ein Logeintrag begin transaction Ti gefunden, füge Ti zur UndoListe hinzu.

37 DEVO 8.37 Wiederanlauf (Forts.) 2. Lies das Logprotokoll vom letzten Eintrag ausgehend rückwärts und mache alle Änderungen von Transaktionen in der UndoListe rückgängig. Fahre am Checkpoint fort, im Logprotokoll rückwärts zu lesen, bis die begin transaction- Einträge für alle Transaktionen in der UndoListe gefunden wurden. 3. Lies das Logprotokoll ab dem Checkpoint vorwärts und schreibe für jede von einer Transaktion in der RedoListe durchgeführte Änderung den neuen Wert in die Datenbank. 4. Starte alle Transaktionen in der UndoListe neu.

38 DEVO 8.38 Beispiel 10 T1 REDO T2 T3 UNDO T4 T5 REDO UNDO Zeit Checkpoint Absturz UNDO T4, T5 REDO T2, T3 RESTART T4, T5

39 DEVO 8.39 Beispiel 11 Achtung: nicht strikte Ausführung T1 T2 T3 T4 T5 write(x) write(x) UNDO REDO REDO UNDO Zeit Checkpoint Absturz UNDO von WRITE(X) in T4 macht ein REDO von WRITE(X) in T2 notwendig.

40 DEVO 8.40 Wiederanlauf nach einem Plattenfehler Voraussetzungen: Sicherungskopie (Backup) und Logprotokoll ab dem Zeitpunkt der Sicherungskopie vorhanden keine Transaktion während der Sicherung aktiv. Algorithmus 1. Ersetze die Datenbank durch die Sicherungskopie. 2. begin transaction Ti im Log Ti in RestartListe commit transaction Ti im Log Ti in RedoListe und Ti aus RestartListe 3. Lies das Log vom Anfang bis zum Ende und übernimm für Änderungen von Transaktionen in der RedoListe die neuen Werte in die Datenbank.

41 DEVO 8.41 Beispiel 12 T1 T2 T3 REDO T4 T5 Zeit Checkpoint Absturz Backup DB:=Backup REDO T2 RESTART T5

42 DEVO 8.42 Schattenkopieverfahren (shadow paging) Die Grundidee Vermeidung eines Logs durch Führen einer zweiten Datenbank-Kopie Schattenkopie: enthält den Datenbankzustand vor dem Start der Transaktion, repräsentiert den nach der letzten erfolgreich abgeschlossenen Transaktion gültigen Datenbankzustand. Arbeitskopie: auf ihr werden alle Änderungen der Transaktion durchgeführt. Initialisierung mit Schattenkopie. Bei Transaktionsabbruch: Arbeitskopie verwerfen. Bei Transaktions-Commit: Arbeitskopie wird neue Schattenkopieverwerfen.

43 DEVO 8.43 Annahme für Realisierung Aufteilung der Datenbank in Seiten (pages). Eine Seite umfaßt eine vorgegebene Anzahl Blöcke fixer Länge. Die Seiten sind nicht notwendigerweise sequentiell gespeichert. Seitentabelle (page table) ordnet jeder Seite, identifiziert durch die Seitennummer, ihre Adresse auf der Platte zu.

44 DEVO n Seitentabelle... Seiten auf der Platte

45 DEVO 8.45 Schattenkopie-Realisierung Schattenspeicherfahren: verwende zwei Seitentabellen. Schattenseitentabelle (für DB) und Arbeitsseitentabelle (für Transaktion), die auf die Schatten- bzw. die Arbeitskopie zeigen. Seiten, die in der Schattenkopie und in der Arbeitskopie gleich sind, werden nur einmal gespeichert und von beiden Tabellen referenziert. Eine fixe Speicheradresse auf der Platte enthält einen Zeiger auf die Schattenseitentabelle.

46 DEVO 8.46 SST AST

47 DEVO 8.47 Schattenkopie - Schreiben Zum Transaktionsbeginn wird die Schattenseitentabelle in die Arbeitsseitentabelle kopiert. Eine Schreiboperation write(x,x j) auf ein Objekt X, das auf der i-ten Seite liegt, wird wie folgt behandelt: 1. Ist die i-te Seite nicht im Puffer, dann übertrage sie mit input(x). 2. Wird die i-te Seite zum ersten Mal verändert, dann suche eine freie Seite auf der Platte und ordne dieser die i-te Seite in der Arbeitsseitentabelle zu. 3. Weise den Wert xi dem Objekt X im Puffer zu.

48 DEVO 8.48 Schattenkopie - Transaktionsende Um eine Transaktion erfolgreich abzuschließen, werden folgende Schritte gesetzt: 1. Schreibe alle schmutzigen Seiten im Puffer auf die Platte. 2. Schreibe die Arbeitsseitentabelle auf die Platte. 3. Schreibe die Adresse der Arbeitsseitentabelle auf jene fixe Speicheradresse, die die Adresse der Schattenseitentabelle enthält. Das Wiederanlaufverfahren nach einem Systemfehler oder Transaktionsfehler ist einfach: setze die Arbeit mit der Schattenkopie fort.

49 DEVO 8.49 Schattenspeicherverfahren Vorteile: Keine Verwaltung eines Logprotokolls. Wiederanlauf beträchtlich schneller. Nachteile: Datenfragmentierung Freispeicherverwaltung Schwerer als Verfahren mit Logprotokoll auf Mehrbenutzerbetrieb erweiterbar Indirekter Datenzugang, langsamer Zugriff