chapter11.pdf

Anwendersoftware (AS) 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

2

bersicht

Einfhrung 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

Gertefehler-Recovery Erstellung von Archivkopien


3

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


4

Fehlerarten

Auswirkung eines Fehlers auf

Fehlertyp Fehler-klassifikation

eine Transaktion Verletzung von Systemrestriktionen Versto gegen Sicherheitsbestimmungen bermige Betriebsmittelanforderungen Anwendungsbedingte Fehler z. B. falsche Operationen und Werte

Transaktions-fehler

mehrere Transaktionen Geplante Systemschlieung 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

Zerstrung von Sekundrspeichern Gertefehler

Zerstrung des Rechenzentrums Katastrophe

Recovery-Arten


5

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


6

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


7

Forward-Recovery vs. Backward Recovery

Normale Verarbeitung

Fehler entdeckt

Rcksetzen

Benutzer entscheidet, Was zu tun ist

Verarbeitung fortsetzen

Problemorientierte Fehlerbehandlung

Systemorientierte Fehlerbehandlung (Sicherungspunkt)

Backward Recovery

Ja

Ja

Nein

Forward Recovery

Forward Recovery manuell

Nein


8

Systemkomponenten

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

Pufferung von Log-Daten im Hauptspeicher (Log-Puffer) Ausschreiben sptestens bei Commit

Einsatz der Log-Daten Temporre Log-Datei zur Behandlung

von Transaktions- und Systemfehlern - DB + temp. Log DB

Behandlung von Gertefehlern - Archiv-Kopie + Archiv-Log DB

Archiv-Kopie der DB

temporre Log-Datei

Archiv-Log

permanente Datenbank

AP 1 AP 2 AP n

DBMS

DB-Puffer

Log-Puffer


9

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


10

Transaktions-Recovery (R1)

Zurcksetzen einzelner (noch nicht abgeschlossener) Transaktionen im laufenden Betrieb (Transaktionsfehler, Deadlock)

Arten Vollstndiges Zurcksetzen auf Transaktionsbeginn (TA-UNDO)

Partielles Zurcksetzen auf Rcksetzpunkt (Savepoint) innerhalb der TA

T1 Undo T1

Recovery

Undo T1 Recovery

T1

Savpoint

temporre Log-Datei

temporre Log-Datei


11

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

T2

T3

Systemfehler Recovery

Redo T1

Undo T2

RedoT3

temporre Log-Datei



12

Medien-Recovery (R3)

Recovery nach Gertefehler Spiegelplatten bzw. Vollstndiges Wiederholen (REDO) aller nderungen (erfolgreich

abgeschlossener Transaktionen) auf einer Archivkopie

T1

T3

Gertefehler Recovery

Redo T1

RedoT3

temporre Log-Datei


Archivkopie der DB


13

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)


14

bersicht







15

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 Log-Satz

DB-Zustandneu CLR

DB-Zustandalt Log-Satz DB-Zustandneu

DB-Zustandneu Log-Satz DB-Zustandalt

DO REDO UNDO

CLR: Compensation Log Record (fr Crash whrend Recovery)


16

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

bergangs- Logging

physisch (byte-orientiert)

kombiniert (physiological)

Zustands- Logging

bergangs- Logging

Seiten- Logging

Eintrags- Logging . . .


17

Logisches Logging

Protokollierung der ndernden DML-Befehle mit ihren Parametern Vorteil:

minimaler Log-Umfang Generelles UNDO-Problem:

mengenorientierte Aktualisierungsoperation, z. B. DELETE Voraussetzung

nach einem Systemausfall mssen auf der permanenten Datenbank DML-Operationen ausfhrbar sein, d.h., sie muss wenigstens operationskonsistent sein (Aktionskonsistenz)

verzgerte (indirekte) Einbringstrategie erforderlich, d.h. fr Update-in-Place nicht anwendbar


18

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

Seitenkopf

einfgen genderte Eintrge


19

Aufwand bei physischem Zustandslogging

einfachste Form der Implementierung: Seiten-Logging

Freispeicherverwaltung FPAZuordnungs-

1 2 3 i nfi

123

j

m

Adr(X1)

tabelle ZT

Datenseite Pi

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

Operation: STORE X-RECORD (X1)


20

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)

Rekonstruktion von Seiten beim bergangs-Logging A1 als Anfangs- oder A3 als Endzustand seien verfgbar REDO-Recovery UNDO-Recovery

A1 (A1 A2) = A2 A3 (A2 A3) = A2 A2 (A2 A3) = A3 A2 (A1 A2) = A1

logisches Logging physisches Logging

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

1. A1 und A2 2. A2 und A3

bergnge Protokollierung der Operationen mit Parameter

1. Insert (a) 2. Update (balt, bneu)

bergangs-Logging 1. A1 A2 2. A2 A3

Logging: Anwendungsbeispiel


21

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


22

Bewertung der Logging-Verfahren

Eintrags-Logging vs. Seiten-Logging Vorteile von Eintrags-Logging

geringerer Platzbedarf weniger Log-E/As erlaubt bessere Pufferung von Log-

Daten (Gruppen-Commit) untersttzt feine Synchronisations-

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

Logging-Aufwand im Normalbetrieb

Restart-Aufwand im Fehlerfall (Crash)

Seitenzustands-Logging

-- +

Seitenbergangs-Logging (Differenzen)

- +

Eintrags-Logging physiologisches Logging

+ +

Logisches Logging

++ --


23

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


24


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


25


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


26

Temporre Log-Datei

Beispiel


27

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!


28

Temporre Log-Datei

Ringpuffer-Organisation der Log-Datei

lteste Redo-Information lteste Redo-Information, die nicht im Archiv-Log vorliegt

aktuelles logisches

1 2 3 ... A E ... n

Log-Ende

logischerLog-Anfang

einer genderten Seiteim DB-Puffer

Beginn der ltesten TA(MinLSN)


29

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 Log-Puffers

logprimary DB Anzahl primrer Log-Dateien

logsecond DB maximale Anzahl sekundrer Log-Dateien

logfilsiz DB Gre der einzelnen Log-Dateien

logpath DB Pfad zu den Log-Dateien

mirrorlogpath DB Pfad fr gespiegelte Log-Dateien

logretain DB Legt fest, ob Log-Dateien archiviert werden oder nicht


30

bersicht







31

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)

Wahl des Sperrgranulats

Commit-Behandlung

Seitenzuordnungs- strukturen

Puffer- verwaltung

Synchronisation


32

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


33

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

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

Undo- Info

Redo- Info

DB-Puffer Log-Puffer

temp. Log-Datei

U(C) R A B C'

U(C) R(C') A B'

U(B) R(B')

C'

DB-Seiten

DB


34

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


35

Einbringstrategie

atomic / verzgert

Undo- Info

Redo- Info

DB-Puffer Log-Puffer

temp. Log-Datei

U R

A B C C'

U(C) R(C') A B'

U(B) R(B')

C'

DB-Seiten

DB

a b c'

a b c

laufende

alte 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


36

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


37

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


38

Ersetzungsstrategie/Ausschreibstrategie

steal nosteal

force Undo-Recovery keine Redo-Recovery

fr non-atomic nicht mglich non-atomic, nosteal force non-atomic, force steal

noforce Undo-Recovery Redo-Recovery

keine Undo-Recovery Redo-Recovery


39

Sperrverwaltung

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)

r1

r2

r1

r2

T1 T2

r1 -> r1 r2 -> r2

o

commit

T2

DB

r1

r2

Undo r1' und r2'!?


40

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)

w(x) T1

Unlock(x)

Beginn der Commit-Behandlung

r(x) T2

EOT


41

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

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

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

Sperr- freigabe


42

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 Log-

Puffer (1 oder mehrere Seiten) Voraussetzung: Eintrags-Logging Ausschreiben des Log-Puffers erfolgt,

wenn er voll ist bzw. Timer abluft nur geringe Commit-Verzgerung

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 Timer-Wertes durch DBMS wnschenswert

Gruppen-Commit ermglicht demnach Durchsatzverbesserung v.a. bei Log-Engpass oder hoher CPU-Auslastung

Log-Daten/ Commit-Satz in Log-Puffer

Gruppen-Commit

Sperr- freigabe



43

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

Pr-Commit

Sperr- freigabe



44

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 x x

x

x

x S1

S3

S2

Seiten, die beim Systemausfall im Puffer standen

x x

x

x x x x x x Sp

Systemausfall Start des

DBMS

t


45

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


46

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 Sicherungspunkt-Aufwand

Redo-Informationen vor letztem Sicherungspunkt sind i. A. noch zu bercksichtigen

Sonderbehandlung von Hot-Spot-Seiten


47

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 genderten Seiten der TA aus dem DB-Puffer

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

Systemfehler

T1

T2

T3

c (T1) c (T2) Sicherungspunkte

t


48

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 verzgern neue nderungs-TA mssen warten,

bis Sicherungspunkt erzeugt Crash-Recovery startet bei letztem

Sicherungspunkt

Systemfehler

T1

T2

T3

Sicherungspunkt anmelden

T4

Totzeit des DBS fr neue Transaktionen

ci

ci

ci-1

Sicherungspunkt erzeugen

t


49

Aktionskonsistente Sicherungspunkte

ACC = action-consistent checkpoint (speicherkonsistent)

Sicherungspunkt bezieht sich immer auf alle TA

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

T2

Systemfehler Totzeit des DBS fr Operationen

ci ci-1

Sicherungspunkt anmelden ci

Sicherungspunkt erzeugen

T4

T3

T1

t


50

Unscharfe Sicherungspunkte (Fuzzy Checkpoints)

Ziel: Synchrones Ausschreiben genderter

Seiten vermeiden

Problem Bestimmung der Log-Position, an der

Redo-Recovery beginnen muss

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

x x x

x

x

x

S 1

S 3

S 2

Log

10 20 30 40 50 60 70 (LSN)

write

write

Seiten, die beim Systemausfall im Puffer standen

Sicherungspunkt


51

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


52

Kombination von DB-Recovery-Verfahren non-atomic, nosteal noforce | force TOC | non-atomic,force steal | ACC steal | atomic FuzzyCP

DB-Recovery-Verfahren

non-atomic atomic

nosteal steal nosteal steal

force noforce noforce force noforce force noforce

TOC TCC ACC Fuzzy TCC Fuzzy TOC TCC ACC TOC TCC

IMS Adabas UDS

DB2 Tandem ARIES

TOSP TWIST AIM

System R SQL/DS ? ?

Einbring- Strategie

Seiten- ersetzung

EOT- Behandlung

Sicherungs- punkt

System- beispiele

DM

S 11

00

IMS

FP

DB

Cac

he


53

Beispiel DB2

Gruppen-Commit fasst mincommit TA zusammen maximale Verzgerung: 1 Sek.

Soft Checkpoints Unscharfe Sicherungspunkte Vorgabe hinsichtlich der Anzahl der

fr die Recovery relevanten Log-Dateien steuert die Hufigkeit

Overhead fr Logging reduzieren: Logging fr einzelne Tabellen unterbinden

Logging wird fr in einer Session deklarierte temporre Tabellen nicht durchgefhrt

Parameter Bereich Beschreibung

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

softmax DB Steuert die Hufigkeit der Checkpoints

CREATE TABLE NOT LOGGED INITIALLY

DECLARE GLOBAL TEMPORARY TABLE


54

bersicht







56

Crash-Recovery

Ziel Herstellung des jngsten

transaktionskonsistenten DB-Zustandes 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


57

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

gendert wurden 2. Undo-Phase

Rcksetzen der Verlierer-TA durch Rckwrtslesen des Logs bis zum BOT-Satz 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


58

Allgemeine Restart-Prozedur

Log Sicherungspunkt

a) transaktionskonsistent Analyse

Redo

Undo

b) aktionskonsistent

c) unscharf (fuzzy)

Analyse

Redo

Undo MinLSN

Analyse

Redo MinDirtyPageLSN

MinLSN Undo


59

bersicht







60

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

Ableitung von Archivdaten 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

Archiv-kopie

Archiv-Log

TemporrerLog

DB


61

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


62

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 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.) Dumpprozess frbt alle weien Seiten

schwarz und schreibt genderte 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;

Rcksetzregel Transaktionen, die sowohl weie als

auch schwarze Objekte gendert haben (graue Transaktionen), werden zurckgesetzt

Farbtest am Transaktionsende

Quelle: [Pu86]


63


Beispiel

Dump- Prozess

T1

T2

T3

P1

P5

P2

P1

w rite

weie Transaktion

schwarze

graue

Transaktion

Transaktion

(in Archiv-Kopie)

P2 P3 P4 P5 P6 P7

P7

P1

P5


64


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)


65

Zusammenfassung

Fehlerarten: Transaktions-, System- und Gertefehler 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 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


66

Literatur zu diesem Kapitel

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

Datenbanken und InformationssystemebersichtAnforderungenFehlerartenVoraussetzungenForward-Recovery vs. Backward RecoveryForward-Recovery vs. Backward RecoverySystemkomponentenZielzustand nach RecoveryTransaktions-Recovery (R1)Crash-Recovery (R2)Medien-Recovery (R3)Katastrophen-Recovery (R4)bersichtLoggingLogging-VerfahrenLogisches LoggingPhysisches LoggingAufwand bei physischem ZustandsloggingLogging: AnwendungsbeispielPhysiologisches LoggingBewertung der Logging-VerfahrenSatzarten der temporren Log-DateiSatzarten der temporren Log-DateiSatzarten der temporren Log-DateiTemporre Log-DateiTemporre Log-DateiTemporre Log-DateiBeispiel DB2bersichtWichtige AbhngigkeitenWAL-Prinzip und Commit-RegelEinbringstrategieEinbringstrategieEinbringstrategieErsetzungsstrategieAusschreibstrategieErsetzungsstrategie/AusschreibstrategieSperrverwaltungCommit-BehandlungCommit-BehandlungGruppen-CommitPr-CommitSicherungspunkte / CheckpointsSicherungspunkte / CheckpointsArten von SicherungspunktenTransaktionsorientierte SicherungspunkteTransaktionskonsistente SicherungspunkteAktionskonsistente SicherungspunkteUnscharfe Sicherungspunkte (Fuzzy Checkpoints)Unscharfe SicherungspunkteKombination von DB-Recovery-VerfahrenBeispiel DB2bersichtCrash-RecoveryAllgemeine Restart-ProzedurAllgemeine Restart-ProzedurbersichtPlatten-RecoveryErstellung der ArchivkopieBlack-/White-VerfahrenBlack-/White-VerfahrenBlack-/White-VerfahrenZusammenfassungLiteratur zu diesem Kapitel

chapter11.pdf

Documents

Transcript of chapter11.pdf