VLDatenbank-Implementierungstechniken–8–1 VLDatenbank-Implementierungstechniken–8–2 n 2 1 read, write,commit, abortreadwritewritereadreadwritewritereadreadwritefetchflush restartread, write,commit, abort VLDatenbank-Implementierungstechniken–8–3

(1)

9. Wiederherstellung und Datensicherheit

■ Einführung in Recovery

■ Recovery-Komponenten eines DBMSs

■ Fehlerklassen

■ Recovery-Klassen und Strategien

VL Datenbank-Implementierungstechniken – 8–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 Isolation- und Konsistenzeigenschaft einer Transaktion

■ Recovery-Komponenten sichern die Atomaritäts- und Dauerhaftigkeitseigenschaft einer Transaktion

Beteiligte Systemkomponenten

T₁ T₂ T_n

restart

read, write, commit, abort

Archiv read, write,

commit, abort

read write

fetch read Scheduler (SC) Manager (TM) Transaktions

Manager (RM)

DB- ...

Recovery

(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

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“

Fehlerklassifikation

Fehlerklassifikation 1. Transaktionsfehler 2. Systemfehler 3. Mediafehler

→unterschiedliche Recovery-Maßnahmen je nach Fehlerart

(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

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 – 8–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:

(4)

Szenario eines Systemfehlers

T1 T2

T3

T4 T5

t

Zeit Fehler

f

Szenario eines Systemfehlers (II)

■ Folgen:

◆ Inhalt des flüchtigen Speichers zum Zeitpunktt_fist unbrauchbar_→Transaktionen in unterschiedlicher Weise davon betroffen

■ Transaktionszustände:

◆ zum Fehlerzeitpunkt noch aktive Transaktionen (T2

undT₄)

◆ bereits vor dem Fehlerzeitpunkt beendete Transaktionen (T1,T3undT5)

Szenario eines Systemfehlers (III)

■ Probleme:

◆ Dauerhaftigkeitseigenschaft_⇒Effekte vonT1,T3und T5müssen dauerhaft in der DB sein

◆ Atomaritätseigenschaft_⇒Effekte vonT2undT4

dürfen nicht in der DB sein

(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

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

Protokollierungsarten

■ Log-Buch

■ physische versus logische Protokollierung

■ Sicherungspunkte

(6)

Prinzipieller Aufbau eines Log-Buchs

Schritt T1 T2 Log

1 lockA (T1, begin)

2 readA 3 A:=A−1

4 writeA (T1, A,10,9)

5 lockB 6 unlockA

7 lockA (T2, begin)

8 readA

9 A:=A×2

10 readB

11 writeA (T2, A,9,18)

12 commit (T2, commit)

13 unlockA

14 B:=B/A↓ (T1, abort)

Prinzipieller Aufbau eines Log-Buchs II

Ahat zu zu Anfang den Wert10

Vor dem ersten Schritt wird(T1, begin)eingetragen Vor Schritt 4 folgt(T1, A,10,9)

Vor Schritt 7 beginntT2mit(T2, begin) Vor Schritt 11 wird(T2, A,9,18)eingetragen Vor Schritt 12 folgt Abschluß vonT2:(T2, commit) Nach Schritt 14 wird Abbruch(T1, abort)geschrieben

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

(7)

Einträge im Log – Beispiel

[ #1, T1, BOT ]

[ #2, T₁, P_A, A=A+1, A=A-1, #1 ] [ #3, T2, BOT ]

[ #4, T2, PA, A=A×2, A=A/2, #3 ] [ #5, T2, commit, #4 ]

[ #6, T1, abort, #2 ]

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

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

(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

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

Szenario

Systemfehler nach einem Sicherungspunkt

T1 T2

T3

T4 T5 Sicherungspunkt

t t_s

Zeit Fehler

f

(9)

Physisches vs. logisches Protokollieren

Phys. Protokollieren Log. Protokollieren T1 Intswurden alle bis dahin angefallenen Änderungen über-

nommen (keine Wiederholung vonT1notwendig) T2 Partielles Zurücksetzen von

T2 mit Hilfe der Before- Images

Ausführung bistsprotokollier- ter inverser DML-Befehle in umgekehrter Reihenfolge bis BOT

T3 Partielles Wiederholen vonT3

mit Hilfe der After-Images

Ausführung nachtsprotokol- lierter Original-DML-Befehle bis Commit

T4 Alle Effekte von T4 mit Wiederherstellung des Zustands zum Zeitpunkttsimplizit entfernt (keine weiteren Maßnah- men erforderlich)

T5 Durch Wiederherstellen des Zustands zum Zeitpunkttsver- schwinden alle Auswirkungen vonT5 (T5 komplett wiederholen)

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 UNDObei abgebrochenen Transaktionen)

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

(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

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

Transaktionskonsistente SP (III)

T1

T2

T3

T4

Anmeldung Sicherungspunkt

Zeit

(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

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

Aktionskonsistente Sicherungspunkte (III)

T1 T2 T3

T4

Zeit

Periodische Sicherungspunkte

(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

Recovery-Strategien

■ Seitenersetzungsstrategien

■ Propagierungsstrategien

■ Einbringstrategien

■ Konkrete Recovery-Strategien

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

(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

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

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

(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

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

Recovery-Strategien im Überblick

Propagierung Seitenersetzung force _¬force

¬steal kein REDO REDO

kein UNDO kein UNDO

steal kein REDO REDO

UNDO UNDO

(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

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

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

(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

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

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

(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 √

− − −

Wiederanlauf im Fehlerfall

2. Redo aller Änderungen (Winner und Loser) 3. Undo aller Loser-Änderungen

1. Analyse (Ermittlung der Winner und Loser) Log

Systemfehler

R EDO -Protokoll

commit-Punkt einer Transaktion:

■ Für jedesA, das mit neuem WertavonTbelegt 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

(18)

R EDO -Protokoll (II)

Untersuchung des Log-Buchs:

■ Datenbank wird in den letztmöglichen konsistenten Zustand zurückgesetzt

■ Alle zur Zeit gesetzten Sperren werden aufgehoben

R EDO -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 TransaktionTwerden alle (T, A, a)-Einträge gesucht undain 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

Das ARIES-Verfahren

Recovery in drei Phasen:

1. Analysephase 2. Redo-Phase

„history repeating“

3. Undo-Phase

Kompensation der zum Fehlerzeitpunkt aktiven Transaktionen

(19)

Vorgehensweise in ARIES am Beispiel

LSN Log-Eintrag

10 update:T1schreibt SeiteP5

30 commit:T2

40 EOT:T2

×

Systemfehler_→restart

Vorgehensweise in ARIES am Beispiel (II)

■ Analysephase:T1undT3aktiv_→Undo

◆ T₂Commit_→Resultate nach Recovery auf stabilem Speicher

◆ P1,P3undP5potentielle „Dirty-Pages“

■ Redo-Phase: „history repeating“

Änderungen vonT1undT3wiederholt

■ Undo-Phase:

Änderungen vonT1undT3in umgekehrter Reihenfolge rückgängig machen: Log-Einträge 60, 50 und dann 10 werden kompensiert

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

(20)

Phasen des Wiederanlaufs

Start der ältesten aktiven Transaktion

Erste möglicherweise Checkpoint Ende des Änderung

verlorengegangene Logs

Analyse Redo Undo

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!

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

(21)

Einsatz der CLR

Schreibe Seite 1

LSN: 10

CLR für LSN 30

40 Schreibe Schreibe

Seite 1 Seite 1

CLR für LSN 20

50

Restart

CLR für LSN 10

60

Restart

20 30

Undo! Undo! Undo!

Log

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

Schattenspeicherkonzept

p Schatten ~j

q Schalter

i V0:

V1:

physische Seiten

virtuelle Seiten (−tabellen) j

j i

(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

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

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

(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-Ebene0sichert 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

Multi-level inkrementelles Backup

Level 0 1 1 2 2 1 2 2

Zeit