Sie sind auf Seite 1von 65
AnwendersoftwareAnwendersoftware (AS)(AS) Datenbanken und Informationssysteme Kapitel 11: Logging und Recovery Bernhard

AnwendersoftwareAnwendersoftware (AS)(AS)

AnwendersoftwareAnwendersoftware (AS)(AS) Datenbanken und Informationssysteme Kapitel 11: Logging und Recovery Bernhard

Datenbanken und Informationssysteme

Kapitel 11: Logging und Recovery

Bernhard Mitschang Universität Stuttgart

Wintersemester 2013/2014

Teile zu diesem Folienskript beruhen auf einer ähnlichen Vorlesung , gehalten von Prof. Dr. T. Härder am Fachbereich Informatik der Universität Kaiserslautern und Prof. Dr. N. Ritter am Fachbereich Informatik der Universität Hamburg. Für dieses Skriptum verbleiben alle Rechte (insbesondere für Nachdruck) bei den Autoren.

Logging und Recovery

Übersicht

Einführung

Fehlermodell

Recovery-Arten

Logging-Strategien

physisches/logisches und Zustands-/Übergangs-Logging

Eintrags- vs. Seiten-Logging

Aufbau der Log-Datei

Klassifikation von Recovery-Verfahren

Einbringstrategie

Zusammenspiel mit der DB-Pufferverwaltung (Seitenersetzung, Ausschreibstrategie)

Commit-Behandlung, Gruppen-Commit

Sicherungspunkte (Checkpoints)

Crash-Recovery

Allgemeine Restart-Prozedur

Crash-Recovery mit dem Schattenspeicherkonzept

Gerätefehler-Recovery

Erstellung von Archivkopien

Logging und Recovery

Anforderungen

Aufgabe des DBMS

Automatische Behandlung aller erwarteten Fehler

Begrenzung und Behebung der zur Laufzeit möglichen Fehler (wie auch bei anderen fehlertoleranten Systemen)

„Reparatur” der statischen Struktur der DB

Erwartete Fehler

DB-Operation wird zurückgewiesen

Commit wird nicht akzeptiert

Stromausfall

Geräte funktionieren nicht (Spur, Zylinder, Platte defekt)

Logging und Recovery

Fehlerarten

Auswirkung eines Fehlers auf …

 

Fehlertyp

Fehler-

 

klassifikation

… eine Transaktion

Verletzung von Systemrestriktionen

Transaktions-

Verstoß gegen Sicherheitsbestimmungen

fehler

übermäßige Betriebsmittelanforderungen Anwendungsbedingte Fehler

z. B. falsche Operationen und Werte

… mehrere Transaktionen

Geplante Systemschließung

Überlast des Systems

Schwierigkeiten bei der Betriebsmittelvergabe

Verklemmung mehrerer Transaktionen

alle Transaktionen, d.h. das gesamte Systemverhalten

Hardware-Fehler, Software-Fehler, Umgebungsfehler Systemzusammenbruch mit Verlust der Hauptspeicherinhalte

Systemfehler

Zerstörung von Sekundärspeichern

Gerätefehler

Zerstörung des Rechenzentrums

Katastrophe

Zerstörung von Sekundärspeichern Gerätefehler Zerstörung des Rechenzentrums Katastrophe Recovery-Arten 4

Recovery-Arten

Logging und Recovery

Voraussetzungen

Allgemeine Probleme

Fehlererkennung

Fehlereingrenzung

Abschätzung des Schadens

Durchführung der Recovery (Forward-Recovery vs. Backward-Recovery)

Voraussetzungen für die Wiederherstellung der Daten

Sammeln redundanter Informationen während des Normalbetriebs (Logging)

quasi-stabiler Speicher

fehlerfreier DBMS-Code

fehlerfreie Log-Daten

Unabhängigkeit der Fehler

Logging und Recovery

Forward-Recovery vs. Backward Recovery

Wie soll Recovery durchgeführt werden?

• Forward-Recovery

Non-Stop-Paradigma (Prozesspaare usw.)

i. A. nicht anwendbar

Fehlerursache häufig falsche Programme, Eingabefehler u. ä.

durch Fehler unterbrochene TA sind zurückzusetzen

• Backward-Recovery

setzt voraus, dass auf allen Abstraktionsebenen genau definiert ist, auf welchen Zustand die DB im Fehlerfall zurückzusetzen ist

Zurücksetzen auf konsistenten Zustand und Wiederholung

Logging und Recovery

Forward-Recovery vs. Backward Recovery

Normale Verarbeitung Fehler entdeckt Ja Problemorientierte Fehlerbehandlung Nein Backward Recovery Ja
Normale
Verarbeitung
Fehler
entdeckt
Ja
Problemorientierte
Fehlerbehandlung
Nein
Backward
Recovery
Ja
Systemorientierte
Rücksetzen
Fehlerbehandlung
(Sicherungspunkt)
Nein

Benutzer entscheidet, Was zu tun ist

Forward

Recovery

Verarbeitung

fortsetzen

Verarbeitung fortsetzen
Verarbeitung fortsetzen
Nein Benutzer entscheidet, Was zu tun ist Forward Recovery Verarbeitung fortsetzen Forward Recovery „manuell“ 7

Forward

Recovery

„manuell“

Logging und Recovery

Systemkomponenten

Daten werden in die physische DB geschrieben und in die materialisierte DB eingebracht

Pufferung von Log-Daten im Hauptspeicher (Log-Puffer)

Ausschreiben spätestens bei Commit

Einsatz der Log-Daten

Temporäre Log-Datei zur Behandlung von Transaktions- und Systemfehlern

- DB + temp. Log DB

Behandlung von Gerätefehlern

- Archiv-Kopie + Archiv-Log DB

temporäre Log-Datei AP 1 AP 2 • • • AP n Log-Puffer DBMS DB-Puffer permanente
temporäre
Log-Datei
AP 1
AP 2
AP n
Log-Puffer
DBMS
DB-Puffer
permanente
Datenbank
Archiv-Kopie der DB

Archiv-Log

Logging und Recovery

Zielzustand nach Recovery

Transaktionsparadigma verlangt

Alles-oder-Nichts-Eigenschaft von Transaktionen

Dauerhaftigkeit erfolgreicher Änderungen

Zielzustand nach erfolgreicher Recovery

jüngster transaktionskonsistenter DB-Zustand

Durch die Recovery-Aktionen ist der jüngste Zustand vor Erkennen des Fehlers wiederherzustellen, der allen semantischen Integritätsbedingungen entspricht, der also ein möglichst aktuelles, exaktes Bild der Miniwelt darstellt.

Zustand der Systemumgebung?

Betriebssystem, Anwendungssystem, andere Komponenten

Umgebung

AW

DB

darstellt. • Zustand der Systemumgebung?  Betriebssystem, Anwendungssystem, andere Komponenten Umgebung AW DB 9

Logging und Recovery

Transaktions-Recovery (R1)

Zurücksetzen einzelner (noch nicht abgeschlossener) Transaktionen im laufenden Betrieb (Transaktionsfehler, Deadlock)

Arten

Vollständiges Zurücksetzen auf Transaktionsbeginn (TA-UNDO)

T1

T1
Recovery
Recovery
Undo T1 temporäre Log-Datei

Undo T1

temporäre

Log-Datei

Undo T1 temporäre Log-Datei

Partielles Zurücksetzen auf Rücksetzpunkt (Savepoint) innerhalb der TA

T1

T1 Savpoint

Savpoint

Recovery
Recovery
Undo T1 temporäre Log-Datei

Undo T1

temporäre

Log-Datei

Undo T1 temporäre Log-Datei

Logging und Recovery

Crash-Recovery (R2)

Recovery nach einem Systemfehler

Wiederherstellen des jüngsten transaktionskonsistenten DB-Zustands

Notwendige Aktionen

(partielles) REDO für erfolgreiche Transaktionen, d.h. Wiederholung verloren gegangener Änderungen

UNDO aller durch Ausfall unterbrochenen Transaktionen d.h. Entfernen der Änderungen aus der permanenten DB

T1

T1 T3 T2 Systemfehler

T3

T2

T1 T3 T2 Systemfehler
T1 T3 T2 Systemfehler

Systemfehler

Recovery
Recovery

Redo T1

Redo T1 RedoT3 temporäre Log-Datei Undo T2 permanente Datenbank
Redo T1 RedoT3 temporäre Log-Datei Undo T2 permanente Datenbank

RedoT3

temporäre

Log-Datei

Undo T2 permanente Datenbank
Undo T2
permanente
Datenbank

Logging und Recovery

Medien-Recovery (R3)

Recovery nach Gerätefehler

Spiegelplatten bzw.

Vollständiges Wiederholen (REDO) aller Änderungen (erfolgreich abgeschlossener Transaktionen) auf einer Archivkopie

T1

T1 T3 Gerätefehler

T3

T1 T3 Gerätefehler

Gerätefehler

Recovery
Recovery

Redo T1

Redo T1 RedoT3 temporäre L o g - D a t e i Archivkopie der DB

RedoT3

Redo T1 RedoT3 temporäre L o g - D a t e i Archivkopie der DB
Redo T1 RedoT3 temporäre L o g - D a t e i Archivkopie der DB

temporäre

Log-Datei

Archivkopie

der DB

Redo T1 RedoT3 temporäre L o g - D a t e i Archivkopie der DB

permanente

Datenbank

Logging und Recovery

Katastrophen-Recovery (R4)

Recovery nach Katastrophe

Nutzung einer aktuellen DB-Kopie in einem ‚entfernten‘ System oder

stark verzögerte Fortsetzung der DB-Verarbeitung mit repariertem/neuem System auf der Basis gesicherter Archivkopien (Datenverlust)

Logging und Recovery

Einführung

Fehlermodell

Recovery-Arten

Übersicht

Logging-Strategien

physisches/logisches und Zustands-/Übergangs-Logging

Eintrags- vs. Seiten-Logging

Aufbau der Log-Datei

Klassifikation von Recovery-Verfahren

Einbringstrategie

Zusammenspiel mit der DB-Pufferverwaltung (Seitenersetzung, Ausschreibstrategie)

Commit-Behandlung, Gruppen-Commit

Sicherungspunkte (Checkpoints)

Crash-Recovery

Allgemeine Restart-Prozedur

Crash-Recovery mit dem Schattenspeicherkonzept

Gerätefehler-Recovery

Erstellung von Archivkopien

Logging und Recovery

Aufgaben

Logging

Sammlung redundanter Daten bei Änderungen im Normalbetrieb (DO) als Voraussetzung für Recovery

Einsatz im Fehlerfall (Undo-, Redo-Recovery)

Do-Redo-Undo-Prinzip

DB-Zustand alt

DO
DO

DB-Zustand neu

Log-Satz

DB-Zustand alt

Log-Satz

REDO DB-Zustand neu
REDO
DB-Zustand neu

DB-Zustand neu

Log-Satz

UNDO
UNDO

DB-Zustand alt

CLR

CLR: Compensation Log Record (für Crash während Recovery)

Logging und Recovery

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 erfüllt sind

Klassifikation der Logging-Verfahren

erfüllt sind • Klassifikation der Logging-Verfahren logisch Logging physisch kombiniert

logisch

Logging physisch kombiniert
Logging
physisch
kombiniert

(„byte-orientiert“)

Logging physisch kombiniert („byte-orientiert“) („physiological“) Übergangs- Logging Zustands- Logging
Logging physisch kombiniert („byte-orientiert“) („physiological“) Übergangs- Logging Zustands- Logging

(„physiological“)

Übergangs-

Logging

Zustands-

Logging

(„physiological“) Übergangs- Logging Zustands- Logging Seiten- Logging . . . Eintrags- Logging Übergangs- Logging

Seiten-

Logging

.

(„physiological“) Übergangs- Logging Zustands- Logging Seiten- Logging . . . Eintrags- Logging Übergangs- Logging 16

.

.

Eintrags-

Logging

Übergangs-

Logging

Logging und Recovery

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 müssen auf der permanenten Datenbank DML- Operationen ausführbar sein, d.h., sie muss wenigstens operationskonsistent sein (Aktionskonsistenz) verzögerte (indirekte) Einbringstrategie erforderlich, d.h. für Update-in-Place nicht anwendbar

Logging und Recovery

Physisches Logging

Protokollierung der Objekte vor und nach einer Änderung

• Zustands-Logging

alte Zustände (Before-Images) und neue Zustände (After-Images) geänderter 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 verzögerten Einbringstrategien anwendbar

aufwendig und unnötig starr v.a. bezüglich Lösch- und Einfügeoperationen

starr v.a. bezüglich Lösch- und Einfügeoperationen S e i t e n k o p f

Seitenkopf

einfügen
einfügen
starr v.a. bezüglich Lösch- und Einfügeoperationen S e i t e n k o p f

geänderte Einträge

Logging und Recovery

Aufwand bei physischem Zustandslogging

einfachste Form der Implementierung:

Seiten-Logging

Freispeicherverwaltung FPA

Zuordnungs- tabelle ZT f i 1 1 2 3 i n 2 Datenseite P i
Zuordnungs-
tabelle ZT
f i
1
1
2
3
i
n
2
Datenseite P i
3
X1
j
Adr(X1)
m

Operation: STORE X-RECORD (X1)

Aufwand

Datenseite

ZT

FPA

n Zugriffspfadseiten

normaler Betrieb (DO)

neues P i

Adr(X1)

f

i

n

DS neu

UNDO-Log

altes P i

alter Inhalt

alter Inhalt

n

DS salt

REDO-Log

neues P i

Adr(X1)

f

i

n

DS neu

Logging und Recovery

Logging: Anwendungsbeispiel

Änderungen bezüglich einer Seite A

1. ein Objekt a wird in Seite A eingefügt (A 1 A 2 )

2. in A wird ein bestehendes Objekt b alt nach b neu geändert (A 2 A 3 )

 

logisches Logging

physisches Logging

Zustände

 

Seiten-Logging: Protokollierung der Before- und After-Images

1. A 1 und A 2

2. A 2 und A 3

Übergänge

Protokollierung der Operationen mit Parameter

Übergangs-Logging

1. A 1 A 2

1. Insert (a)

2. A 2 A 3

2. Update (b alt , b neu )

Rekonstruktion von Seiten beim Übergangs-Logging

A 1 als Anfangs- oder A 3 als Endzustand seien verfügbar

REDO-Recovery

UNDO-Recovery

A 1 (A 1 A 2 ) = A 2 A 2 (A 2 A 3 ) = A 3

A 3 (A 2 A 3 ) = A 2 A 2 (A 1 A 2 ) = A 1

Logging und Recovery

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 verträglich

Logging und Recovery

Bewertung der Logging-Verfahren

 

Logging-

Restart-

Aufwand im Normalbetrieb

Aufwand im

Fehlerfall

 

(Crash)

Seitenzustands-

--

+

Logging

Seitenübergangs

-

+

-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 Log- Daten (Gruppen-Commit)

unterstützt feine Synchronisations- granulate (Seiten-Logging Synchronisation auf Seitenebene)

Nachteil von Eintrags-Logging

Recovery ist komplexer als mit Seiten-Logging

z.B. müssen Seiten vor der Anwendung der Log-Sätze wieder in den Speicher eingelesen werden

Logging und Recovery

Satzarten der temporären Log-Datei

Verschiedene Satzarten erforderlich

BOT-, Commit-, Abort-Satz

Änderungssatz

- UNDO-Informationen, z.B. ‚Before-Images‘

- REDO-Informationen, z.B. ‚After-Images‘

Sicherungspunkt-Sätze

Logging und Recovery

Satzarten der temporären Log-Datei

Struktur der Log-Einträge für Änderungsoperationen:

[LSN, TAID, PageID, Redo, Undo, PrevLSN]

• LSN: Log Sequence Number

eindeutige Kennung des Log-Eintrags

LSNs müssen monoton aufsteigend vergeben werden

chronologische Reihenfolge der Protokolleinträge kann dadurch ermittelt werden

Seitenkopf einer DB-Seite enthält LSN der zuletzt durchgeführten Änderung (Seiten-LSN)

• TAID: Transaktionskennung der TA, die die Änderung durchgeführt hat

Logging und Recovery

Satzarten der temporären Log-Datei

Struktur der Log-Einträge für Ä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, müssen entsprechend viele Log-Einträge 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 rückgängig 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 benötigt man aus Effizienzgründen

Logging und Recovery

Temporäre Log-Datei

Beispiel

Logging und Recovery Temporäre Log-Datei Beispiel 26

Logging und Recovery

Temporäre Log-Datei

Log ist eine sequentielle Datei

Schreiben neuer Protokolldaten an das aktuelle Dateiende

Log-Daten sind für Crash-Recovery nur begrenzte Zeit relevant

Undo-Sätze für erfolgreich beendete TA werden nicht mehr benötigt

nach Einbringen der Seite in die DB wird Redo-Information nicht mehr benötigt

Redo-Information für Medien-Recovery ist im Archiv-Log zu sammeln!

Logging und Recovery

Temporäre Log-Datei

Ringpuffer-Organisation der Log-Datei

älteste Redo-Information einer geänderten Seite im DB-Puffer älteste Redo-Information, die nicht im Archiv-Log
älteste Redo-Information
einer geänderten Seite
im DB-Puffer
älteste Redo-Information, die
nicht im Archiv-Log vorliegt
Beginn der ältesten TA
(MinLSN)
1 2
3
A
E
n
logischer
aktuelles
Log-Anfang
logisches
Log-Ende

Logging und Recovery

Beispiel DB2

Logging und Recovery Beispiel DB2 • primäre Log-Dateien werden beim Start der Datenbank allokiert • sekundäre

primäre Log-Dateien werden beim Start der Datenbank allokiert

sekundäre Log-Dateien werden bei Bedarf allokiert

Zwei Log-Modi:

Circular Logging: Log-Dateien sind als Ringpuffer organisiert. Es sind nur vollständige Backups möglich (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 möglich.

Gespiegelte Log-Dateien möglich

Parameter

Bereich

Beschreibung

logbufsz

DB

Größe des Log- Puffers

logprimary

DB

Anzahl primärer Log- Dateien

logsecond

DB

maximale Anzahl sekundärer Log- Dateien

logfilsiz

DB

Größe der einzelnen Log-Dateien

logpath

DB

Pfad zu den Log- Dateien

mirrorlogpath

DB

Pfad für gespiegelte Log-Dateien

logretain

DB

Legt fest, ob Log- Dateien archiviert werden oder nicht

Logging und Recovery

Einführung

Fehlermodell

Recovery-Arten

Logging-Strategien

Übersicht

physisches/logisches und Zustands-/Übergangs-Logging

Eintrags- vs. Seiten-Logging

Aufbau der Log-Datei

Klassifikation von Recovery-Verfahren

Einbringstrategie

Zusammenspiel mit der DB-Pufferverwaltung (Seitenersetzung, Ausschreibstrategie)

Commit-Behandlung, Gruppen-Commit

Sicherungspunkte (Checkpoints)

Crash-Recovery

Allgemeine Restart-Prozedur

Crash-Recovery mit dem Schattenspeicherkonzept

Gerätefehler-Recovery

Erstellung von Archivkopien

Logging und Recovery

Wichtige Abhängigkeiten

Einbringstrategie

direktes Einbringen von Änderungen (non-atomic)

verzögertes Einbringen von Änderungen (atomic)

Ersetzungsstrategie

Verdrängen ‘schmutziger’ Seiten (steal)

nur Verdrängung von Seiten abgeschlossener TAs (nosteal)

Ausschreibstrategie

Ausschreiben notwendigerweise bei Commit (force)

Ausschreiben möglicherweise nach Commit (noforce)

Wahl des Sperrgranulats

Commit-Behandlung

Seitenzuordnungs-

strukturen

Puffer-

verwaltung

Synchronisation

Logging und Recovery

WAL-Prinzip und Commit-Regel

• WAL-Prinzip (Write Ahead Log)

Vor dem Schreiben einer schmutigen Änderung in die materialisierte Datenbank muss die zugehörige Undo-Information (z.B. Before-Images) in die Log-Datei geschrieben werden.

• Commit-Regel (Force-Log-at-Commit)

Bevor das Commit einer TA ausgeführt werden kann, sind für ihre Änderungen ausreichende Redo-Informationen (z. B. After-Images) in der Log-Datei zu sichern.

Ausschreibezeitpunkte des Log-Puffers:

wenn er vollständig gefüllt ist

aufgrund des WAL-Prinzips

aufgrund der Commit-Regel

Logging und Recovery

Einbringstrategie

• non-atomic / direkt / update-in-place

geänderte Seite wird immer in denselben Block auf Platte zurückgeschrieben

Schreiben ist gleichzeitig Einbringen in die permanente DB

‚atomares‘ Einbringen mehrerer geänderter Seiten ist nicht möglich

Undo- Redo- Info Info DB-Seiten U(C) R(C') A B' Log-Puffer U(B) R(B') DB-Puffer C' U(C)
Undo-
Redo-
Info
Info
DB-Seiten
U(C)
R(C')
A
B'
Log-Puffer
U(B)
R(B')
DB-Puffer
C'
U(C)
R…
A
B
C'

temp. Log-Datei

DB

WAL-Prinzip:

Write Ahead Log für Undo-Info U(B) vor B’ und U(C) vor C'

Commit-Regel:

Ausschreiben der Redo-Info

spätestens bei Commit R(C’) + R(B’) vor Commit

Logging und Recovery

Einbringstrategie

• atomic / verzögert

z. B. in System R, SQL/DS

geänderte Seite wird in separaten Block auf Platte geschrieben, Einbringen in die DB erfolgt später

Seitentabelle gibt aktuelle Adresse einer Seite an

verzögertes, atomares Einbringen mehrerer Änderungen ist durch Umschalten von Seitentabellen möglich

aktions- oder transaktionskonsistente DB auf Platte

logisches Logging anwendbar

Logging und Recovery

Einbringstrategie

• atomic / verzögert

Undo- Redo- Info Info DB-Seiten U(C) R(C') A B' Log-Puffer U(B) R(B') DB-Puffer C' a
Undo-
Redo-
Info
Info
DB-Seiten
U(C)
R(C')
A
B'
Log-Puffer
U(B)
R(B')
DB-Puffer
C'
a
b
c'
laufende
Seitentabelle
alte
U…
R…
WAL-Prinzip:
a
b
c
Write Ahead Log für Undo-Info
temp. Log-Datei
A
B
C
C'
U(B) und U(C) vor Sicherungspunkt

DB

Commit-Regel:

Ausschreiben der Redo-Info spätestens bei Commit R(C’) + R(B’) vor Commit

Logging und Recovery

Ersetzungsstrategie

Problem: Ersetzung ‚schmutziger‘ Seiten

• steal

geänderte Seiten können jederzeit, insbesondere vor EOT der ändernden TA, ersetzt und in die permanente DB eingebracht werden

große Flexibilität zur Seitenersetzung

Undo-Recovery vorzusehen (TA-Abbruch, Systemfehler)

steal erfordert Einhaltung des WAL-Prinzips

• nosteal

Seiten mit schmutzigen Änderungen dürfen nicht ersetzt werden

Probleme bei langen Änderungs-TA

es ist keine Undo-Recovery auf der permanenten DB vorzusehen

Logging und Recovery

Ausschreibstrategie

Problem: Ersetzung ‚schmutziger‘ Seiten

• force

alle geänderten Seiten werden spätestens bei EOT (Commit) in die permanente DB eingebracht (Durchschreiben)

hoher Schreibaufwand

Antwortzeitverlängerung für Änderungs-TA

große 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

Logging und Recovery

Ersetzungsstrategie/Ausschreibstrategie

 

steal

nosteal

force

Undo-Recovery keine Redo-Recovery

für non-atomic nicht möglich

non-atomic, nosteal force non-atomic, force steal

noforce

Undo-Recovery

keine Undo-Recovery Redo-Recovery

Redo-Recovery

Logging und Recovery

Sperrverwaltung

Abhängigkeit: 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 durchgeführte Änderungen derselben Seite überschreiben (lost update)

r1 r2 r1 -> r1’
r1
r2
r1 -> r1’

o

T1

r1‘ r2‘ r2 -> r2’ ⇓
r1‘
r2‘
r2 -> r2’

DB

r2 r1 -> r1’ o T1 r1‘ r2‘ r2 -> r2’ ⇓ • DB commit •

commit

T2

T2

r1 r2
r1
r2

Undo r1' und r2'!?

Logging und Recovery

Commit-Behandlung

Forderungen:

Änderungen einer TA sind mit Commit zuzusichern

andere TA dürfen Änderungen erst sehen, wenn ‚Durchkommen‘ der ändernden TA gewährleistet ist (Problem des rekursiven Zurücksetzens)

Beginn der Commit-Behandlung w(x) Unlock(x) T1 r(x) EOT T2
Beginn der Commit-Behandlung
w(x)
Unlock(x)
T1
r(x)
EOT
T2

Logging und Recovery

Commit-Behandlung

zweiphasige Commit-Bearbeitung:

Phase 1: Wiederholbarkeit der TA sichern

ggf. noch Änderungen sichern

Commit-Satz auf Log schreiben

Phase 2: Änderungen sichtbar machen

Freigabe der Sperren

Sperr- Schreiben der Log-Daten (inkl. Commit-Satz) auf Platte freigabe
Sperr-
Schreiben der Log-Daten
(inkl. Commit-Satz) auf Platte
freigabe

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 geänderten DB-Seiten

3. After-Images (für Archiv-Log) und Commit-Satz schreiben

Commit Phase 1 bei noforce:

lediglich 3. notwendig

Logging und Recovery

Gruppen-Commit

Log-Datei ist pot. Leistungsengpass

pro Änderungstransaktion wenigstens 1 Log-E/A

max. ca. 250 sequentielle Schreibvorgänge pro Sekunde (1 Platte)

Gruppen-Commit bedeutet gemeinsames Schreiben der Log-Daten mehrerer TA

Pufferung der Log-Daten in Log- Puffer (1 oder mehrere Seiten)

Voraussetzung: Eintrags-Logging

Ausschreiben des Log-Puffers erfolgt, wenn er voll ist bzw. Timer abläuft

nur geringe Commit-Verzögerung

Gruppen-Commit erlaubt Reduktion auf 0.1 - 0.2 Log-E/As pro TA

Einsparung an CPU-Overhead für E/A reduziert CPU-Wartezeiten

dynamische Festsetzung des Timer- Wertes durch DBMS wünschenswert

Gruppen-Commit ermöglicht demnach Durchsatzverbesserung v.a. bei Log- Engpass oder hoher CPU-Auslastung

Log-Daten/ Commit-Satz Schreiben der Log-Daten (inkl. Commit-Satz) auf Platte Sperr- in Log-Puffer freigabe
Log-Daten/
Commit-Satz
Schreiben der Log-Daten
(inkl. Commit-Satz) auf Platte
Sperr-
in Log-Puffer
freigabe

Gruppen-Commit

Logging und Recovery

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 ‚abhängigen‘ 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

 

Schreiben der Log-Daten (inkl. Commit-Satz) auf Platte

in Log-Puffer

   

Sperr-

 
  Schreiben der Log-Daten (inkl. Commit-Satz) auf Platte in Log-Puffer     Sperr-   freigabe

freigabe

Prä-Commit

Logging und Recovery

Sicherungspunkte / Checkpoints

Motivation:

Maßnahme zur Begrenzung des Redo-Aufwands nach Systemfehlern (noforce)

ohne Sicherungspunkte müssten potentiell alle Änderungen seit Start des DBMS wiederholt werden

Besonders kritisch: Hot-Spot-Seiten

x x
x
x

x

S

S

1

2

x

x

x

x

x

x

x x

x

x

x

S

S

3

x

p

Start

des

DBMS

Systemausfall

t

x x x x x x x x x S • • • S 3 x

Seiten, die beim

Systemausfall im

Puffer standen

Logging und Recovery

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 Restart- Datei geführt

Sicherungspunkte und Einbringverfahren

atomic

- Zustand der permanenten DB beim Crash entspricht dem zum Zeitpunkt des letzten erfolgreichen Sicherungspunktes

non-atomic

- Zustand der permanenten DB enthält alle ausgeschriebenen (eingebrachten) Änderungen bis zum Crash

Logging und Recovery

Arten von Sicherungspunkten

• Direkte Sicherungspunkte

alle geänderten Seiten im DB-Puffer werden in die permanente DB eingebracht

Redo-Recovery beginnt bei letztem Sicherungspunkt

Nachteil: lange ‚Totzeit‘ des Systems, da während des Sicherungspunktes keine Änderungen durchgeführt werden können

Problem wird durch große Hauptspeicher verstärkt

Transaktionskonsistente oder aktionskonsistente Sicherungspunkte

Indirekte/Unscharfe Sicherungspunkte (Fuzzy Checkpoints)

kein Hinauszwingen geänderter Seiten

nur Statusinformationen (Pufferbelegung, Menge aktiver TA, offene Dateien etc.) werden in die Log-Datei geschrieben

sehr geringer Sicherungspunkt- Aufwand

Redo-Informationen vor letztem Sicherungspunkt sind i. A. noch zu berücksichtigen

Sonderbehandlung von Hot-Spot- Seiten

Logging und Recovery

Transaktionsorientierte Sicherungspunkte

• TOC = transaction-oriented checkpoint

Force kann als spezieller Sicherungspunkt-Typ aufgefasst werden: force toc

Seiten genau einer TA werden ausgeschrieben

Eigenschaften

EOT-Behandlung erzwingt das Ausschreiben aller geänderten Seiten der TA aus dem DB- Puffer

Übernahme aller Änderungen in DB

Vermerk in Log-Datei

nur atomic ermöglicht atomares Einbringen mehrerer Seiten

zumindest bei direktem Einbringen der Seiten ist demnach Undo-Recovery vorzusehen (steal)

Systemfehler

T1 T2 T3 • c (T1) c (T2) Sicherungspunkte
T1
T2
T3
c (T1)
c (T2)
Sicherungspunkte

Abhängigkeit:

non-atomic, force steal

t

Logging und Recovery

Transaktionskonsistente Sicherungspunkte

• TCC = transaction-consistent checkpoint (logisch konsistent)

Sicherungspunkt bezieht sich immer auf alle TA

Eigenschaften

Ausschreiben ist bis zum Ende aller aktiven Änderungs-TA zu verzögern

neue Änderungs-TA müssen warten, bis Sicherungspunkt erzeugt

Sicherungspunkt erzeugen  Crash-Recovery startet bei letztem Sicherungspunkt Sicherungspunkt c i anmelden T1 T2
Sicherungspunkt
erzeugen
 Crash-Recovery startet bei letztem
Sicherungspunkt
Sicherungspunkt
c i
anmelden
T1
T2
T3
T4
c i
Systemfehler
c i-1
Totzeit des DBS
für neue Transaktionen

t

Logging und Recovery

Aktionskonsistente Sicherungspunkte

• ACC = action-consistent checkpoint (speicherkonsistent)

Sicherungspunkt bezieht sich immer auf alle TA

Eigenschaften:

- keine Änderungsanweisungen während des Sicherungspunktes

- geringere Totzeiten als bei TCC

- Redo-Recovery wird durch Sicherungspunkt begrenzt

- Undo-Recovery wird nicht durch

Sicherungspunkt

erzeugen

Sicherungspunkt

anmelden

durch Sicherungspunkt erzeugen Sicherungspunkt anmelden c i letzten Sicherungspunkt begrenzt sondern durch MinLSN
durch Sicherungspunkt erzeugen Sicherungspunkt anmelden c i letzten Sicherungspunkt begrenzt sondern durch MinLSN

c i

durch Sicherungspunkt erzeugen Sicherungspunkt anmelden c i letzten Sicherungspunkt begrenzt sondern durch MinLSN (LSN
durch Sicherungspunkt erzeugen Sicherungspunkt anmelden c i letzten Sicherungspunkt begrenzt sondern durch MinLSN (LSN

letzten Sicherungspunkt begrenzt sondern durch MinLSN (LSN des ersten Log-Eintrags der zum Sicherungspunkt ältesten TA)

c i-1

T1

der zum Sicherungspunkt ältesten TA) c i-1 T1 T2  Abhängigkeit: ACC → steal T3 T4
der zum Sicherungspunkt ältesten TA) c i-1 T1 T2  Abhängigkeit: ACC → steal T3 T4
der zum Sicherungspunkt ältesten TA) c i-1 T1 T2  Abhängigkeit: ACC → steal T3 T4
der zum Sicherungspunkt ältesten TA) c i-1 T1 T2  Abhängigkeit: ACC → steal T3 T4

T2

Abhängigkeit: ACC steal

TA) c i-1 T1 T2  Abhängigkeit: ACC → steal T3 T4 c i Totzeit des
TA) c i-1 T1 T2  Abhängigkeit: ACC → steal T3 T4 c i Totzeit des
TA) c i-1 T1 T2  Abhängigkeit: ACC → steal T3 T4 c i Totzeit des
TA) c i-1 T1 T2  Abhängigkeit: ACC → steal T3 T4 c i Totzeit des
TA) c i-1 T1 T2  Abhängigkeit: ACC → steal T3 T4 c i Totzeit des
TA) c i-1 T1 T2  Abhängigkeit: ACC → steal T3 T4 c i Totzeit des
TA) c i-1 T1 T2  Abhängigkeit: ACC → steal T3 T4 c i Totzeit des

T3

T4

TA) c i-1 T1 T2  Abhängigkeit: ACC → steal T3 T4 c i Totzeit des

c

i

Totzeit des DBS für Operationen der zum Sicherungspunkt ältesten TA) c i-1 T1 T2  Abhängigkeit: ACC → steal T3 T4

Systemfehler

t

Logging und Recovery

Unscharfe Sicherungspunkte (Fuzzy Checkpoints)

Ziel:

Synchrones Ausschreiben geänderter Seiten vermeiden

Problem

Bestimmung der Log-Position, an der Redo-Recovery beginnen muss

• StartLSN und MinDirtyPageLSN

Pufferverwalter merkt sich zu jeder geänderten 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

Sicherungspunkt Seiten, die beim Systemausfall im Puffer standen write x x x S 1 write
Sicherungspunkt
Seiten, die beim
Systemausfall im
Puffer standen
write
x
x
x
S
1
write
x
x
S
2
x
S
3
im Puffer standen write x x x S 1 write x x S 2 x S
im Puffer standen write x x x S 1 write x x S 2 x S
im Puffer standen write x x x S 1 write x x S 2 x S
im Puffer standen write x x x S 1 write x x S 2 x S
im Puffer standen write x x x S 1 write x x S 2 x S
im Puffer standen write x x x S 1 write x x S 2 x S
im Puffer standen write x x x S 1 write x x S 2 x S
im Puffer standen write x x x S 1 write x x S 2 x S

10

20

30

40

50

60

70

Log

(LSN)

Logging und Recovery

Unscharfe Sicherungspunkte

Sicherungspunkt-Information

MinDirtyPageLSN, Liste der aktiven TA, LSN ihres ersten Eintrags (MinLSN),

geänderte Seiten werden asynchron ausgeschrieben

ggf. Kopie der Seite anlegen (für Hot-Spot-Seiten)

Seite ausschreiben

StartLSN anpassen / zurücksetzen

Eigenschaften:

DB auf Platte bleibt ‚fuzzy‘, d.h. nicht aktionskonsistent

nur bei Update-in-Place (non-atomic) relevant

Aufwand für Sicherungspunkt reduziert

Abhängigkeit: atomic ¬FuzzyCP

DMS 1100

Logging und Recovery

Kombination von DB-Recovery-Verfahren

non-atomic, nosteal noforce | force TOC | non-atomic,force steal | ACC steal | atomic ¬FuzzyCP

Einbring-

Strategie

Seiten-

ersetzung

EOT-

Behandlung

Sicherungs-

punkt

System-

beispiele

DB-Recovery-Verfahren

Sicherungs- punkt System- beispiele DB-Recovery-Verfahren non-atomic atomic noforce steal TCC ACC Fuzzy nosteal

non-atomic

atomic

noforce
noforce

steal

TCC ACC Fuzzy

non-atomic atomic noforce steal TCC ACC Fuzzy nosteal steal nosteal   noforce force

nosteal

steal

nosteal

 
 
 
 
 

noforce

force

noforce

force

noforce

TCC Fuzzy IMS FP DB Cache
TCC
Fuzzy
IMS FP
DB Cache

TOC

TOSP

TWIST

TCC ACC System R AIM SQL/DS
TCC
ACC
System R
AIM
SQL/DS

TOC

?

TCC

?

IMS FP DB Cache TOC TOSP TWIST TCC ACC System R AIM SQL/DS TOC ? TCC

force

TOC

DB2

Tandem

ARIES

Adabas

UDS

IMS

Logging und Recovery

Beispiel DB2

Logging und Recovery Beispiel DB2 • Gruppen-Commit  fasst mincommit TA zusammen  maximale Verzögerung: 1

Gruppen-Commit

fasst mincommit TA zusammen

maximale Verzögerung: 1 Sek.

Soft Checkpoints Unscharfe Sicherungspunkte

Vorgabe hinsichtlich der Anzahl der für die Recovery relevanten Log-Dateien steuert die Häufigkeit

Parameter

Bereich

Beschreibung

mincommit

DB

Anzahl der TA, die in einem Gruppen- Commit zusammen- gefasst werden

softmax

DB

Steuert die Häufigkeit der Checkpoints

Overhead für Logging reduzieren:

Logging für einzelne Tabellen unterbinden

CREATE TABLE NOT LOGGED INITIALLY

Logging wird für in einer Session deklarierte temporäre Tabellen nicht durchgeführt

DECLARE GLOBAL TEMPORARY TABLE …

Logging und Recovery

Einführung

Fehlermodell

Recovery-Arten

Logging-Strategien

Übersicht

physisches/logisches und Zustands-/Übergangs-Logging

Eintrags- vs. Seiten-Logging

Aufbau der Log-Datei

Klassifikation von Recovery-Verfahren

Einbringstrategie

Zusammenspiel mit der DB-Pufferverwaltung (Seitenersetzung, Ausschreibstrategie)

Commit-Behandlung, Gruppen-Commit

Sicherungspunkte (Checkpoints)

Crash-Recovery

Allgemeine Restart-Prozedur

Crash-Recovery mit dem Schattenspeicherkonzept

Gerätefehler-Recovery

Erstellung von Archivkopien

Logging und Recovery

Crash-Recovery

Ziel

Herstellung des jüngsten transaktionskonsistenten DB- Zustandes aus permanenter DB und temporärer 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 ausführbar

logisches Logging möglich

force:

- kein Redo

noforce:

- transaktionskonsistentes Einbringen Redo, jedoch kein Undo

- aktionskonsistentes Einbringen Undo + Redo

Logging und Recovery

Allgemeine Restart-Prozedur

1. Analyse-Phase

vom letzten Sicherungspunkt bis zum Log-Ende

Bestimmung von Gewinner- und Verlierer-TA sowie der Seiten, die von ihnen geändert wurden

2. Undo-Phase

Rücksetzen der Verlierer-TA durch Rückwärtslesen des Logs bis zum BOT- Satz der ältesten Verlierer-TA

UNDO nur, wenn Seiten-LSN Log-Satz-LSN

3. Redo-Phase

Vorwärtslesen des Log: Startpunkt abhängig vom Sicherungspunkt-Typ

REDO nur, wenn Seiten-LSN < Log-Satz-LSN

selektives Redo bei Seitensperren (redo winners) oder vollständiges Redo (repeating history) möglich

temporäre Log-Datei wird 3-mal gelesen

Logging und Recovery

Allgemeine Restart-Prozedur

Log

a) transaktionskonsistent

b) aktionskonsistent

c) unscharf (fuzzy)

Sicherungspunkt

Sicherungspunkt

Sicherungspunkt
Sicherungspunkt
b) aktionskonsistent c) unscharf (fuzzy) Sicherungspunkt A n a l y s e   Undo Redo

Analyse

 

Undo

  Undo
Redo

Redo

 

Analyse

  Analyse
 

Undo

  Undo
 

Redo

 

Analyse

  Analyse
 

Undo

  U n d o
 

Redo

  Redo

MinLSN

  Undo   Redo   Analyse   U n d o   Redo MinLSN MinLSN MinDirtyPageLSN

MinLSN

  Undo   Redo   Analyse   U n d o   Redo MinLSN MinLSN MinDirtyPageLSN

MinDirtyPageLSN

  Undo   Redo   Analyse   U n d o   Redo MinLSN MinLSN MinDirtyPageLSN

Logging und Recovery

Einführung

Fehlermodell

Recovery-Arten

Logging-Strategien

Übersicht

physisches/logisches und Zustands-/Übergangs-Logging

Eintrags- vs. Seiten-Logging

Aufbau der Log-Datei

Klassifikation von Recovery-Verfahren

Einbringstrategie

Zusammenspiel mit der DB-Pufferverwaltung (Seitenersetzung, Ausschreibstrategie)

Commit-Behandlung, Gruppen-Commit

Sicherungspunkte (Checkpoints)

Crash-Recovery

Allgemeine Restart-Prozedur

Crash-Recovery mit dem Schattenspeicherkonzept

Gerätefehler-Recovery

Erstellung von Archivkopien

Logging und Recovery

Platten-Recovery

Spiegelplatten

schnellste und einfachste Lösung

hohe Speicherkosten

Doppelfehler nicht auszuschließen

Alternative

Archivkopie + Archiv-Log

sind längerfristig verfügbar zu halten (auf Band)

Problem von Alterungsfehlern

- Führen von Generationen der Archivkopie

- Duplex-Logging für Archiv-Log

Archiv-

kopie

- Duplex-Logging für Archiv-Log Archiv- kopie Archiv- Log Temporärer Log • Ableitung von

Archiv-

Log

Duplex-Logging für Archiv-Log Archiv- kopie Archiv- Log Temporärer Log • Ableitung von Archivdaten DB 

Temporärer

Log

Archiv-Log Archiv- kopie Archiv- Log Temporärer Log • Ableitung von Archivdaten DB  Sammlung sehr großer

Ableitung von Archivdaten

Log Temporärer Log • Ableitung von Archivdaten DB  Sammlung sehr großer Datenvolumina als

DB

Sammlung sehr großer Datenvolumina als nachgelagerter Prozess

Archiv-Log kann offline aus temporärer Log-Datei abgeleitet werden

Erstellung von Archivkopien und Archiv-Log erfolgt segmentorientiert

Logging und Recovery

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 Archiv- Kopie 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

Logging und Recovery

Black-/White-Verfahren

Ziel

Erzeugung transaktionskonsistenter Archiv-Kopien

spezieller Dumpprozess zur Erstellung der Archiv-Kopie

Kennzeichnung der Seiten

Paint-Bit (pro Seite)

- weiß: Seite wurde noch nicht überprüft

- 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.)

Dumpprozess färbt alle weißen Seiten schwarz und schreibt geänderte Seiten in Archiv-Kopie:

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;

Rücksetzregel

Transaktionen, die sowohl weiße als auch schwarze Objekte geändert haben (’graue Transaktionen’), werden zurückgesetzt

’Farbtest’ am Transaktionsende

Quelle: [Pu86]

62

Logging und Recovery

Black-/White-Verfahren

Beispiel

Dump-

Prozess

P1 P2 P3 P4 P5 P6 P7 write (in Archiv-Kopie) P5 P7
P1
P2
P3
P4
P5
P6
P7
write
(in Archiv-Kopie)
P5
P7

T1

P2 P3 P4 P5 P6 P7 write (in Archiv-Kopie) P5 P7 T1 weiße Transaktion T2 P2
P2 P3 P4 P5 P6 P7 write (in Archiv-Kopie) P5 P7 T1 weiße Transaktion T2 P2
P2 P3 P4 P5 P6 P7 write (in Archiv-Kopie) P5 P7 T1 weiße Transaktion T2 P2
P2 P3 P4 P5 P6 P7 write (in Archiv-Kopie) P5 P7 T1 weiße Transaktion T2 P2
P2 P3 P4 P5 P6 P7 write (in Archiv-Kopie) P5 P7 T1 weiße Transaktion T2 P2
P2 P3 P4 P5 P6 P7 write (in Archiv-Kopie) P5 P7 T1 weiße Transaktion T2 P2

weiße Transaktion

T2

P2

P1

P6 P7 write (in Archiv-Kopie) P5 P7 T1 weiße Transaktion T2 P2 P1 schwarze Transaktion T3
P6 P7 write (in Archiv-Kopie) P5 P7 T1 weiße Transaktion T2 P2 P1 schwarze Transaktion T3
P6 P7 write (in Archiv-Kopie) P5 P7 T1 weiße Transaktion T2 P2 P1 schwarze Transaktion T3
P6 P7 write (in Archiv-Kopie) P5 P7 T1 weiße Transaktion T2 P2 P1 schwarze Transaktion T3
P6 P7 write (in Archiv-Kopie) P5 P7 T1 weiße Transaktion T2 P2 P1 schwarze Transaktion T3
P6 P7 write (in Archiv-Kopie) P5 P7 T1 weiße Transaktion T2 P2 P1 schwarze Transaktion T3

schwarze

Transaktion

T3

P1

P5

P6 P7 write (in Archiv-Kopie) P5 P7 T1 weiße Transaktion T2 P2 P1 schwarze Transaktion T3
P6 P7 write (in Archiv-Kopie) P5 P7 T1 weiße Transaktion T2 P2 P1 schwarze Transaktion T3
P6 P7 write (in Archiv-Kopie) P5 P7 T1 weiße Transaktion T2 P2 P1 schwarze Transaktion T3

graue

Transaktion

Logging und Recovery

Black-/White-Verfahren

Erweiterungen zur Vermeidung von Rücksetzungen

Turn-White-Strategien (Turn gray transactions white)

- für graue Transaktionen werden Änderungen ’schwarzer’ Objekte nachträglich in Archiv-Kopie geschrieben

- Problem: transitive Abhängigkeiten

- 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

- während der Erstellung einer Archiv-Kopie werden keine Zugriffe auf weiße Objekte vorgenommen

- ggf. warten, bis Objekt gefärbt wird

Alternative: Copy-on-Update

("save some")

- während der Erstellung einer Archiv-Kopie wird bei Änderung eines weißen 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)

Logging und Recovery

Zusammenfassung

Fehlerarten: Transaktions-, System- und Gerätefehler

breites Spektrum von Logging- und Recovery-Verfahren

Update-in-Place-Verfahren

sind ATOMIC-Strategien vorzuziehen

erfordern physisches Logging

Eintrags-Logging ist Seiten-Logging überlegen

geringerer Platzbedarf, weniger E/As, Gruppen-Commit

NOFORCE-Strategien

weniger E/As, Gruppen-Commit • NOFORCE-Strategien  sind FORCE-Verfahren vorzuziehen  erfordern den

sind FORCE-Verfahren vorzuziehen

erfordern den Einsatz von Checkpoint-Maßnahmen 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 größer oder gleich dem Log-Granulat sein

Erstellung von Archiv-Kopien:

"Fuzzy Dump" oder "Copy on Update" am geeignetsten

Logging und Recovery

Literatur zu diesem Kapitel

[Pu86]

C. Pu: On-the-Fly, Incremental, Consistent Reading of Entire Databases, In: Algorithmica, 1986.

66