8. Wiederherstellung und Datensicherheit

Transkript

1 8. Wiederherstellung und Datensicherheit Einführung in Recovery Recovery-Komponenten eines DBMSs Fehlerklassen Recovery-Klassen und Strategien VL Datenbank-Implementierungstechniken 9 1 Einführung in Recovery Datensicherung ohne Intervention garantieren automatische Wiederherstellung eines konsistenten DB-Zustands nach einem Fehler je nach Fehlerart müssen unterschiedliche Behandlungsstrategien ausgeführt werden Transaktions-Manager/Scheduler wahren die Isolationund Konsistenzeigenschaft einer Transaktion Recovery-Komponenten sichern die Atomaritäts- und Dauerhaftigkeitseigenschaft einer Transaktion VL Datenbank-Implementierungstechniken 9 2 Beteiligte Systemkomponenten T 1 T 2... T n Transaktions Manager (TM) read, write, commit, abort Scheduler (SC) restart read, write, commit, abort read write Recovery Manager (RM) DB- Archiv DB-Puffer fetch flush read write... Log-Puffer Flüchtiger Speicher read write Puffer Manager (PM) Speicher-Manager (SM) read write read write DB Log Log- Archiv Stabiler Speicher (z.b. Platte) VL Datenbank-Implementierungstechniken 9 3

2 Recovery-Komponenten I Speicher-Manager (SM): bildet Schnittstelle zwischen flüchtigem und stabilen Speicher umfaßt Recovery-Manager und Puffer-Manager Recovery-Manager (RM): sorgt dafür, daß 1. alle Änderungen einer committed Transaktion auch tatsächlich im stabilen Speicher sind 2. keine Änderungen von aktiven oder abgebrochenen Transaktionen im stabilen Speicher sind 3. nach einem Fehler die DB in einen konsistenten Zustand gebracht wird zum Restart benötigte Daten müssen gesichert werden VL Datenbank-Implementierungstechniken 9 4 Recovery-Komponenten II Puffer-Manager (PM)/ Cache-Manager (CM): verwaltet den Puffer (DB- und Log-Puffer) holt Daten (Seiten) vom stabilen Speicher in den Puffer schreibt Daten (Seiten) vom Puffer in den stabilen Speicher ersetzt Daten (Seiten) im Falle eines Pufferüberlaufs VL Datenbank-Implementierungstechniken 9 5 Fehlerklassifikation Fehlerklassifikation 1. Transaktionsfehler 2. Systemfehler 3. Mediafehler unterschiedliche Recovery-Maßnahmen je nach Fehlerart VL Datenbank-Implementierungstechniken 9 6

3 Transaktionsfehler Transaktionsfehler haben den Abbruch der jeweiligen Transaktion zur Folge haben keinen Einfluß auf den Rest des Systems auch: lokaler Fehler Typische Transaktionsfehler: 1. Fehler im Anwendungsprogramm 2. Transaktionsabbruch explizit durch den Benutzer 3. Transaktionsabbruch durch das System Behandlung: Isoliertes Zurücksetzen aller Änderungen der abgebrochenen Transaktionen VL Datenbank-Implementierungstechniken 9 7 Systemfehler Systemfehler Folge: Zuerstörung der Daten im Hauptspeicher betreffen jedoch nicht den Hintergrundspeicher Typische Systemfehler: 1. DBMS-Fehler 2. Betriebssystemfehler 3. Hardware-Fehler Behandlung: Zurücksetzen der von nicht beendeten Transaktionen in die DB eingebrachten Änderungen Nachvollziehen der von abgeschlossenen Transaktionen nicht in die DB eingebrachten Änderungen VL Datenbank-Implementierungstechniken 9 8 Mediafehler Mediafehler ziehen den Verlust von stabilen Datenbankbankdaten nach sich Häufige Ursachen: 1. Head-Crashes 2. Controller-Fehler 3. Naturgewalten wie Feuer oder Erdbeben Maßnahmen: DB-Archiv auf anderen Medien VL Datenbank-Implementierungstechniken 9 9

4 Szenario eines Systemfehlers Fehler T 1 T 2 T 3 T 4 T 5 tf Zeit VL Datenbank-Implementierungstechniken 9 10 Szenario eines Systemfehlers (II) Folgen: Inhalt des flüchtigen Speichers zum Zeitpunkt t f ist unbrauchbar Transaktionen in unterschiedlicher Weise davon betroffen Transaktionszustände: zum Fehlerzeitpunkt noch aktive Transaktionen (T 2 und T 4 ) bereits vor dem Fehlerzeitpunkt beendete Transaktionen (T 1, T 3 und T 5 ) VL Datenbank-Implementierungstechniken 9 11 Szenario eines Systemfehlers (III) Probleme: Dauerhaftigkeitseigenschaft Effekte von T 1, T 3 und T 5 müssen dauerhaft in der DB sein Atomaritätseigenschaft Effekte von T 2 und T 4 dürfen nicht in der DB sein VL Datenbank-Implementierungstechniken 9 12

5 Recovery-Klassen R1-Recovery (lokales Zurücksetzen Transaction UNDO): nach Transakationsfehler werden die entsprechenden Transaktionen isoliert zurückgesetzt R2-Recovery (partielles Wiederholen Partial REDO): nach Systemfehler besteht ein konsistenter Zielzustand aus allen bis zum Fehler abgeschlossenen Transaktionen alle Änderungen abgeschlossener Transaktionen, deren Daten beim Systemfehler noch im Puffer waren, nachvollziehen und in die DB schreiben VL Datenbank-Implementierungstechniken 9 13 Recovery-Klassen (II) R3-Recovery (globales Zurücksetzen Global UNDO): nach Systemfehler soll der Zielzustand keine Auswirkungen nicht beendeter Transaktionen enthalten Spuren sämtlicher zum Fehlerzeitpunkt aktiver Transaktionen aus der DB entfernen R4-Recovery (globales Wiederholen Global REDO): nach Defekt auf einem nichtflüchtigen Externspeicher wird eine Archivkopie auf den Datenträger kopiert alle Änderungen der nach der letzten Erstellung der Archivkopie beendeten Transaktionen nachvollziehen und in die DB schreiben VL Datenbank-Implementierungstechniken 9 14 Protokollierungsarten Log-Buch physische versus logische Protokollierung Sicherungspunkte VL Datenbank-Implementierungstechniken 9 15

6 Prinzipieller Aufbau eines Log-Buchs Schritt T 1 T 2 Log 1 lock A (T 1, begin) 2 read A 3 A := A 1 4 write A (T 1, A, 10, 9) 5 lock B 6 unlock A 7 lock A (T 2, begin) 8 read A 9 A := A 2 10 read B 11 write A (T 2, A, 9, 18) 12 commit (T 2, commit) 13 unlock A 14 B := B/A (T 1, abort) VL Datenbank-Implementierungstechniken 9 16 Prinzipieller Aufbau eines Log-Buchs II A hat zu zu Anfang den Wert 10 Vor dem ersten Schritt wird (T 1, begin) eingetragen Vor Schritt 4 folgt (T 1, A, 10, 9) Vor Schritt 7 beginnt T 2 mit (T 2, begin) Vor Schritt 11 wird (T 2, A, 9, 18) eingetragen Vor Schritt 12 folgt Abschluß von T 2 : (T 2, commit) Nach Schritt 14 wird Abbruch (T 1, abort) geschrieben VL Datenbank-Implementierungstechniken 9 17 Einträge im Log [ LSN, TA, PageID, Redo, Undo, PrevLSN ] LSN: Log-Sequence-Number, eindeutige und aufsteigende Durchnumerierung der Log-Einträge TA: Transaktionskennung PageID: Seitennummer Redo: REDO-Information Undo: UNDO-Information PrevLSN: Verweis auf den vorherigen Eintrag der selben Transaktion VL Datenbank-Implementierungstechniken 9 18

7 Einträge im Log Beispiel [ #1, T 1, BOT ] [ #2, T 1, P A, A=A+1, A=A-1, #1 ] [ #3, T 2, BOT ] [ #4, T 2, P A, A=A 2, A=A/2, #3 ] [ #5, T 2, commit, #4 ] [ #6, T 1, abort, #2 ] VL Datenbank-Implementierungstechniken 9 19 Physisches Protokollieren ganze physische Speichereinheiten (d.h. Seiten) vor dem Einlagern Seite gesondert als Before-Image speichern Vorteil: Protokoll- bzw. Recovery-Komponenten sind sehr einfach zu realisieren VL Datenbank-Implementierungstechniken 9 20 Physisches Protokollieren (II) Nachteile: 1. Protokollinformationen können nicht gepuffert werden hoher E/A-Aufwand 2. Seitenprotokollierung erfordert das Sperren ganzer Seiten 3. Protokollinformationen über Änderungen in den Zugriffspfaden, Tabellen, Ketten, etc. müssen zusätzlich gehalten werden VL Datenbank-Implementierungstechniken 9 21

8 Logisches Protokollieren alle ausgeführten höheren Operation werden im Log-Buch erfaßt anhand dieser Informationen können die DML-Anweisungen (und deren Invers-Operationen) nachvollzogen werden Vorteil: Auswirkungen der Änderungsoperationen einer Transaktion auf die Speicherungsstrukturen müssen nicht protokolliert werden es genügt Änderungsoperationen und die aktuellen Parameter zu notieren VL Datenbank-Implementierungstechniken 9 22 Logisches Protokollieren (II) Nachteile: 1. Probleme bei der R1/R3-Recovery inverse DML-Operationen sind oftmals nicht (trivial) berechenbar 2. DB muß in einem speicherkonsistenten Zustand sein, um als Ausgangspunkt für die Recovery dienen zu können VL Datenbank-Implementierungstechniken 9 23 Szenario Systemfehler nach einem Sicherungspunkt Sicherungspunkt Fehler T 1 T 2 T 3 T 4 t s T 5 tf Zeit VL Datenbank-Implementierungstechniken 9 24

9 Physisches vs. logisches Protokollieren Phys. Protokollieren Log. Protokollieren T 1 In t s wurden alle bis dahin angefallenen Änderungen übernommen (keine Wiederholung von T 1 notwendig) T 2 Partielles Zurücksetzen von Ausführung bis t s protokollierter T 2 mit Hilfe der Before- inverser DML-Befehle in Images umgekehrter Reihenfolge bis BOT T 3 Partielles Wiederholen von T 3 Ausführung nach t s protokollierter mit Hilfe der After-Images Original-DML-Befehle bis Commit T 4 Alle Effekte von T 4 mit Wiederherstellung des Zustands zum Zeitpunkt t s implizit entfernt (keine weiteren Maßnahmen erforderlich) T 5 Durch Wiederherstellen des Zustands zum Zeitpunkt t s verschwinden alle Auswirkungen von T 5 (T 5 komplett wiederholen) VL Datenbank-Implementierungstechniken 9 25 Das WAL-Prinzip Write Ahead Log vor commit einer Transaktion Ausschreiben aller zugehörigen Log-Einträge (notwendig für Durchführung von REDO) vor dem Auslagern einer modifizierten Seite Schreiben aller zugehörigen Log-Einträge in das Log-Archiv (ermöglicht UNDO bei abgebrochenen Transaktionen) VL Datenbank-Implementierungstechniken 9 26 Sicherungspunkte (SP) Sicherungspunkte (engl. checkpoints) werden im normalen Betrieb der DB angelegt, um bei der Recovery Zeit/Kosten zu sparen Arten: 1. Transaktionskonsistente Sicherungspunkte 2. Aktionskonsistente Sicherungspunkte 3. Unscharfe Sicherungspunkte VL Datenbank-Implementierungstechniken 9 27

10 Transaktionskonsistente SP alle Änderungen werden in einem Moment, in dem keine Schreibbefehle aktiv sind, vom Puffer in die DB geschrieben Ablauf: 1. Sicherungspunkt angemelden 2. neu ankommende Transaktionen müssen warten 3. aktive Transaktionen werden zu Ende geführt 4. sobald alle aktiven Transaktionen beendet wurden, werden alle geänderten Seiten auf die Platte gezwungen VL Datenbank-Implementierungstechniken 9 28 Transaktionskonsistente SP (II) Kennzeichen: spätere R2-Recovery braucht keine Veränderungen vor diesem Punkt mehr zu berücksichtigen Nachteil: läßt Benutzer unter Umständen lange warten VL Datenbank-Implementierungstechniken 9 29 Transaktionskonsistente SP (III) T 1 T 2 T 3 Anmeldung Sicherungspunkt T 4 Zeit VL Datenbank-Implementierungstechniken 9 30

11 Aktionskonsistente Sicherungspunkte periodisches Blockieren aller aktiven Transaktionen blockiert und Schreiben der bis dahin geänderten Seiten in die DB Änderungen der abgebrochenen Transaktionen (bzgl. des letzten Sicherungspunkts) werden im nächsten Sicherungspunkt behandelt VL Datenbank-Implementierungstechniken 9 31 Aktionskonsistente Sicherungspunkte (II) Kennzeichen: beim Restart muß weniger geleistet werden, da alle bis zum letzten Sicherungspunkt erfolgreich abgeschlossenen Transaktionen gesichert sind und damit keine Redo-Phase notwendig ist alle abgebrochenen Transaktionen mit dem Zurücksetzen ungültig gemacht wurden Nachteil: läßt Benutzer unter Umständen lange warten VL Datenbank-Implementierungstechniken 9 32 Aktionskonsistente Sicherungspunkte (III) T 1 Periodische Sicherungspunkte T 2 T 3 T 4 Zeit VL Datenbank-Implementierungstechniken 9 33

12 Unscharfe (fuzzy) Sicherungspunkte es werden nur die Seiten auf die Platte gezwungen, die vor dem letzten Checkpoint nicht ausgeschrieben wurden Kennzeichen: vermeidet Performance-Verlust durch Unterbrechen bzw. Blockieren von Transaktionen garantiert jeweils den vorletzten konsistenten Zustand der DB VL Datenbank-Implementierungstechniken 9 34 Recovery-Strategien Seitenersetzungsstrategien Propagierungsstrategien Einbringstrategien Konkrete Recovery-Strategien VL Datenbank-Implementierungstechniken 9 35 Seitenersetzungsstrategien UNDO (steal): jederzeit dürfen noch nicht freigegebene Seiten auslagert werden benötigt das Write-Ahead-Logging-Protokoll Sicherung von Protokollinformationen bevor Seitenauslagerung NO-UNDO ( steal): kein Auslagern von geänderten Seiten vor dem Commit einer Transaktion erlaubt vermeidet das Zurücksetzen von Transaktionen vereinfacht den Abbruch einer Transaktion hat Probleme, wenn keine der im Puffer modifizierten Seiten ausgelagert werden dürfen VL Datenbank-Implementierungstechniken 9 36

13 Propagierungsstrategien NO-REDO (force): beim Commit werden alle geänderten Seiten in die DB eingebracht REDO ( force): nach dem Commit können geänderte Seiten im Puffer verbleiben, ohne explizit auf dem stabilen Speicher gesichert werden Redo-Protokollinformationen im stabilen Speicher abgelegt VL Datenbank-Implementierungstechniken 9 37 Propagierungsstrategien (II) Vergleich: REDO-Variante ist im allgemeinen besser, weil sie den großen E/A-Aufwand beim Commit und damit schlechte Antwortzeiten vermeidet sie durch den Einsatz von Sicherungspunkten verbessert werden kann VL Datenbank-Implementierungstechniken 9 38 Einbringstrategien Direkte Zuordnung ( atomar = update-in-place): jede Seite im Puffer ist genau einer Seite in der DB zugeordnet Puffer-Seite wird beim Auslagern auf die entsprechende DB-Seite kopiert der alte Zustand geht verloren erfordert physisches Protokollieren Indirekte Zuordnung (atomar): für jede Puffer-Seite ist im stabilen Speicher ein Twin-Block reserviert Puffer-Seite wird jeweils auf den älteren Twin-Block ausgelagert selbst bei einem Fehler bleibt der letzte konsistente Zustand erhalten VL Datenbank-Implementierungstechniken 9 39

14 Einbringstrategien (II) Nachteil (der indirekten Zuordnung): 1. doppelter Speicherplatzbedarf 2. Seitentabellen für die zur Abbildung zwischen flüchtigen und stabilen Speicher passen nicht in den Hauptspeicher VL Datenbank-Implementierungstechniken 9 40 Konkrete Recovery-Strategien Kombination der Seitenersetzungs- und Propagierungsstrategien ergeben die möglichen Recoverystrategien: 1. UNDO/REDO 2. UNDO/NO-REDO 3. NO-UNDO/REDO 4. NO-UNDO/NO-REDO VL Datenbank-Implementierungstechniken 9 41 Recovery-Strategien im Überblick Propagierung Seitenersetzung force force steal kein REDO REDO kein UNDO kein UNDO steal kein REDO REDO UNDO UNDO VL Datenbank-Implementierungstechniken 9 42

15 UNDO/REDO jederzeit dürfen geänderte Seiten auslagert werden update-in-place erlaubt WAL und Propagierung sind mit Sicherungspunkten verkoppelt Vorteil: maximiert die Effizienz bei normalen Betrieb auf Kosten der Effizienz bei der Recovery Nachteile: After-Images brauchen viel Platz großer E/A-Overhead, wenn die Seiten von den meisten Transaktionen nur geringfügig geändert werden VL Datenbank-Implementierungstechniken 9 43 UNDO/NO-REDO alle geänderten Seiten werden spätestens beim Commit in die DB geschrieben vermeidet partielles Redo keine After-Images benötigt speichert Redo Einträge auf Archivmedium für globales Redo legt Undo Einträge (Before-Images) in der temporären Logdatei ab VL Datenbank-Implementierungstechniken 9 44 UNDO/NO-REDO (2) Vorteile: läßt sich gut mit einem Multi-Versionen-Scheduler kombinieren, da die Multiversionen als Before-Images genutzt werden können keine After-Images notwendig Nachteile: geänderte Hot-Spot -Seiten müssen nach jedem Commit in die DB geschrieben werden hoher E/A-Aufwand Verwaltungskosten für die Before-Images VL Datenbank-Implementierungstechniken 9 45

16 NO-UNDO/REDO alle Änderungen werden bis mindestens zum Commit im Puffer gehalten DB enthält nur committed Seiten Vorteile: Commit ist schnell und billig keine Before-Images nötig hohe Durchsatzrate, da wenig E/A bei normalem Betrieb Nachteile: großer Puffer nötig nach Absturz ist die DB konsistent, aber alt muß beim Neustart anhand von After-Images aktualisiert werden VL Datenbank-Implementierungstechniken 9 46 NO-UNDO/NO-REDO um NO-UNDO/NO-REDO zu garantieren, müssen alle Änderungen einer Transaktion beim Commit atomar in die DB geschrieben werden Änderungen werden zunächst auf Kopien geschrieben Kopien werden über Directories verwaltet, wobei ein Zeiger auf die letzte committed Kopie zeigt beim Commit wird der Zeiger auf die neue Kopie gelenkt und somit alle Änderungen atomar propagiert VL Datenbank-Implementierungstechniken 9 47 NO-UNDO/NO-REDO (II) Vorteil: kein Abbrechen und Wiederholen von Transaktionen notwendig Nachteile: Halten von Directories häufiger indirekter Zugriff darauf ist sehr teuer Platzbedarf für die Versionen Finden von uncommitted Versionen VL Datenbank-Implementierungstechniken 9 48

17 Recovery-Strategien im Vergleich Eigenschaft Strategie UNDO UNDO NO-UNDO NO-UNDO REDO NO-REDO REDO NO-REDO Zeitpunkt jederzeit spätestens nach dem beim Commit der Auslagerung beim Commit Commit Before-Images After-Images WAL-Protokoll VL Datenbank-Implementierungstechniken 9 49 Wiederanlauf im Fehlerfall Log 1. Analyse (Ermittlung der Winner und Loser) Systemfehler 2. Redo aller Änderungen (Winner und Loser) 3. Undo aller Loser-Änderungen VL Datenbank-Implementierungstechniken 9 50 REDO-Protokoll commit-punkt einer Transaktion: Für jedes A, das mit neuem Wert a von T belegt wird, wird (T, A, a) in das Log geschrieben Eintrag (T, commit) wird an das Log angehängt Alle Seiten des Log werden auf den stabilen Speicher geschrieben (Transaktion committed ) (T, A, a)-änderungen werden in der Datenbank (oder nur im Puffer) durchgeführt VL Datenbank-Implementierungstechniken 9 51

18 REDO-Protokoll (II) Untersuchung des Log-Buchs: Datenbank wird in den letztmöglichen konsistenten Zustand zurückgesetzt Alle zur Zeit gesetzten Sperren werden aufgehoben VL Datenbank-Implementierungstechniken 9 52 REDO-Protokoll (III) Recovery-Algorithmus: Log wird rückwärts durchlaufen Alle (T, commit)-einträge werden notiert; diese Transaktionen werden als erfolgreich ( Winner ) markiert Für jede erfolgreiche Transaktion T werden alle (T, A, a)-einträge gesucht und a in die Datenbank geschrieben Transaktionen ohne (T, commit) oder mit (T, abort) werden als Loser ignoriert Warnung an den Benutzer: T not committed! oder ein automatisches restart VL Datenbank-Implementierungstechniken 9 53 Das ARIES-Verfahren Recovery in drei Phasen: 1. Analysephase 2. Redo-Phase history repeating 3. Undo-Phase Kompensation der zum Fehlerzeitpunkt aktiven Transaktionen VL Datenbank-Implementierungstechniken 9 54

19 Vorgehensweise in ARIES am Beispiel LSN Log-Eintrag 10 update: T 1 schreibt Seite P 5 20 update: T 2 schreibt Seite P 3 30 commit: T 2 40 EOT: T 2 50 update: T 3 schreibt Seite P 1 60 update: T 3 schreibt Seite P 3 Systemfehler restart VL Datenbank-Implementierungstechniken 9 55 Vorgehensweise in ARIES am Beispiel (II) Analysephase: T 1 und T 3 aktiv Undo T 2 Commit Resultate nach Recovery auf stabilem Speicher P 1, P 3 und P 5 potentielle Dirty-Pages Redo-Phase: history repeating Änderungen von T 1 und T 3 wiederholt Undo-Phase: Änderungen von T 1 und T 3 in umgekehrter Reihenfolge rückgängig machen: Log-Einträge 60, 50 und dann 10 werden kompensiert VL Datenbank-Implementierungstechniken 9 56 ARIES: Notwendige Datenstrukturen Transaktionsliste: Informationen über alle laufenden Transaktionen für jede Transaktion Log-Sequenz-Nummer lastlsn: letzter Log-Eintrag der von dieser Transaktion geschrieben Dirty-Page-Liste: Einträge über Dirty-Pages Seiten mit Änderungen, die nicht bereits auf den stabilen Speicher gerettet wurden recoverylsn: Log-Eintrag, der die Seite in den Zustand dirty bewegt hat Log-Buch: prevlsn zum Verketten der Einträge einer Transaktion rückwärts in der Zeit; lastlsn ist Kopf dieser Verkettung VL Datenbank-Implementierungstechniken 9 57

20 Phasen des Wiederanlaufs Start der ältesten aktiven Transaktion Erste möglicherweise Checkpoint Ende des verlorengegangene Logs Änderung Analyse Redo Undo VL Datenbank-Implementierungstechniken 9 58 Phasen des Wiederanlaufs (II) 1. Analysephase Log wird vorwärts beginnend mit dem letzten Sicherungspunkt analysiert Analysephase findet Dirty-Pages und aktive Transaktionen firstlsn: älteste recoverylsn aller Dirty-Pages Anfangspunkt der Redo-Phase 2. Redo-Phase history repeating : Wiederholung aller Änderungen Redo auf Seiten-Ebene Für Redo kein Logging notwendig! VL Datenbank-Implementierungstechniken 9 59 Phasen des Wiederanlaufs (III) 3. Undo-Phase Undo für logische Operationen Logisches Undo besonders hilfreich bei Index-Operationen (da dort Probleme mit dem Zusammenspiel mit den erfolgreichen Transaktionen auftreten würden) Im Log-Buch werden Undo-Schritte als Kompensations-Log-Einträge CLR protolliert CLR enthält UndoNxtLSN als Verweis auf nächste Undo-Operation der bearbeiteten Transaktion VL Datenbank-Implementierungstechniken 9 60

21 Einsatz der CLR Log Schreibe Seite 1 Schreibe Schreibe Seite 1 Seite 1 Restart CLR für LSN 30 CLR für LSN 20 Restart CLR für LSN 10 Undo! Undo! Undo! LSN: VL Datenbank-Implementierungstechniken 9 61 Schattenspeicherverfahren Schattenspeicherverfahren für Recovery statt oder zusätzlich zu Logs Puffer Kopien auf dem stabilem Speicher halten Schattenspeicher Seitenzuordnungstabelle logische Seitenadressen Umschalten zwischen den Seitentabellen atomar boole sche Variable als kleinstmöglicher kritischer Speicherinhalt VL Datenbank-Implementierungstechniken 9 62 Schattenspeicherkonzept virtuelle Seiten ( tabellen) V0: i Schalter j Schatten ~j p physische Seiten V1: i j q aktuelles j r VL Datenbank-Implementierungstechniken 9 63

22 Vorteile des Schattenspeicher-Verfahren Führen eines Logs ist überflüssig, so daß der laufende Betrieb effizienter erfolgen kann Beim Wiederanlauf der Datenbank ist kein REDO notwendig Rücksetzen auf den letzten konsistenten Datenbankzustand ist sehr billige Operation VL Datenbank-Implementierungstechniken 9 64 Nachteile bei Schattenspeicher Durch viele Kopien von Schattenseiten entsteht "Datenmüll auf der Platte Seiten zu einer Relation werden durch die Erstellung von Kopien, die bei Transaktionsende zu Originalen werden, über die ganze Platte verteilt Relation kann nicht mehr als sequentielle Folge von Blöcken effizient mit Prefetching-Strategien gelesen werden Bei sehr großen Datenbanken werden Hilfstabellen zur Umsetzung der Seitenadressen so groß, daß sie selber (teilweise) auf den Sekundärspeicher ausgelagert werden VL Datenbank-Implementierungstechniken 9 65 Backup-Strategien Backup der gesamten Datenbank sehr aufwendig während des laufenden Betriebs ohne kaum Einschränkungen möglich Backup der Änderungen seit dem letztem Backup (inkrementelles Backup) jeweils Backup der neuen Daten seit dem letztem (auch inkrementellen) Backup u.u. Aufbau einer langen Kette von inkrementellen Backups, die bei Verlust der Datenbank bearbeitet werden muß, um aktuellen Stand der verlorengegangenen Datenbank wiederherzustellen VL Datenbank-Implementierungstechniken 9 66

23 Backup-Strategien (II) Inkrementelles Backup mit mehreren Ebenen mehrere Backup-Ebenen legen fest, welchen Umfang die Daten haben, für die Sicherung erfolgt Basis-Ebene 0 sichert die komplette Datenbank Backup geht zeitlich jeweils zum vorherigen Backup einer kleineren Stufe zurück je höher die Ebene, desto kürzer ist das Endstück der Datenbank-Historie, für die das Backup erfolgt Kette wiederherzustellender inkrementeller Backups ist durch die Anzahl der Ebenen begrenzt VL Datenbank-Implementierungstechniken 9 67 Multi-level inkrementelles Backup Level Zeit VL Datenbank-Implementierungstechniken 9 68