Der Prozess der Wiederherstellung der Daten einer Datenbank nach einem Fehler im laufenden Betrieb in einen konsistenten, möglichst verlustfreien Zustand heißt Recovery. Beteiligt an diesem Recovery sind von Seiten der Datenbank: Speichermanager des DBMS, der aus Puffermanager und Recoverymanager besteht Hauptspeicher mit den Daten- und Logpuffer Die Daten- und Logdateien im Sekundärspeicher Die archivierten Logdateien im Tertiärspeicher 1
Hauptaufgaben des Recoverymanager: Physische Speicherung der Ergebnisse von erfolgreich abgeschlossenen Transaktionen im Sekundärspeicher. Löschen von Daten aus dem Sekundärspeicher, die von abgebrochenen Transaktionen stammen. Bearbeitung der read-, write-, commit-, abort-, restart- Anweisungen des Schedulers. Überwachung der flush-anweisungen des Puffermanagers. 2
Mögliche Fehler im laufenden Betrieb: Transaktionsfehler Systemfehler Mediafehler Diese potentiell auftretenden Fehlerkategorien benötigen unterschiedliche Recovery-Maßnahmen zur Wiederherstellung eines konsistenten Datenbestandes! 3
Transaktionsfehler: Transaktionsfehler beziehen sich im Prinzip nur auf eine Transaktion, sind also lokal und bewirken, dass diese Transaktion abgebrochen wird. Mögliche Ursachen: Fehler im Anwendungsprogramm (z.b. Division durch 0, o.ä.) Expliziter Transaktionsabbruch durch den Benutzer Expliziter Transaktionsabbruch durch das System (z.b. zur Behebung eines deadlocks, ) Recovery-Maßnahmen: Zurückrollen der betroffenen Transaktion und Löschen der Daten, die bzgl. dieser Transaktion in die Datendateien geschrieben wurden 4
Transaktionsfehler: Obwohl nur eine Transaktion betroffen ist, kann es sein, dass sich das Recovery auch auf andere Transaktionen erstrecken muss: T1 Zeit T2 begin T1 1 wlock1(x) 2 r1(x) 3 w1(x) 4 5 begin T2 6 wlock2(y) 7 r2(y) 8 w2(y) 9 unlock2(y) 10 commit2 wlock1(y) 11 r1(y) 12 w1(y) 13 rollback1 14 Nach dem Zurückrollen von T1 muss T2 nach vorne gerollt werden, da T2 erfolgreich abgeschlossen wurde (Bedingung D der ACID-Bedingungen)! 5
Systemfehler: Unter dieser Kategorie werden alle DBMS-Fehler, Betriebsystem- und Hardware-Fehler gesammelt. Hauptmerkmale dieser Kategorie: Alle im Hauptspeicher befindlichen Daten wurden zerstört. Sekundärspeicher ist unversehrt. Recovery-Maßnahmen: Alle Änderungen von nicht abgeschlossenen Transaktionen, die bereits in den Sekundärspeicher geschrieben wurden, müssen rückgängig gemacht werden. Alle Änderungen abgeschlossener Transaktionen, die noch nicht in den Sekundärspeicher geschrieben wurden, müssen physisch 6 gespeichert werden
Systemfehler: Recovery-Maßnahmen: Alle Änderungen abgeschlossener Transaktionen, die noch nicht in den Sekundärspeicher geschrieben wurden, müssen physisch gespeichert werden Aber: Es kann sein, dass auch bzgl. abgeschlossener Transaktionen, die noch nicht komplett physisch in die Datendateien geschrieben wurden, Daten aus den Puffern verloren gegangen sind! Falls diese Daten sich bereits in den Log-Dateien befinden (WAL- Protokoll), können sie zurückgeholt werden. Falls nicht, sind auch Daten von abgeschlossenen Transaktionen verloren, d.h. die Datenbank kann nur mit Datenverlust wiederhergestellt werden!!! 7
Mediafehler: Unter diese Kategorie fallen alle Fehler, die den Verlust bereits im Sekundärspeicher gespeicherter Daten nach sich ziehen. Ursachen für diese Kategorie: head crashes, die einige Plattensektoren zerstören. Controler-Fehler, die zu Datenverlusten führen. Zerstörung des Sekundärspeichers (Vandalismus, Naturgewalten, etc ) Recovery-Maßnahmen: 1. Einspielen eines möglichst zeitnahen Betriebsystem-Backups 2. Recovery mit archivierten Log-Dateien (Wiederherstellen der Ergebnisse der abgeschlossenen Transaktionen). 3. Recovery mit den aktuellen Log-Dateien (soweit vorhanden, etwa durch Spiegelung) und den Pufferinhalten. 8
Mediafehler: Recovery-Maßnahmen: 1. Einspielen eines möglichst zeitnahen Betriebsystem-Backups 2. Recovery mit archivierten Log-Dateien (Wiederherstellen der Ergebnisse der abgeschlossenen Transaktionen). 3. Recovery mit den aktuellen Log-Dateien (soweit vorhanden, etwa durch Spiegelung) und den Pufferinhalten (wie beim Systemfehler). Sind keine archivierten Log-Dateien vorhanden, oder aktuelle Log- Dateien mit verloren gegangen, kann lediglich der Datenzustand des eingespielten Betriebsystem-Backups wiederhergestellt werden! Folge: Datenverlust! 9
Die beschriebenen Recovery-Maßnahmen setzen insbesondere voraus, dass die Log-Seiten, die sich im Log-Puffer befinden, rechtzeitig in den Sekundärspeicher geschrieben werden! Dies garantiert das WAL-Prinzip (Write Ahead Log-Prinzip: Vor dem commit einer Transaktion müssen alle zugehörigen Log-Einträge in den Sekundärspeicher geschrieben werden (notwendig für das REDO) Vor dem Auslagern einer modifizierten Seite aus dem Daten-Puffer müssen erst alle zugehörigen Log-Einträge in den Sekundärspeicher geschrieben werden (notwendig für das UNDO) Die beschriebenen Recovery-Maßnahmen setzen außerdem ein zeitaktuelles Betriebsystem-Backup voraus. 10
Backup Grundlage jedes Media-Recovery ist ein Betriebsystem-Backup. Dieses muss alle relevanten Dateien des Datenbanksystems enthalten. (Hersteller-abhängig!!) BS-Backups können nur für geschlossene Dateien gemacht werden. Muss die Datenbank rund um die Uhr geöffnet sein, muss so ein BS-Backup durch eigene Backup-Maßnahmen der Datenbank ergänzt werden! (Hersteller-abhängig!!) Zusätzliche Sicherheit bietet die Spiegelung der Daten- und Log-Dateien der Datenbank, wenn das Datenbanksystem dieses als Maßnahme implementiert hat. (Hersteller-abhängig!!) 11
Backup und Recovery für das ORACLE-Datenbanksystem Das BS-Backup für das ORACLE-Datenbanksystem muss auf jeden Fall die folgenden Dateien enthalten: Daten-Dateien Log-Dateien Konfigurationsdateien Control-Datei Log-Dateien können archiviert werden, indem die Datenbank im Modus ARCHIVELOG gefahren wird. Dazu sind notwendig: Entsprechende Einträge in der Konfigurationsdatei: log_archive_start = TRUE (und mehr) Ein explizites Versetzen der Datenbank in diesen Modus durch das alter database archivelog - statement. 12
Backup und Recovery für das ORACLE-Datenbanksystem Wurden nach einem BS-Backup strukturelle Änderungen in der Datenbank vorgenommen (Erzeugung eines neuen tablespace, oder Erzeugung einer neuen Datendatei für einen bestehenden tablespace, ), muss die Control- Datei zusätzlich aktuell gesichert werden: alter database backup controlfile to <filename>; Dieses gesicherte Controlfile kann bei einem Recovery benutzt werden: recover database using backup of controlfile; Zusätzlich zu allen üblichen Backup-Maßnahmen bietet ORACLE auch ein logisches backup an: Export der kompletten Datenbank oder Teilen davon in eine Textdatei: exp user/passwd file=<dateiname>. Das logische Backup kann komplett oder in Teilen eingespielt werden durch: imp user/passwd file=<dateiname> 13
Backup und Recovery für das ORACLE-Datenbanksystem Das Recovery kann bei ORACLE automatisiert oder manuell durchgeführt werden. Automatisiert: Datenbank starten, aber nicht öffnen: startup mount Datenbank im Single-user-modus: : alter database exclusive; Recovery-Kommando alter database recover; Ist die Datenbank im ARCHIVELOG-Modus, wird, aufsetzend auf dem vorher eingespielten BS-Backup, ein komplettes Recovery mit den archivierten Log-Dateien durchgeführt und anschließend die Datenbank über alter database open für alle wieder zugänglich gemacht. Manuell: Beim manuellen Recovery müssen nach dem alter database recover Befehl alle archivierten und aktuellen Log-Dateien namentlich aufgeführt werden. 14