Chapter11 PDF

Anwendersoftware (AS)
Datenbanken und
Informationssysteme
Kapitel 11: Logging und Recovery
Bernhard Mitschang
Universitt Stuttgart
Wintersemester 2013/2014
Teile zu diesem Folienskript beruhen auf einer hnlichen Vorlesung, gehalten von Prof. Dr. T. Hrder am
Fachbereich Informatik der Universitt Kaiserslautern und Prof. Dr. N. Ritter am Fachbereich Informatik der
Universitt Hamburg. Fr dieses Skriptum verbleiben alle Rechte (insbesondere fr Nachdruck) bei den
Autoren.
Logging und Recovery
bersicht
Einfhrung
Logging-Strategien
Einbringstrategie
Zusammenspiel mit der DB-Pufferverwaltung (Seitenersetzung, Ausschreibstrategie)
Commit-Behandlung, Gruppen-Commit
Sicherungspunkte (Checkpoints)
Crash-Recovery
physisches/logisches und Zustands-/bergangs-Logging

Eintrags- vs. Seiten-Logging
Aufbau der Log-Datei
Klassifikation von Recovery-Verfahren
Fehlermodell
Recovery-Arten
Allgemeine Restart-Prozedur
Crash-Recovery mit dem Schattenspeicherkonzept
Gertefehler-Recovery
Erstellung von Archivkopien
Anforderungen
Aufgabe des DBMS

Automatische Behandlung aller erwarteten Fehler
Begrenzung und Behebung der zur Laufzeit mglichen Fehler
(wie auch bei anderen fehlertoleranten Systemen)
Reparatur der statischen Struktur der DB
Erwartete Fehler
DB-Operation wird zurckgewiesen
Commit wird nicht akzeptiert
Stromausfall
Gerte funktionieren nicht (Spur, Zylinder, Platte defekt)
...
Fehlerarten
Auswirkung eines
Fehlers auf
Fehlertyp
Fehlerklassifikation
Transaktionsfehler
eine Transaktion
Verletzung von Systemrestriktionen

Versto gegen Sicherheitsbestimmungen
bermige Betriebsmittelanforderungen
Anwendungsbedingte Fehler
z. B. falsche Operationen und Werte
mehrere Transaktionen
alle Transaktionen,
d.h. das gesamte
Systemverhalten
Hardware-Fehler, Software-Fehler, Umgebungsfehler

Systemzusammenbruch mit Verlust der Hauptspeicherinhalte
Systemfehler
Zerstrung von Sekundrspeichern
Gertefehler
Zerstrung des Rechenzentrums
Katastrophe
Geplante Systemschlieung
berlast des Systems
Schwierigkeiten bei der Betriebsmittelvergabe
Verklemmung mehrerer Transaktionen
Recovery-Arten
4
Voraussetzungen
Allgemeine Probleme
Fehlererkennung
Fehlereingrenzung
Abschtzung des Schadens
Durchfhrung der Recovery (Forward-Recovery vs. Backward-Recovery)
Voraussetzungen fr die Wiederherstellung der Daten

Sammeln redundanter Informationen whrend des Normalbetriebs (Logging)
quasi-stabiler Speicher
fehlerfreier DBMS-Code
fehlerfreie Log-Daten
Unabhngigkeit der Fehler
Forward-Recovery vs. Backward Recovery
Wie soll Recovery durchgefhrt werden?

Forward-Recovery
Non-Stop-Paradigma (Prozesspaare usw.)
i. A. nicht anwendbar
Fehlerursache hufig falsche Programme, Eingabefehler u. .
durch Fehler unterbrochene TA sind zurckzusetzen
Backward-Recovery
setzt voraus, dass auf allen Abstraktionsebenen genau definiert ist, auf
welchen Zustand die DB im Fehlerfall zurckzusetzen ist
Zurcksetzen auf konsistenten Zustand und Wiederholung
Forward-Recovery vs. Backward Recovery

Normale
Verarbeitung
Fehler
entdeckt
Problemorientierte
Fehlerbehandlung
Ja
Verarbeitung
fortsetzen
Nein
Backward
Recovery
Ja
Rcksetzen
Forward
Recovery
Systemorientierte
Fehlerbehandlung
(Sicherungspunkt)
Nein
Benutzer entscheidet,
Was zu tun ist
Forward
Recovery
manuell
7
Systemkomponenten
Daten werden in die physische DB

geschrieben und in die materialisierte
DB eingebracht
Pufferung von Log-Daten im
Hauptspeicher (Log-Puffer)
AP1
AP2
Ausschreiben sptestens bei Commit
Einsatz der Log-Daten
APn
temporre
Log-Datei
Log-Puffer
DBMS
DB-Puffer
Temporre Log-Datei zur Behandlung

von Transaktions- und Systemfehlern
- DB + temp. Log DB
Behandlung von Gertefehlern
Archiv-Log
- Archiv-Kopie + Archiv-Log DB
permanente
Datenbank
Archiv-Kopie der DB
Zielzustand nach Recovery
Transaktionsparadigma verlangt
Alles-oder-Nichts-Eigenschaft von Transaktionen
Dauerhaftigkeit erfolgreicher nderungen
Zielzustand nach erfolgreicher Recovery
jngster transaktionskonsistenter DB-Zustand
Durch die Recovery-Aktionen ist der jngste Zustand vor Erkennen des Fehlers
wiederherzustellen, der allen semantischen Integrittsbedingungen entspricht, der also
ein mglichst aktuelles, exaktes Bild der Miniwelt darstellt.
Zustand der Systemumgebung?

Betriebssystem, Anwendungssystem, andere Komponenten
Umgebung
AW
DB
9
Transaktions-Recovery (R1)
Zurcksetzen einzelner (noch nicht abgeschlossener) Transaktionen im laufenden

Betrieb (Transaktionsfehler, Deadlock)
Arten
Vollstndiges Zurcksetzen auf Transaktionsbeginn (TA-UNDO)
T1
Undo T1
Recovery
temporre
Log-Datei
Partielles Zurcksetzen auf Rcksetzpunkt (Savepoint) innerhalb der TA
Undo T1
T1
Recovery
Savpoint
temporre
Log-Datei
10
Crash-Recovery (R2)
Recovery nach einem Systemfehler

Wiederherstellen des jngsten transaktionskonsistenten DB-Zustands
Notwendige Aktionen
(partielles) REDO fr erfolgreiche Transaktionen,
d.h. Wiederholung verloren gegangener nderungen
UNDO aller durch Ausfall unterbrochenen Transaktionen
d.h. Entfernen der nderungen aus der permanenten DB
T1
Redo T1
T2
Undo T2
T3
Recovery
RedoT3
Systemfehler
temporre
Log-Datei
permanente
Datenbank
11
Medien-Recovery (R3)
Recovery nach Gertefehler

Spiegelplatten bzw.
Vollstndiges Wiederholen (REDO) aller nderungen (erfolgreich
abgeschlossener Transaktionen) auf einer Archivkopie
T1
Redo T1
T3
RedoT3
Recovery
Gertefehler
temporre
Log-Datei
Archivkopie
der DB
permanente
Datenbank
12
Katastrophen-Recovery (R4)
Recovery nach Katastrophe

Nutzung einer aktuellen DB-Kopie in einem entfernten System oder
stark verzgerte Fortsetzung der DB-Verarbeitung mit repariertem/neuem System
auf der Basis gesicherter Archivkopien (Datenverlust)
13
bersicht
Einfhrung
Logging-Strategien
Einbringstrategie
Crash-Recovery

Fehlermodell
Recovery-Arten
14
Logging
Aufgaben
Sammlung redundanter Daten bei nderungen im Normalbetrieb (DO) als
Voraussetzung fr Recovery
Einsatz im Fehlerfall (Undo-, Redo-Recovery)
Do-Redo-Undo-Prinzip
DB-Zustandalt
DO
DB-Zustandneu
DB-Zustandalt
Log-Satz
REDO
Log-Satz
DB-Zustandneu
DB-Zustandneu
Log-Satz
UNDO
DB-Zustandalt
CLR
CLR: Compensation Log Record (fr Crash whrend Recovery)

15
Logging-Verfahren
Logging kann auf jeder DBMS-Systemebene erfolgen

Sammeln von ebenenspezifischer Log-Information setzt voraus, dass bei der
Recovery die Konsistenzbedingungen der darunter liegenden
Abbildungsschicht im DB-Zustand erfllt sind
Klassifikation der Logging-Verfahren
Logging
logisch
bergangsLogging
SeitenLogging
physisch
kombiniert
(byte-orientiert)
(physiological)
ZustandsLogging
...
bergangsLogging
EintragsLogging
16
Logisches Logging
Protokollierung der ndernden DML-Befehle mit ihren Parametern

Vorteil:
minimaler Log-Umfang
Generelles UNDO-Problem:
mengenorientierte Aktualisierungsoperation, z. B. DELETE <relation>
Voraussetzung
nach einem Systemausfall mssen auf der permanenten Datenbank DMLOperationen ausfhrbar sein, d.h., sie muss wenigstens operationskonsistent
sein (Aktionskonsistenz)
verzgerte (indirekte) Einbringstrategie erforderlich,
d.h. fr Update-in-Place nicht anwendbar
17
Physisches Logging
Protokollierung der Objekte vor und nach einer nderung

Zustands-Logging
alte Zustnde (Before-Images) und neue Zustnde (After-Images) genderter
Objekte werden in die Log-Datei geschrieben
Seiten-Logging: Log-Granulat eine Seite
Eintrags-Logging: Log-Granulat ein Eintrag/Satz
bergangs-Logging
Protokollierung der Differenz zwischen Before- und After-Image
Eigenschaften:
physisches Logging ist bei direkten und verzgerten Einbringstrategien
anwendbar
aufwendig und unntig starr v.a. bezglich Lsch- und Einfgeoperationen
einfgen
Seitenkopf
genderte Eintrge
18
Aufwand bei physischem Zustandslogging
einfachste Form
der Implementierung:
Seiten-Logging
Freispeicherverwaltung FPA
Zuordnungstabelle ZT
fi
1 2 3
1
2
3
i
Datenseite Pi
X1
j Adr(X1)
m
Operation: STORE X-RECORD (X1)

Aufwand
Datenseite
ZT
FPA
n Zugriffspfadseiten
normaler Betrieb (DO)
neues Pi
Adr(X1)
fi
n DSneu
UNDO-Log
altes Pi
alter Inhalt
alter Inhalt
n DSsalt
REDO-Log
neues Pi
Adr(X1)
fi
n DSneu
19
Logging: Anwendungsbeispiel
nderungen bezglich einer Seite A

1. ein Objekt a wird in Seite A eingefgt (A1 A2)
2. in A wird ein bestehendes Objekt balt nach bneu gendert (A2 A3)
logisches Logging
Zustnde
bergnge
physisches Logging
Seiten-Logging: Protokollierung der
Before- und After-Images
1. A1 und A2
2. A2 und A3
Protokollierung der Operationen

mit Parameter
1. Insert (a)
2. Update (balt, bneu)
bergangs-Logging
1. A1 A2
2. A2 A3
Rekonstruktion von Seiten beim bergangs-Logging

A1 als Anfangs- oder A3 als Endzustand seien verfgbar
REDO-Recovery
UNDO-Recovery
A1 (A1 A2) = A2
A2 (A2 A3) = A3
A3 (A2 A3) = A2
A2 (A1 A2) = A1
20
Physiologisches Logging
Kombination aus physischer und logischer Protokollierung
physical-to-a-page, logical-within-a-page
Protokollierung von elementaren Operationen innerhalb einer Seite
jeder Log-Satz bezieht sich auf eine Seite
Technik ist mit Update-in-Place vertrglich
21
Bewertung der Logging-Verfahren

LoggingAufwand im
Normalbetrieb
RestartAufwand im
Fehlerfall
(Crash)
SeitenzustandsLogging
--
Seitenbergangs
-Logging
(Differenzen)
Eintrags-Logging
++
--
physiologisches
Logging
Logisches
Logging
Eintrags-Logging vs. Seiten-Logging

Vorteile von Eintrags-Logging
geringerer Platzbedarf
weniger Log-E/As
erlaubt bessere Pufferung von LogDaten (Gruppen-Commit)
untersttzt feine Synchronisationsgranulate
(Seiten-Logging Synchronisation
auf Seitenebene)
Nachteil von Eintrags-Logging

Recovery ist komplexer als mit
Seiten-Logging
z.B. mssen Seiten vor der
Anwendung der Log-Stze wieder in
den Speicher eingelesen werden
22
Satzarten der temporren Log-Datei
Verschiedene Satzarten erforderlich

BOT-, Commit-, Abort-Satz
nderungssatz
- UNDO-Informationen, z.B. Before-Images
- REDO-Informationen, z.B. After-Images
Sicherungspunkt-Stze
23
Struktur der Log-Eintrge fr nderungsoperationen:

[LSN, TAID, PageID, Redo, Undo, PrevLSN]
LSN: Log Sequence Number
eindeutige Kennung des Log-Eintrags
LSNs mssen monoton aufsteigend vergeben werden
chronologische Reihenfolge der Protokolleintrge kann dadurch ermittelt
werden
Seitenkopf einer DB-Seite enthlt LSN der zuletzt durchgefhrten nderung
(Seiten-LSN)
TAID: Transaktionskennung der TA, die die nderung durchgefhrt hat
24
Struktur der Log-Eintrge fr nderungsoperationen:

[LSN, TAID, PageID, Redo, Undo, PrevLSN]
PageID:
Kennung der Seite, auf der die nderungsoperation vollzogen wurde
wenn die nderung mehr als eine Seite betrifft, mssen entsprechend viele
Log-Eintrge generiert werden
Redo:
Redo-Information gibt an, wie die nderung nachvollzogen werden kann
Redo ist nur erforderlich, wenn Seiten-LSN < LSN des Log-Eintrags
Undo:
Undo-Information beschreibt, wie die nderung rckgngig gemacht werden
kann
Undo ist nur erforderlich, wenn Seiten-LSN LSN des Log-Eintrags
PrevLSN:
ist ein Zeiger auf den vorhergehenden Log-Eintrag der jeweiligen TA
diesen Eintrag bentigt man aus Effizienzgrnden
25
Temporre Log-Datei
Beispiel
26
Temporre Log-Datei
Log ist eine sequentielle Datei

Schreiben neuer Protokolldaten an das aktuelle Dateiende
Log-Daten sind fr Crash-Recovery nur begrenzte Zeit relevant
Undo-Stze fr erfolgreich beendete TA werden nicht
mehr bentigt
nach Einbringen der Seite in die DB wird Redo-Information
nicht mehr bentigt
Redo-Information fr Medien-Recovery ist im Archiv-Log zu sammeln!
27
Temporre Log-Datei
Ringpuffer-Organisation der Log-Datei

lteste Redo-Information
einer genderten Seite
lteste Redo-Information, die

nicht im Archiv-Log vorliegt
im DB-Puffer
Beginn der ltesten TA
(MinLSN)
1 2 3
...
A
logischer
Log-Anfang
...
E
aktuelles
logisches
Log-Ende
28
Beispiel DB2
primre Log-Dateien werden beim

Start der Datenbank allokiert
sekundre Log-Dateien werden bei
Bedarf allokiert
Zwei Log-Modi:
Circular Logging: Log-Dateien sind als
Ringpuffer organisiert. Es sind nur
vollstndige Backups mglich
(offline).
Archive Logging: Log-Dateien werden
archiviert. Ausgehend von einem
Datenbank-Backup ist Recovery bis
zum Ende des Logs oder bis zu einem
bestimmten Zeitpunkt mglich.
Gespiegelte Log-Dateien mglich
Parameter
Bereich
Beschreibung
logbufsz
DB
Gre des LogPuffers
logprimary
DB
Anzahl primrer LogDateien
logsecond
DB
maximale Anzahl
sekundrer LogDateien
logfilsiz
DB
Gre der einzelnen

Log-Dateien
logpath
DB
Pfad zu den LogDateien
mirrorlogpath
DB
Pfad fr gespiegelte
Log-Dateien
logretain
DB
Legt fest, ob LogDateien archiviert

werden oder nicht
29
bersicht
Einfhrung
Logging-Strategien
Einbringstrategie
Crash-Recovery

Fehlermodell
Recovery-Arten
30
Wichtige Abhngigkeiten
Einbringstrategie
direktes Einbringen von nderungen (non-atomic)
verzgertes Einbringen von nderungen (atomic)
Ersetzungsstrategie
Verdrngen schmutziger Seiten (steal)
nur Verdrngung von Seiten abgeschlossener TAs (nosteal)
Ausschreibstrategie
Ausschreiben notwendigerweise bei Commit (force)
Ausschreiben mglicherweise nach Commit (noforce)
Seitenzuordnungsstrukturen
Pufferverwaltung
Wahl des Sperrgranulats

Commit-Behandlung
Synchronisation
31
WAL-Prinzip und Commit-Regel
WAL-Prinzip (Write Ahead Log)

Vor dem Schreiben einer schmutigen nderung in die materialisierte
Datenbank muss die zugehrige Undo-Information (z.B. Before-Images) in die
Log-Datei geschrieben werden.
Commit-Regel (Force-Log-at-Commit)
Bevor das Commit einer TA ausgefhrt werden kann, sind fr ihre
nderungen ausreichende Redo-Informationen (z. B. After-Images) in der
Log-Datei zu sichern.
Ausschreibezeitpunkte des Log-Puffers:

wenn er vollstndig gefllt ist
aufgrund des WAL-Prinzips
aufgrund der Commit-Regel
32
Einbringstrategie
non-atomic / direkt / update-in-place

genderte Seite wird immer in denselben Block auf Platte zurckgeschrieben
Schreiben ist gleichzeitig Einbringen in die permanente DB
atomares Einbringen mehrerer genderter Seiten ist nicht mglich
Undo- RedoInfo
Info
U(C) R(C') A
Log-Puffer U(B)
DB-Seiten
B'
DB-Puffer
R(B')
C'
U(C)
temp. Log-Datei
DB
C'
WAL-Prinzip:
Write Ahead Log fr Undo-Info
U(B) vor B und U(C) vor C'
Commit-Regel:
Ausschreiben der Redo-Info
sptestens bei Commit
R(C) + R(B) vor Commit
33
Einbringstrategie
atomic / verzgert
z. B. in System R, SQL/DS
genderte Seite wird in separaten Block auf Platte geschrieben, Einbringen in
die DB erfolgt spter
Seitentabelle gibt aktuelle Adresse einer Seite an
verzgertes, atomares Einbringen mehrerer nderungen ist durch Umschalten
von Seitentabellen mglich
aktions- oder transaktionskonsistente DB auf Platte
logisches Logging anwendbar
34
Einbringstrategie
atomic / verzgert
Undo- RedoInfo
Info
U(C) R(C') A
Log-Puffer U(B)
DB-Seiten
B'
DB-Puffer
R(B')
C'
a
laufende
c'
alte
R
a
temp. Log-Datei
DB
C'
Seitentabelle
WAL-Prinzip:
Write Ahead Log fr Undo-Info
U(B) und U(C) vor Sicherungspunkt
Commit-Regel:
Ausschreiben der Redo-Info
sptestens bei Commit
R(C) + R(B) vor Commit
35
Ersetzungsstrategie
Problem: Ersetzung schmutziger Seiten

steal
genderte Seiten knnen jederzeit, insbesondere vor EOT der ndernden TA,
ersetzt und in die permanente DB eingebracht werden
groe Flexibilitt zur Seitenersetzung
Undo-Recovery vorzusehen (TA-Abbruch, Systemfehler)
steal erfordert Einhaltung des WAL-Prinzips
nosteal
Seiten mit schmutzigen nderungen drfen nicht ersetzt werden
Probleme bei langen nderungs-TA
es ist keine Undo-Recovery auf der permanenten DB vorzusehen
36
Ausschreibstrategie
Problem: Ersetzung schmutziger Seiten

force
alle genderten Seiten werden sptestens bei EOT (Commit) in die
permanente DB eingebracht (Durchschreiben)
hoher Schreibaufwand
Antwortzeitverlngerung fr nderungs-TA
groe DB-Puffer werden schlecht genutzt
keine Redo-Recovery nach Rechnerausfall
noforce
kein Durchschreiben der nderungen bei EOT
beim Commit werden lediglich Redo-Informationen in die Log-Datei
geschrieben (Commit-Regel)
Redo-Recovery nach Rechnerausfall
37
Ersetzungsstrategie/Ausschreibstrategie
force
noforce
steal
nosteal
Undo-Recovery
keine Redo-Recovery
fr non-atomic nicht mglich
Undo-Recovery
Redo-Recovery
keine Undo-Recovery
Redo-Recovery
non-atomic, nosteal force

non-atomic, force steal
38
Sperrverwaltung
DB
r1
r1
r1
r2
r2
r2
r1 -> r1
T1
r2 -> r2
T2
Abhngigkeit: Log-Granulat muss kleiner oder gleich Sperrgranulat sein

Beispiel:
Sperren auf Satzebene
Logging auf Seitenebene (Before- und After-Images)
Undo (Redo) einer nderung kann parallel durchgefhrte nderungen
derselben Seite berschreiben (lost update)
commit
Undo r1' und r2'!?
T2
39
Commit-Behandlung
Forderungen:
nderungen einer TA sind mit Commit zuzusichern
andere TA drfen nderungen erst sehen, wenn Durchkommen der
ndernden TA gewhrleistet ist
(Problem des rekursiven Zurcksetzens)
Beginn der Commit-Behandlung
T1
Unlock(x)
w(x)
T2
r(x)
EOT
40
Commit-Behandlung
zweiphasige Commit-Bearbeitung:
Phase 1: Wiederholbarkeit der TA sichern
Schreiben der Log-Daten
ggf. noch nderungen sichern
(inkl. Commit-Satz) auf Platte
Commit-Satz auf Log schreiben
Phase 2: nderungen sichtbar machen
Freigabe der Sperren
Benutzer kann nach Phase 1 vom erfolgreichen Ende der TA
informiert werden (Ausgabenachricht)
Beispiel
Commit Phase 1 bei force, steal:
1. Before-Images in Log-Datei schreiben
2. Force der genderten DB-Seiten
3. After-Images (fr Archiv-Log) und Commit-Satz schreiben
Commit Phase 1 bei noforce:
lediglich 3. notwendig
Sperrfreigabe
41
Gruppen-Commit
Log-Datei ist pot. Leistungsengpass

pro nderungstransaktion wenigstens
1 Log-E/A
max. ca. 250 sequentielle
Schreibvorgnge pro Sekunde (1
Platte)
Gruppen-Commit bedeutet gemeinsames
Schreiben der Log-Daten mehrerer TA
Pufferung der Log-Daten in LogPuffer (1 oder mehrere Seiten)
Voraussetzung: Eintrags-Logging
Ausschreiben des Log-Puffers erfolgt,
wenn er voll ist bzw. Timer abluft
nur geringe Commit-Verzgerung
Log-Daten/
Commit-Satz
in Log-Puffer
Gruppen-Commit erlaubt Reduktion auf

0.1 - 0.2 Log-E/As pro TA
Einsparung an CPU-Overhead fr E/A
reduziert CPU-Wartezeiten
dynamische Festsetzung des TimerWertes durch DBMS wnschenswert
Gruppen-Commit ermglicht demnach
Durchsatzverbesserung v.a. bei LogEngpass oder hoher CPU-Auslastung

Sperrfreigabe
Gruppen-Commit
42
Pr-Commit
Sperren bereits freigeben, wenn Commit-Satz im Log-Puffer steht (vor Schreiben

auf Log-Platte)
TA kann nur noch durch Systemfehler scheitern
In diesem Fall scheitern auch alle abhngigen TA, die ungesicherte nderungen
aufgrund der vorzeitigen Sperrfreigabe gesehen haben
In allen drei Verfahren wird der Benutzer erst nach Schreiben des Commit-Satzes
auf Platte vom TA-Ende informiert
Log-Daten/
Commit-Satz
in Log-Puffer

Sperrfreigabe
Pr-Commit
43
Sicherungspunkte / Checkpoints
Motivation:
Manahme zur Begrenzung des Redo-Aufwands nach Systemfehlern (noforce)
ohne Sicherungspunkte mssten potentiell alle nderungen seit Start des
DBMS wiederholt werden
Besonders kritisch: Hot-Spot-Seiten
x
S1
x
x
Start
des
DBMS
x x
xx x
S2
S3
Sp
Seiten, die beim

Systemausfall im
Puffer standen
Systemausfall
t
44
Sicherungspunkte / Checkpoints
Verwaltungsinformation
Log-Datei
- BEGIN_CHKPT-Satz
- Sicherungspunkt-Informationen, z.B. Liste der aktiven TA
- END_CHKPT-Satz
Log-Adresse des letzten Sicherungspunkt-Satzes wird in spezieller RestartDatei gefhrt
Sicherungspunkte und Einbringverfahren

atomic
- Zustand der permanenten DB beim Crash entspricht dem zum Zeitpunkt des letzten
erfolgreichen Sicherungspunktes
non-atomic
- Zustand der permanenten DB enthlt alle ausgeschriebenen (eingebrachten)
nderungen bis zum Crash
45
Arten von Sicherungspunkten
Direkte Sicherungspunkte
alle genderten Seiten im DB-Puffer
werden in die permanente DB
eingebracht
Redo-Recovery beginnt bei letztem
Sicherungspunkt
Nachteil: lange Totzeit des Systems,
da whrend des Sicherungspunktes
keine nderungen durchgefhrt
werden knnen
Problem wird durch groe
Hauptspeicher verstrkt
Transaktionskonsistente oder
aktionskonsistente Sicherungspunkte
Indirekte/Unscharfe
Sicherungspunkte
(Fuzzy Checkpoints)
kein Hinauszwingen genderter
Seiten
nur Statusinformationen
(Pufferbelegung, Menge aktiver TA,
offene Dateien etc.) werden in die
Log-Datei geschrieben
sehr geringer SicherungspunktAufwand
Redo-Informationen vor letztem
Sicherungspunkt sind i. A. noch zu
bercksichtigen
Sonderbehandlung von Hot-SpotSeiten
46
Transaktionsorientierte Sicherungspunkte
TOC = transaction-oriented checkpoint

Force kann als spezieller
Sicherungspunkt-Typ aufgefasst
werden: force toc
Seiten genau einer TA werden
ausgeschrieben
Systemfehler
T1
T2
T3
c (T1)
c (T2)
Sicherungspunkte
Eigenschaften
EOT-Behandlung erzwingt das
Ausschreiben aller genderten
Seiten der TA aus dem DBPuffer
bernahme aller nderungen
in DB
Vermerk in Log-Datei
nur atomic ermglicht
atomares Einbringen mehrerer
Seiten
zumindest bei direktem
Einbringen der Seiten ist
demnach Undo-Recovery
vorzusehen (steal)
Abhngigkeit:
non-atomic, force steal
47
Transaktionskonsistente Sicherungspunkte
TCC = transaction-consistent
checkpoint (logisch konsistent)
Sicherungspunkt bezieht sich immer
auf alle TA
Sicherungspunkt
anmelden
Sicherungspunkt
erzeugen
ci
Eigenschaften
Ausschreiben ist bis zum Ende aller
aktiven nderungs-TA zu verzgern
neue nderungs-TA mssen warten,
bis Sicherungspunkt erzeugt
Crash-Recovery startet bei letztem
Sicherungspunkt
T1
T2
T3
T4
ci-1
t
Totzeit des DBS

fr neue Transaktionen
ci
Systemfehler
48
Aktionskonsistente Sicherungspunkte
ACC = action-consistent checkpoint

(speicherkonsistent)
Sicherungspunkt bezieht sich immer
auf alle TA
Sicherungspunkt
anmelden
Sicherungspunkt
erzeugen
ci
T1
T2
Eigenschaften:
- keine nderungsanweisungen
whrend des Sicherungspunktes
- geringere Totzeiten als bei TCC
- Redo-Recovery wird durch
Sicherungspunkt begrenzt
- Undo-Recovery wird nicht durch
letzten Sicherungspunkt begrenzt
sondern durch MinLSN (LSN des
ersten Log-Eintrags der zum
Sicherungspunkt ltesten TA)
Abhngigkeit: ACC steal
T3
T4
Totzeit des DBS c
i
fr Operationen
ci-1
Systemfehler
t
49
Unscharfe Sicherungspunkte (Fuzzy Checkpoints)

Ziel:
Synchrones Ausschreiben genderter
Seiten vermeiden
Bestimmung der Log-Position, an der
Redo-Recovery beginnen muss
S1
write
StartLSN und MinDirtyPageLSN

Pufferverwalter merkt sich zu jeder
genderten Seite die StartLSN,
d.h. Log-Satz-Adresse der ersten
nderung seit Einlesen von Platte
bzw. seit dem letzten Ausschreiben
der nderungen
MinDirtyPageLSN = MIN(StartLSN)
REDO-Recovery nach Crash beginnt
bei MinDirtyPageLSN
write
Problem
Sicherungspunkt
Seiten, die beim

Systemausfall im
Puffer standen
S2
S3
Log
10
20
30
40
50
60
70
(LSN)
50
Unscharfe Sicherungspunkte
Sicherungspunkt-Information
MinDirtyPageLSN,
Liste der aktiven TA,
LSN ihres ersten Eintrags (MinLSN),
...
genderte Seiten werden asynchron ausgeschrieben
ggf. Kopie der Seite anlegen (fr Hot-Spot-Seiten)
Seite ausschreiben
StartLSN anpassen / zurcksetzen
Eigenschaften:
DB auf Platte bleibt fuzzy, d.h. nicht aktionskonsistent
nur bei Update-in-Place (non-atomic) relevant
Aufwand fr Sicherungspunkt reduziert
Abhngigkeit: atomic FuzzyCP
51
Kombination von DB-Recovery-Verfahren

non-atomic, nosteal noforce | force TOC | non-atomic,force steal | ACC steal | atomic FuzzyCP
DB-Recovery-Verfahren
EinbringStrategie
non-atomic
nosteal
force
noforce
Sicherungspunkt
TOC
TCC ACC Fuzzy
Systembeispiele
IMS
DMS 1100
EOTBehandlung
DB2
Adabas
Tandem
UDS
ARIES
noforce
TCC Fuzzy
DB Cache
steal
IMS FP
Seitenersetzung
atomic
steal
nosteal
force
noforce
force
noforce
TOC
TCC ACC
TOC
TCC
TOSP
TWIST
AIM
System R
SQL/DS
52
Beispiel DB2
Gruppen-Commit
fasst mincommit TA zusammen
maximale Verzgerung: 1 Sek.
Parameter
mincommit
Soft Checkpoints
Unscharfe Sicherungspunkte
Vorgabe hinsichtlich der Anzahl der
fr die Recovery relevanten
Log-Dateien steuert die Hufigkeit
softmax
Bereich
Beschreibung
DB
Anzahl der TA, die in

einem GruppenCommit zusammengefasst werden
DB
Steuert die
Hufigkeit der
Checkpoints
Overhead fr Logging reduzieren:

Logging fr einzelne Tabellen unterbinden
CREATE TABLE NOT LOGGED INITIALLY
Logging wird fr in einer Session deklarierte
temporre Tabellen nicht durchgefhrt
DECLARE GLOBAL TEMPORARY TABLE
53
bersicht
Einfhrung
Logging-Strategien
Einbringstrategie
Crash-Recovery

Fehlermodell
Recovery-Arten
54
Crash-Recovery
Ziel
Herstellung des jngsten

transaktionskonsistenten DBZustandes aus permanenter DB und
temporrer Log-Datei
bei non-atomic (update-in-place)

Zustand der permanenten DB nach
Crash unvorhersehbar (chaotisch)
kein logisches Logging anwendbar
ein Block der permanenten DB ist
entweder
- aktuell
- oder veraltet (noforce) Redo
- oder schmutzig (steal) Undo
bei atomic
permanente DB entspricht Zustand
des letzten erfolgreichen Einbringens
(Sicherungspunkt)
zumindest aktionskonsistent
DML-Befehle ausfhrbar
logisches Logging mglich
force:
- kein Redo
noforce:
- transaktionskonsistentes Einbringen
Redo, jedoch kein Undo
- aktionskonsistentes Einbringen
Undo + Redo
56
1. Analyse-Phase
vom letzten Sicherungspunkt bis zum Log-Ende
Bestimmung von Gewinner- und Verlierer-TA sowie der Seiten, die von ihnen
gendert wurden
2. Undo-Phase
Rcksetzen der Verlierer-TA durch Rckwrtslesen des Logs bis zum BOTSatz der ltesten Verlierer-TA
UNDO nur, wenn Seiten-LSN Log-Satz-LSN
3. Redo-Phase
Vorwrtslesen des Log: Startpunkt abhngig vom Sicherungspunkt-Typ
REDO nur, wenn Seiten-LSN < Log-Satz-LSN
selektives Redo bei Seitensperren (redo winners) oder vollstndiges Redo
(repeating history) mglich
temporre Log-Datei wird 3-mal gelesen
57
Sicherungspunkt
Log
Analyse
a) transaktionskonsistent
Undo
Redo
Analyse
b) aktionskonsistent
MinLSN
Undo
Redo
Analyse
c) unscharf (fuzzy)
MinLSN
MinDirtyPageLSN
Undo
Redo
58
bersicht
Einfhrung
Logging-Strategien
Einbringstrategie
Crash-Recovery

Fehlermodell
Recovery-Arten
59
Platten-Recovery
Spiegelplatten
schnellste und einfachste Lsung
hohe Speicherkosten
Doppelfehler nicht auszuschlieen
Alternative
Archivkopie + Archiv-Log
sind lngerfristig verfgbar zu halten (auf Band)
Problem von Alterungsfehlern
- Fhren von Generationen der Archivkopie
- Duplex-Logging fr Archiv-Log
Archivkopie
ArchivLog
Ableitung von Archivdaten
Temporrer
Log
DB
Sammlung sehr groer Datenvolumina als nachgelagerter Prozess

Archiv-Log kann offline aus temporrer Log-Datei abgeleitet werden
Erstellung von Archivkopien und Archiv-Log erfolgt segmentorientiert
60
Erstellung der Archivkopie
Anhalten des nderungsbetriebs zur

Erstellung einer DB-Kopie
i. A. nicht tolerierbar
Alternativen:
Inkrementelles Dumping (a)
- Ableiten neuer Generationen aus
Urkopie
- nur nderungen seit der letzten ArchivKopie protokollieren
- Offline-Erstellung einer aktuelleren
Kopie
Online-Erstellung einer Archivkopie (b)

- parallel zum nderungsbetrieb
Unterschiedliche Konsistenzgrade:
fuzzy dump (b1)
- Kopieren der DB im laufenden
Betrieb, kurze Lesesperren
- bei Plattenfehler Archiv-Log ab Beginn
der Dump-Erstellung anzuwenden
aktionskonsistente Archivkopie (b2)

- Voraussetzung bei logischem
Operations-Logging
transaktionskonsistente Archivkopie
(b3)
- Voraussetzung bei logischem
Transaktions-Logging
- Black-/White-Verfahren
- Copy-on-Update-Verfahren
61
Black-/White-Verfahren
Ziel
Erzeugung transaktionskonsistenter
Archiv-Kopien
Dumpprozess frbt alle weien Seiten

schwarz und schreibt genderte
Seiten in Archiv-Kopie:
spezieller Dumpprozess zur Erstellung

der Archiv-Kopie
Kennzeichnung der Seiten
WHILE there are white pages DO;

lock any white page;
IF page is modified THEN DO;
write page to archive copy;
clear modified bit;
END;
change page color;
release page lock;
END;
Paint-Bit (pro Seite)

- wei: Seite wurde noch nicht
berprft
- schwarz: Seite wurde bereits
verarbeitet
Modified-Bit (pro Seite)

- zeigt an, ob eine nderung seit
Erstellung der letzten Archiv-Kopie
erfolgte
Kennzeichnung der Seiten (Forts.)
Rcksetzregel
Transaktionen, die sowohl weie als
auch schwarze Objekte gendert
haben (graue Transaktionen),
werden zurckgesetzt
Farbtest am Transaktionsende
Quelle: [Pu86]
62
Beispiel
P1
P2
DumpProzess
P3 P4
P5 P6 P7
w rite
(in Archiv-Kopie)
P5
P7
weie Transaktion
T1
P2
P1
T2
P1
T3
schwarze
Transaktion
P5
graue
Transaktion
63
Erweiterungen zur Vermeidung von Rcksetzungen
Turn-White-Strategien (Turn gray transactions white)
- fr graue Transaktionen werden nderungen schwarzer Objekte nachtrglich in
Archiv-Kopie geschrieben
- Problem: transitive Abhngigkeiten
- Alternative: alle nderungen schwarzer Objekte seit Dump-Beginn werden noch
geschrieben (repaint all)
- Problem: Archiv-Kopie-Erstellung kommt u.U. nie zu Ende
Turn-Black-Strategien
- whrend der Erstellung einer Archiv-Kopie werden keine Zugriffe auf weie Objekte
vorgenommen
- ggf. warten, bis Objekt gefrbt wird
Alternative: Copy-on-Update ("save some")

- whrend der Erstellung einer Archiv-Kopie wird bei nderung eines weien
Objektes Kopie mit Before-Image der Seite angelegt
- Dump-Prozess greift auf Before-Images zu
- Archiv-Kopie entspricht DB-Schnappschuss bei Dump-Beginn
- wird in einigen DBS eingesetzt (DEC RDB)
64
Zusammenfassung
Fehlerarten: Transaktions-, System- und Gertefehler

breites Spektrum von Logging- und Recovery-Verfahren
Update-in-Place-Verfahren
Eintrags-Logging ist Seiten-Logging berlegen
sind ATOMIC-Strategien vorzuziehen

erfordern physisches Logging
geringerer Platzbedarf, weniger E/As, Gruppen-Commit
NOFORCE-Strategien
sind FORCE-Verfahren vorzuziehen
erfordern den Einsatz von Checkpoint-Manahmen zur Begrenzung des Redo-Aufwandes
Fuzzy Checkpoints erzeugen den geringsten Overhead im Normalbetrieb
STEAL-Methoden
verlangen die Einhaltung des WAL-Prinzips

erfordern Undo-Aktionen nach einem Rechnerausfall
Synchronisationsgranulat muss grer oder gleich dem Log-Granulat sein

Erstellung von Archiv-Kopien:
"Fuzzy Dump" oder "Copy on Update" am geeignetsten
65
Literatur zu diesem Kapitel

[Pu86]
C. Pu: On-the-Fly, Incremental, Consistent Reading

of Entire Databases, In: Algorithmica, 1986.
66

Chapter11 PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Chapter11 PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Anwendersoftware (AS)

Logging und Recovery

physisches/logisches und Zustands-/bergangs-Logging

Klassifikation von Recovery-Verfahren

Erstellung von Archivkopien

Logging und Recovery

Aufgabe des DBMS

Logging und Recovery

Verletzung von Systemrestriktionen

Hardware-Fehler, Software-Fehler, Umgebungsfehler

Zerstrung von Sekundrspeichern

Zerstrung des Rechenzentrums

Logging und Recovery

Voraussetzungen fr die Wiederherstellung der Daten

Logging und Recovery

Forward-Recovery vs. Backward Recovery

Wie soll Recovery durchgefhrt werden?

Logging und Recovery

Forward-Recovery vs. Backward Recovery

Logging und Recovery

Daten werden in die physische DB

Ausschreiben sptestens bei Commit

Einsatz der Log-Daten

Temporre Log-Datei zur Behandlung

Behandlung von Gertefehlern

Logging und Recovery

Zielzustand nach Recovery

Zustand der Systemumgebung?

Logging und Recovery

Zurcksetzen einzelner (noch nicht abgeschlossener) Transaktionen im laufenden

Partielles Zurcksetzen auf Rcksetzpunkt (Savepoint) innerhalb der TA

Logging und Recovery

Recovery nach einem Systemfehler

Logging und Recovery

Recovery nach Gertefehler

Logging und Recovery

Recovery nach Katastrophe

Logging und Recovery

physisches/logisches und Zustands-/bergangs-Logging

Klassifikation von Recovery-Verfahren

Erstellung von Archivkopien

Logging und Recovery

CLR: Compensation Log Record (fr Crash whrend Recovery)

Logging und Recovery

Logging kann auf jeder DBMS-Systemebene erfolgen

Klassifikation der Logging-Verfahren

Logging und Recovery

Protokollierung der ndernden DML-Befehle mit ihren Parametern

Logging und Recovery

Protokollierung der Objekte vor und nach einer nderung

Logging und Recovery

Aufwand bei physischem Zustandslogging

Operation: STORE X-RECORD (X1)

normaler Betrieb (DO)

Logging und Recovery

nderungen bezglich einer Seite A

Protokollierung der Operationen

Rekonstruktion von Seiten beim bergangs-Logging

Logging und Recovery

Logging und Recovery

Bewertung der Logging-Verfahren

Eintrags-Logging vs. Seiten-Logging

Nachteil von Eintrags-Logging