Fehlerbehandlung Transaktionsverwaltung 7.3 Fehlerbehandlung 2002 Prof. Dr. Rainer Manthey Informationssysteme 1 Recovery: Übersicht Bei Auftreten von Fehlersituationen: Transaktionsmanager bricht betroffene Transaktionen ab und setzt sie zurück (Rollback. danach: Einleiten einer "geordneten Wiederaufnahme" des Betriebs (Recovery Aufgabe des Recovery-Managers: Rekonstruktion des letzten konsistenten Vorzustandes bei Abbruch einer Transaktion Wiederanlauf aller zurückgesetzten Transaktionen Rücksetzen dient der Einhaltung aller vier ACID-Eigenschaften. Insbesondere die Eigenschaft 'D' (für Dauerhaftigkeit wird vom Recoverymanager garantiert. T 1 T 2 T 3.... Transaktions-Manager Scheduler Daten-Manager Recovery-Manager Puffer-Manager Datenbank T n (Graphik nach Prof. Kemper 2002 Prof. Dr. Rainer Manthey Informationssysteme 2
Fehlerklassifikation Die einzuleitenden Recovery-Maßnahmen hängen von der Art des aufgetretenen Fehlers ab. Fehlersituationen lassen sich wie folgt klassifizieren: Lokale Fehler: Auswirkungen des Fehlers betreffen nur eine Transaktion Globale Fehler: Auswirkungen betreffen alle Transaktionen Ursachen für lokale Fehler: expliziter Abbruch (abort, Konsistenzverletzung, Abbruch durch den Scheduler wg. Deadlock, Fehler im umschliessenden Anwendungsprogramm Beheben lokaler Fehler: Rücksetzen aller Änderungen dieser speziellen Transaktion (lokales Undo zwei Arten von globalen Fehlern: mit Hauptspeicherverlust: z.b. durch Stromausfall, Betriebssystemfehler oder Hardwareausfall - Hintergrundspeicher bleibt erhalten mit Hintergrundspeicherverlust: z.b. durch Plattenverlust nach "head crash", Feuer oder Naturkatastrophen, Fehler im Plattentreiber usw. (natürlich zusätzlich zum Hauptspeicherverlust 2002 Prof. Dr. Rainer Manthey Informationssysteme 3 Pufferung von Speicherseiten: Grundlagen wichtig für den Recoverymanager: Wechselwirkung mit Puffermanager beim Ein- und Auslagern von Seiten aus der persistenten DB im Hintergrundspeicher Seiten, die eine Transaktion benötigt, werden eingelagert und im Hauptspeicher (dem DB-Puffer fixiert. Fixierte Seiten können nicht ausgelagert werden. Pufferseiten, die von einer gerade aktiven Transaktion geändert worden sind, werden als "dirty" markiert. Sie stimmen nicht mit ihrem Abbild im Hintergrundspeicher überein. gepufferte Seite verdrängen einlagern Hauptspeicher Hintergrundspeicher 2002 Prof. Dr. Rainer Manthey Informationssysteme 4
Seitenersetzungsstrategien wichtige strategische Entscheidung des Transaktionsmanagers: Wann dürfen "dirty pages" ersetzt werden? zwei grundsätzlich verschiedene Seitenersetzungsstrategien: steal (dt.: "stehlen": Jede nicht fixierte Seite kann jederzeit ausgelagert werden, wenn der Speicherplatz von einer anderen Transaktion benötigt wird - "Transaktionen stehlen einander Seiten". not steal: Seiten, die von einer noch aktiven Transaktion verändert wurden, dürfen nicht ausgelagert werden. Konsequenzen der beiden Strategien für das Recovery: steal-strategie: Beim Rollback einer Transaktion müssen nicht nur im Hauptspeicher, sondern auch im Hintergrundspeicher Änderungen zurückgesetzt werden (wenn es "gestohlene" Seiten gibt. not steal-strategie: Nur im Hauptspeicher sind "Spuren" der abgebrochenen Transaktion zu finden. 2002 Prof. Dr. Rainer Manthey Informationssysteme 5 Auslagerungsstrategien weitere wichtige strategische Entscheidung: Wann müssen "dirty pages" ausgelagert werden? wiederum zwei alternative Auslagerungsstrategien: force (dt.: "zwingen : Alle von der beendeten Transaktion modifizierten Pufferseiten werden sofort bei Transaktionsende in den Hintergrundspeicher übertragen. not force: Auslagerung erfolgt erst später, wenn die entsprechenden Seiten tatsächlich wieder benötigt werden. Vorteile der jeweiligen Strategie: force-strategie: Bei Erreichen des Commit sind alle Änderungen, die die jeweilige Transaktion ausgeführt hat, dauerhaft (im Hintergrundspeicher. not force-strategie: Seiten im Puffer können von nachfolgenden Transaktionen weiter genutzt werden (Ein- und Auslagerung wird u.u. vermieden. 2002 Prof. Dr. Rainer Manthey Informationssysteme 6
Kombinationen von Seitenersetzung und Auslagerung scheinbar attraktivste Kombination: force und not steal! Vorteile: Alle Änderungen abgeschlossener T. sind dauerhaft. Keine Änderung noch aktiver T. ist schon "materialisiert". Nachteile: zu frühes Auslagern von oft gebrauchten "hot spot"-seiten Vorsorge gegen globale Fehler beim Auslagern erforderlich Anforderungen der vier möglichen Strategiekombinationen an Recovery im Hintergrundspeicher: undo: Rückgängigmachen, Zurücksetzen redo: Wiederholen force not force not steal steal redo undo redo undo redo undo redo undo 2002 Prof. Dr. Rainer Manthey Informationssysteme 7 Einbringstrategien dritte strategisch wichtige Entscheidung bei der Organisation der Speichernutzung durch Transaktionen: Wohin werden "dirty pages" ausgelagert? ebenfalls zwei Einbringstrategien für verdrängte Seiten auf den Hintergrundspeicher: update in place: direktes Einbringen; alte Seiten werden durch neue überschrieben (Protokollierung alter Seiten bei undo-operationen nötig twin block: Jede Seite ist zweifach (engl. "twin": Zwilling vorhanden; nach Auslagern ist die alte Seite zunächst noch vorhanden. Duplizieren der neuen Seite (mit Freigabe der alten Seite zu "sicherem" Zeitpunkt nach Transaktionsende durch das DBMS Kopie der alten Seite kann bei Rollback genutzt werden. "Twin block" bringt zwar Laufzeitgewinne mit sich, wird aber wegen des erhebllich höheren Speicherplatzbedarfs selten genutzt. Variante: Kopien nur für "dirty pages" (Schattenspeicherkonzept 2002 Prof. Dr. Rainer Manthey Informationssysteme 8
Konstellation für Recovery Die Diskussion der Recoverytechniken in diesem Kapitel legt die am weitesten verbreitete (aber auch anspruchsvollste Kombination von Strategien zugrunde: steal : Nicht-fixierte Seiten können jederzeit ersetzt oder ausgelagert werden. not force : Geänderte Seiten können jederzeit ausgelagert werden - auch nach Beenden der schreibenden Transaktion. update in place: Jede Seite hat einen "Heimatplatz" auf der Platte. (zusätzlich für Synchronisation: kleine Sperrgranularität, d.h., auch "kleine" DB-Objekte können separat gesperrt werden, nicht nur ganze Seiten 2002 Prof. Dr. Rainer Manthey Informationssysteme 9 Logging Um korrektes Rücksetzen (undo und Wiederholen (redo von Transaktionen zu ermöglichen, braucht jeder Recoverymanager eine Protokolldatei: Log Herkunft des Begriffs: engl. "log" = Holzscheit, ursprünglich das Medium zum "Anschreiben", d.h. Protokollieren, des Konsums in Gaststätten; siehe auch Logbuch in der Schiffahrt Protokollierung der Transaktionsaktivitäten ("Logging" erfolgt in drei Schritten: Ablegen der Protokolldaten in eigenen Pufferbereich im Hauptspeicher: Log-Puffer (Auslagern regelmäßig, spätestens wenn Puffer voll ist temporäres, aber persistentes Ablegen der ausgelagerten Log-Daten auf der Platte: Log-Dateien langfristiges Archivieren von Log-Dateien auf Bändern, um Hintergrundspeicherverluste kompensieren zu können: Log-Archiv Log-Puffer werden meist als Ringspeicher organisiert: Für jeden neuen Protokolleintrag wird (bei vollem Puffer ein alter Eintrag (am anderen Ende ausgelagert. 2002 Prof. Dr. Rainer Manthey Informationssysteme 10
Logging und Speicherhierarchie AP 1 AP n Code Log- Puffer DBMS- Datenbank- Puffer Log-Datei Log- Archiv Datenbank DB- Archiv (Graphik nach Prof. Kemper 2002 Prof. Dr. Rainer Manthey Informationssysteme 11 Anordnung des Log-Ringpuffers #30 Log-Datei eintragen #40 #41 #20 ausschreiben #10 (bereits ausgeschrieben Log- Archiv (Graphik nach Prof. Kemper 2002 Prof. Dr. Rainer Manthey Informationssysteme 12
Log-Einträge Pro Änderungsoperation werden (mindestens folgende Log-Einträge benötigt: Redo-Information: Welche Änderung wurde durchgeführt? Undo-Information: Wie kann die Änderung rückgängig gemacht werden? Speziell für den hier vorgestellten Ansatz wird dazu noch verwendet: "Log Sequence Number" (LSN: eindeutige Kennung des Eintrags; monoton aufsteigend, um Chronologie widerzuspiegeln Transaktionskennung (TA: Welche Transaktion hat geändert? Seitenkennung(en (PageID: Welche Seite(n wurde(n geändert? Vorgängerkennung (PrevLSN: direkt vorhergehender Schritt der T. 2002 Prof. Dr. Rainer Manthey Informationssysteme 13 Beispiel einer Log-Datei Schritt T 1 T 2 Log [LSN, TA, PageID, Redo, Undo, PrevLSN] 1. BOT [#1, T 1, BOT, 0] 2. r(a,a 1 3. BOT [#2, T 2, BOT, 0] 4. r(c,c 2 5. a 1 := a 1-50 6. w(a,a 1 [#3, T 1, P A, A-=50, A+=50, #1] 7. c 2 := c 2 + 100 8. w(c,c 2 [#4, T 2, P C, C+=100, C-=100, #2] 9. r(b,b 1 10. b 1 := b 1 + 50 11. w(b,b 1 [#5, T 1, P B, B+=50, B-=50, #3] 12. commit [#6, T 1, commit, #5] 13. r(a,a 2 14. a 2 := a 2 100 15. w(a,a 2 [#7, T 2, P A, A-=100, A+=100,#4] 16. commit [#8, T 2, commit, #7] 2002 Prof. Dr. Rainer Manthey Informationssysteme 14
Logische vs. physische Protokollierung zwei Alternativen, Redo- und Undo-Information darzustellen: Logische Protokollierung: Vermerken der zum Redo/Undo erforderlichen Operationen Physische Protokollierung: Vermerken der ursprünglichen oder geänderten Daten "before image": Datenwert vor der Änderung "after image": Datenwert nach der Änderung bei physischer Protokollierung: Kennzeichnen des Status von Daten im Hintergrundspeicher durch Mitkopieren der LSN der jeweiligen Seite LSN(Seite < LSN(Log-Eintrag "before image" wurde gespeichert LSN(Seite LSN(Log-Eintrag "after image" wurde gespeichert "write ahead"-log (WAL-Prinzip: Ausschreiben aller Log-Einträge vor commit der zugeh. Transaktion Ausschreiben aller Log-Einträge vor Auslagern der zugeh. Seiten 2002 Prof. Dr. Rainer Manthey Informationssysteme 15 Wiederanlauf nach Hauptspeicherverlust Nach einer Fehlersituation mit Hauptspeicherverlust gibt es zwei Arten betroffener Transaktionen: "Winner" (dt.: Gewinner : Transaktionen, die vor Eintreten der Fehlersituation bereits beendet waren "Loser" (von engl. "to loose", dt.: Verlierer : Transaktionen, die beim Fehlereintritt noch aktiv waren prinzipielle Behandlung der beiden Transaktionstypen: Winner-Transaktionen müssen vollständig wiederholt werden, da nicht sicher ist, dass die von ihnen veränderten Seiten bereits im Hintergrundspeicher stehen (wg. not force. Loser-Transaktionen müssen zusätzlich noch zurückgesetzt werden, denn es kann sein, dass einige der von ihnen geänderten Seiten schon ausgelagert wurden (wg. steal, ohne dass der Erfolg der T. schon feststeht. Recovery erfolgt dann in drei Schritten: 1. Schritt: Log-Analyse und Winner-/Loser-Klassifikation 2. Schritt: Redo-Phase 3. Schritt: Undo-Phase 2002 Prof. Dr. Rainer Manthey Informationssysteme 16
Wiederanlauf im Beispiel Schritt T 1 Winner T 2 Loser Log [LSN, TA, PageID, Redo, Undo, PrevLSN] 1. BOT [#1, T 1, BOT, 0] 2. r(a,a 1 3. BOT [#2, T 2, BOT, 0] 4. r(c,c 2 5. 6. a 1 := a 1-50 w(a,a 1 Warum Redo für Loser (vor Undo!? [#3, T 1, P A, A-=50, A+=50, #1] 7. c 2 := c 2 + 100 8. w(c,c 2 [#4, T 2, P C, C+=100, C-=100, #2] 9. r(b,b 1 10. b 1 := b 1 + 50 11. w(b,b 1 [#5, T 1, P B, B+=50, B-=50, #3] 12. commit [#6, T 1, commit, #5] 13. r(a,a 2 14. Fehlerzeitpunkt a 2 := a 2 100 15. w(a,a 2 [#7, T 2, P A, A-=100, A+=100,#4] 16. commit [#8, T 2, commit, #7] 2002 Prof. Dr. Rainer Manthey Informationssysteme 17 Fehlertoleranz bei Wiederanlauf Grund für die Notwendigkeit einer Redo-Phase auch für "Loser"-Transaktionen: Während des Neustartens einer Transaktion (nach Rollback kann es erneut zu Fehlersituationen kommen. Redo- und Undo-Phase müssen idempotent sein, d.h. auch bei mehrfacher Wiederholung muss stets dasselbe Ergebnis entstehen. Idempotenz...... der Redo-Phase: Bei jeder Redo-Operation wird eine neue LSN auf die zugehörige Seite kopiert.... der Undo-Phase: Zusätzliche Log-Einträge während der Undo-Phase erforderlich. Compensation Log Record (CLR LSN, PrevLSN, Transaktions- und Seitenkennung inverse Undo-Operation UndoNextLSN: Zeiger auf nächsten Undo-Eintrag Diskussion eines ausführlichen Beispiels zur Idempotenz-Problematik: Kemper 10.5 (Bitte unbedingt anschauen! 2002 Prof. Dr. Rainer Manthey Informationssysteme 18
Recovery mit Sicherungspunkten Nachteil der vorgestellten Recoverymethode: Wiederanlauf wird immer langsamer, je länger die Betriebszeit des DBMS ist, da die Log-Datei immer voller wird! Abhilfe: Einführen von Sicherungspunkten innerhalb von Transaktionen Sicherungspunkt: Position im Log, über die beim Wiederanlauf nicht hinausgegangen werden muss. Alle Log-Einträge vor dem S.punkt sind irrelevant. Drei Formen von Sicherungspunkten: transaktionskonsistente S. aktionskonsistente S. unscharfe (Fuzzy-S. (siehe Kemper 10.8.2/.3 Vorgehen bei transaktionskonsistenter Sicherung: Anmelden von S. in bestimmten "vernünftigen" Abständen T. zum Zeitpunkt der Anmeldung aktiv: wird zuende geführt! T. startet nach Anmeldung des S.: muss warten! Wenn aktive T. alle beendet sind: "Schreiben" des S., d.h. Auslagern aller modifizierten Seiten Neubeginn des Loggings nach Löschen des Log-Inhalts 2002 Prof. Dr. Rainer Manthey Informationssysteme 19 Transaktionskonsistente Sicherungspunkte Reset der Log-Datei Auslagern v. "dirty pages" Absturz undo T 1 redo T 2 T 3 wartet T 4 S i-1 Sicherungspunkt S i angemeldet Sicherungspunkt S i geschrieben Zeitachse 2002 Prof. Dr. Rainer Manthey Informationssysteme 20