Recovery- und Buffermanager Gesamtübersicht der Komponenten beim Zusammenspiel des lokalen Recovery Manager und des Datenbank Buffer Manager: persistenter Log Main memory Lokaler Recovery Manager (LRM) Log Buffer Read Write Fetch, Flush Read Write Datenbank persistente Datenbank Read Write Datenbank Buffer Manager (BM) Read Write Buffer (volatile Datenbank) Fetch: holt Daten page-weise in den DB-Buffer (read von persistenter DB) Flush: gibt Daten page-weise aus dem DB-Buffer frei (write in persistente DB) Schestag Datenbanken (Cnam) Kapitel 7-32
Fehlerklassifikation Klassifikation von Fehlern: Transaktionsfehler Systemfehler Externspeicherfehler Unterschiedliche Recoverymaßnahmen sind je nach Fehlerkategorie erforderlich. Schestag Datenbanken (Cnam) Kapitel 7-33
Transaktionsfehler Im Falle von Transaktionsfehlern spricht man beim Wiederherstellen eines konsistenten Zustandes von Transaktionsrecovery: BOT T 1 commit T 1 Zustand A 1 Zustand B 1 BOT T 2 Zustand A 2 abort T 2 Zeit Abort einer einzelnen Transaktion Alle Änderungen der Transaktion T 2 müssen rückgängig gemacht werden UNDO. Alle parallelen Änderungen anderer Transaktionen, die mit commit abgeschlossen wurden, dürfen nicht rückgängig gemacht werden kein Einfluss auf den Rest des Systems auch: lokaler Fehler Schestag Datenbanken (Cnam) Kapitel 7-34
Transaktionsfehler und Transaction-Recovery Typische Transaktionsfehler Fehler im Anwendungsprogramm Transaktionsabbruch explizit durch den Benutzer Transaktionsabbruch durch das System Behandlung (Transaction-Recovery) Isoliertes Zurücksetzen aller Änderungen der abgebrochenen Transaktionen = lokales UNDO bzw. R1-Recovery Wichtig: von dieser Seite veränderte Pages können sich sowohl im Datenbank-Puffer als auch bereits auf dem persistenten Speichermedium befinden! Schestag Datenbanken (Cnam) Kapitel 7-35
Protokoll der Änderungsinformationen Die durchgeführten Änderungen werden von den meisten DBMS in einem Datenbank-Log geschrieben und persistent gespeichert. 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 Pro Transaktion werden außerdem die folgenden Informationen geschrieben: BOT record termination record (commit, abort). Schestag Datenbanken (Cnam) Kapitel 7-36
Beispiel für Log-Einträge 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 Schestag Datenbanken (Cnam) Kapitel 7-37
und entsprechendes Transaktionsrecovery 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 Page) 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 Schestag Datenbanken (Cnam) Kapitel 7-38
Systemfehler Im Falle von Systemfehlern spricht man beim Wiederherstellen eines konsistenten Zustandes von Crashrecovery: BOT T 1 commit T 1 Zustand A 1 Zustand B 1 BOT T 2 Zustand A 2 Zeit Systemfehler Alle Daten im Buffer sind zerstört. Alle Daten auf den persistenten Speichermedien sind noch verfügbar. Schestag Datenbanken (Cnam) Kapitel 7-39
Systemfehler und Crash-Recovery Typische Systemfehler DBMS-Fehler Betriebssystemfehler Hardware-Fehler 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 Schestag Datenbanken (Cnam) Kapitel 7-40
Crash-Recovery: Szenarien Mögliche Zustände von Änderungen auf Pages nach einem Systemfehler: im Buffer geändert und committet, bereits persistent im Buffer geändert und noch nicht committet, bereits persistent im Buffer geändert und committet, noch nicht persistent im Buffer geändert und noch nicht committet, noch nicht persistent persistenter Log Main memory Lokaler Recovery Manager (LRM) Log Buffer Read Write Fetch, Flush Read Write Datenbank persistente Datenbank Read Write Datenbank Buffer Manager (BM) Read Write Buffer (volatile Datenbank) Schestag Datenbanken (Cnam) Kapitel 7-41
3 Phasen des Crash-Recovery Analyse Das Log wird von Anfang bis zum Ende gelesen und ermittelt, welche Transaktionen erfolgreich beendet (committed) wurden und welche zum Fehlerzeitpunkt offen waren. Wiederholung der Historie (REDO) Es werden alle(!) protokollierten Änderungen in der Reihenfolge ihrer Ausführung in die Datenbank eingebracht. UNDO Die Änderungsoperationen der zum Fehlerzeitpunkt offenen Transaktionen werden rückgängig gemacht. Schestag Datenbanken (Cnam) Kapitel 7-42
Das Write-Ahead-Logging-Protokoll (WAL) In Analogie zu den Werten der Datenbank wird auch der Log vom Buffer Manager im Hauptspeicher gepflegt und in einen persistenten Log dauerhaft geschrieben. Der persistente Log sollte immer vor dem Update der entsprechenden Daten auf der persistenten Datenbank geschrieben werden: Das Write-Ahead-Logging-Protokoll (WAL) 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 Page in die Datenbank eingebracht wird, müssen alle diese Page betreffenden Log-Einträge ausgeschrieben werden (für das UNDO im Fehlerfall). Anmerkung: Log-Einträge werden nicht einzeln, sondern alle Log-Einträg bis zum betroffenen Eintrag sequentiell ausgeschrieben. Schestag Datenbanken (Cnam) Kapitel 7-43
Externspeicherfehler und Media-Recovery Die Daten der materialisierten Datenbank sind zerstört oder unbrauchbar. Typische Externspeicherfehler Hardware-Fehler: Head-Crashes, Controller- Fehler etc. Naturgewalten wie Feuer oder Erdbeben Viren Behandlung (Media-Recovery) Die Datenbank muss mit Hilfe einer Sicherungskopie (Backup) wiederhergestellt werden. Danach muss der letzte transaktionskonsistente Zustand wiederhergestellt werden, d.h. alle seit der Erstellung des Backup erfolgreich beendeten Transaktionen nachvollzogen werden. persistente Datenbank Konsequenz: Die Log-Dateien müssen auf einem anderen Medium gesichert werden (z.b. anderer Rechner, Magnetband o.ä.)! Schestag Datenbanken (Cnam) Kapitel 7-44
Media-Recovery (1) Gesicherte Daten mit 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 Zeit Schestag Datenbanken (Cnam) Kapitel 7-45
Media-Recovery (2) Gesicherte Daten mit 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 Zeit Schestag Datenbanken (Cnam) Kapitel 7-46
Inkrementelles Backup und Crash-Recovery Bei großen Datenbanken ist eine Komplettsicherung sehr(!) zeitaufwändig. Inkrementelles Backup = Sicherung der veränderten Datenbankseiten 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: Schestag Datenbanken (Cnam) Kapitel 7-47
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 Schestag Datenbanken (Cnam) Kapitel 7-48
Zusammenfassung Zum Verständnis des Transaktionskonzeptes sind vor allem die ACID- Eigenschaften von Transaktionen wichtig. Bei ungeschützten konkurrierenden Zugriffen können verschiedene Kategorien von Inkonsistenzen auftreten. Zur Vermeidung solcher Inkonsistenzen werden Sperrkonzepte genutzt. Die Granularität des Sperrverhaltens definiert unterschiedliche Isolationlevel. Den drei Fehlerkategorien Transaktionsfehler, Systemfehler und Mediafehler entsprechen unterschiedliche Recovery-Strategien. Zur Wiederherstellung von Daten werden Logfiles und Backups verwendet. Schestag Datenbanken (Cnam) Kapitel 7-49
Datenbanken Einführung Semantische Datenmodellierung Relationenmodell Interne Datenorganisation SQL - Structured Query Language Datenbank-Anwendungsentwicklung Transaktionsmanagement Objekt-relationales Mapping Rückblicke und Ausblicke Schestag Datenbanken (Cnam) Kapitel 7-50