Universität Karlsruhe (TH) © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Kapitel 4...

UniversitätKarlsruhe (TH)

© 2009 Univ,Karlsruhe, IPD, Prof. Lockemann DBI 4

Kapitel 4

Zuverlässigkeit und Recovery in der Segmentschicht

2


Transaktionen in der Architektur

Mengenorientiertes Datenmodell

Anfragebearbeitung

Satzorientiertes Datenmodell

Satz- u. Satzmengenverwaltung

Satzzugriffsstrukturen

Zugriffsschicht

Hauptspeicherseiten u. Segmente

Dateien

Dateiverwaltung

Geräteschnittstelle

Scheduler

Recovery-Verwalter

Segment- u. Pufferverwaltung

Transaktion:Eine vom Benutzer als abgeschlossene Arbeitseinheit definierte Folge von Anfragen (Operatoren auf Mengen)

3


Architektur im Detail – 2. Schritt

Protokoll-datei

Transaktion 1 Transaktion 2 ... Transaktion n

Scheduler

Segment-Verwalter

Schedule 1 Schedule n

Sperren-Verwalter

Puffer- Verwalter

Daten-basis

p3 p2 p17 p24 p18 p57

p42 p8 p67 p19 p33 p81

p46 p25 p54 p66 p9 p91

p14 p68 p31 p29 p48 p47

p1 p5 p99 p23 p24 p56

p62 p15 p49 p36 p93 p7

Protokoll-seiten

d4 d43 d17 d15 d2 d58

d5 d9 d26 d69 d6 d16

d46 d68 d55 d32 d97 d49

d25 d20 d67 d30 d49 d37

d19 d34 d10 d24 d25 d94

d63 d82 d49 d92 d57 d8

Daten-seiten

Transaktionsverwaltung

Recovery

Konflikt-resistenter Gesamt-Schedule

PersistenzFehler-Resistenz

Performanz

eigene Vorlesung

letztes Kapitel

dieses Kapitel

4


Kapitel 4.1Kapitel 4.1

FehlermodellFehlermodell

5


1-konsistenter Zustand

Normalbetrieb

Eine Operation auf Schicht i löst i.A. eine Folge von Operationen auf Schicht i-1 aus.

Aus der letzten dieser (i-1)-Operationen wird der Endzustand der i-Operation über konstruiert.

1(0)

2(2)

1(2)

j(1)

i(1)

2(1)

1(1)

p(0)

n+1(0)

n(0)

m(0)

k(0)

2(0)

op1(0) op

k-1(0)

op1(1) op

i-1(1)

op1(2)

01

12

01

01

01

12

1-Operation

0-OperationenKonstruktion

0-konsistente Zustände

6


Letzter 1-konsistenter

Zustand

Gestörter Betrieb

Eine Operation auf Schicht i löst i.A. eine Folge von Operationen auf Schicht i-1 aus.

Aus der letzten dieser (i-1)-Operationen wird der Endzustand der i-Operation über konstruiert.

1(0)

2(2)

1(2)

j(1)

i(1)

2(1)

1(1)

p(0)

n+1(0)

n(0)

m(0)

k(0)

2(0)

op1(0) op

k-1(0)

op1(1) op

i-1(1)

op1(2)

01

12

01

01

01

12

0-Operationen

1-Operation


Zustand

Kommt nicht zum erfolgreichen Ende

Gilt also nicht mehr

7


Recovery (1)

Folge: Letzter konsistenter Zustand n wird aus einem (i-1) -konsistenten Zustand q durch Recoveryfunktionen i und i-1,i konstruiert:

(i)

(i-1)

Kompensation

Rekonstruktion

1


Zustand

1(0)

2(2)

1(2)

j(1)

i(1)

2(1)

1(1)

p(0)

n+1(0)

n(0)

m(0)

k(0)

2(0)

op1(0) op

k-1(0)

op1(1) op

i-1(1)

op1(2)

01

12

01

01

01

12

0-Operationen

1-Operation


Zustand Letzter 1-konsistenter 0-Zustand

Kompensation

8


Kompensation i

Inverse Funktionen (Kompensationsfunktionen):Kompensationen von Operationen der Ebene i, die vor dem Abbruch abgeschlossen waren, sind zulässig, falls1. Operationen der Ebene i sind atomar, d.h. sie bewirken stets i-konsistente Zustände.2. Die Kompensationsfunktion zu jeder Operation der Ebene i ist idempotent, d.h. sie stellt den Ausgangszustand her, auch wenn sie unterbrochen wurde.

Rekonstruktion i-1,i

Aus gespeicherten Werten der Ebene i-1 wird der Originalzustand von i-Objekten ermittelt.Rekonstruktion von Zuständen der Ebene i ist zulässig, falls der zugrundegelegte Zustand der Ebene i-1 (i-1)-konsistent ist.Rekonstruktion meist identisch mit Konstruktion.

Recovery (2)

9


Recovery in Schichten

Beginne auf Ebene 0 und bestimme dort 0-konsistenten Zustand. Bestimme auf Ebene 1 den zuletzt erreichten 1-konsistenten Zustand. Bestimme den hierzu gehörigen 0-konsistenten Zustand. Stelle ihn wieder her über Kompensation der Ebene 0. Rekonstruiere über den angestrebten 1-konsistenten Zustand. Setze diesen Prozess nach oben fort.

1(0)

2(2)

1(2)

j(1)

i(1)

2(1)

1(1)

p(0)

n+1(0)

n(0)

m(0)

k(0)

2(0)

op1(0) op

k-1(0)

op1(1) op

i-1(1)

op1(2)

1

2

01

12

01

01

01

12

10


Recovery in der Segmentschicht

1

1(0)

j(1)

i(1)

2(1)

1(1)

p(0)

n+1(0)

n(0)

m(0)

k(0)

2(0)

op1(0) op

k-1(0)

op1(1) op

i-1(1)

01

01

01

01

Kompensation

Rekonstruktion

0-Konsistenz durch RAID usw. gesichert.

Seiten

?

Entwurfsentscheidung: Wahl von j(1)

11



Transaktionale ZuverlässigkeitTransaktionale Zuverlässigkeit

12


Transaktionale Zuverlässigkeit

Entwurfsentscheidung: Alle Zuverlässigkeitsmaßnahmen orientieren sich an den Transaktionsgrenzen.

Transaktionen sind atomar („alles-oder-nichts“). Der alte Zustand jeder involvierten Seite bleibt mindestens bis

zum Transaktionsende erhalten. Zum Transaktionsende muss der neue Zustand gesichert

sein. Pufferverwaltung kennt vom Grundsatz her keine

Transaktionen. Erfordert Systemkomponenten außerhalb der

Pufferverwaltung.

13


Transaktionale Architektur d. Segmentschicht

Log-datei


Scheduler

Recovery- Backup-Verwalter

Historie 1 Historie n

Globale Historie aus read, write, allocate, unfix, commit, abort

Sperren-Verwalter

Puffer- Verwalter

Daten-basis

p3 p2 p17 p24 p18 p57

p42 p8 p67 p19 p33 p81

p46 p25 p54 p66 p9 p91

p14 p68 p31 p29 p48 p47

p1 p5 p99 p23 p24 p56

p62 p15 p49 p36 p93 p7

Log-seiten

d4 d43 d17 d15 d2 d58

d5 d9 d26 d69 d6 d16

d46 d68 d55 d32 d97 d49

d25 d20 d67 d30 d49 d37

d19 d34 d10 d24 d25 d94

d63 d82 d49 d92 d57 d8

Daten-seiten

restart

fetch, flush

read, write, allocate, unfix

Segment-Verwalter

Isolation

Atomizität

Einbring-Strategien


14


Kapitel 4.2.1Kapitel 4.2.1

Segment-VerwalterSegment-Verwalter

15


Einbringstrategien

Die Zuverlässigkeitsmaßnahmen richten sich nach der Einbringstrategie, und umgekehrt.

Einbringstrategie: Grundsätze, nach denen Änderungen in die Datei eingebracht werden.

Statischer Aspekt (Speicherstrategie): Ortswahl = Wahl eines Blocks, auf dem eine Änderung gespeichert werden soll. Sache der Segmentverwaltung.

Dynamischer Aspekt (Verdrängen/Auslagern): Wahl des Zeitpunkts, zu dem eine Änderung gespeichert werden soll. Die Pufferverwaltung agiert autonom und entscheidet daher

nach eigenen Optimierungskriterien über den Zeitpunkt. Die Segmentverwaltung muss also gezielt von außen Einfluss

nehmen, wenn sie dies für notwendig erachtet.

16


Speicherstrategien

Direkte Strategie (update-in-place)

Eine Seite wird nach jeder Änderung in ihren einmal zugeordneten Block zurückgeschrieben.

Die Direkte Einbringstrategie ist mit der direkten und der indirekten Seitenabbildung verträglich.

Indirekte Einbringstrategie (shadowing):

Änderungen der Seite werden auf einem zweiten Block gespeichert; geänderten Seiten sind somit zwei Blöcke zugeordnet.

Die natürliche Seitenabbildung ist die indirekte.

17


Verdrängungs- und Auslagerungsstrategie (1)

Verdrängungsstrategie bestimmt, wann Puffer-Verwalter geänderte Datenelemente frühestens auf den Hintergrundspeicher schreiben darf: Steal: Segment-Verwalter veranlasst sofortiges unpin(x) auf

write(x)/unfix(x) hin.

Nosteal: Segment-Verwalter kann bis zum commit der Transaktion für kein geändertes x ein unpin(x) geben.

Transaktions-verhalten

write(a)

unfix(a)

write(b)

unfix(b)

write(c)

unfix(c)

unpin(a) unpin(b) unpin(c)

unpin(a,b,c)

commit

Verwalter mit Steal-Strategie

Verwaltermit Nosteal-Strategie

read(a,b,c)

18



Auslagerungsstrategie bestimmt, wann Puffer-Verwalter geänderte Datenelemente spätestens auf den Hintergrundspeicher schreiben muss: Force: Beim commit der Transaktion zwingt Segment-

Verwalter den Puffer-Verwalter zum flush(x) für alle geänderten x.

Noforce: Puffer-Verwalter entscheidet eigenständig über flush(x) irgendwann nach dem commit der Transaktion (falls nicht Schreiben durch Verdrängen bereits erfolgt).


write(a)unfix(a))

write(b)unfix(b)

write(c)unfix(c)

flush(a) flush(b) flush(c)

flush(a,b,c)

commit

Verwalter mit Noforce-Strategie

Verwalter mit Force-Strategie

read(a,b,c)

19



Verdrängungs- und Auslagerungsstrategie lassen sich beliebig kombinieren.

unpin(a,b,c)flush(a,b,c)

Verwalter mit Nosteal/Force-Strategie


write(a)unfix(a)

write(b)unfix(b)

write(c)unfix(c)

commitread(a,b,c)


Verwalter mit Steal/Noforce-Strategie

unpin(a) unpin(b) unpin(c)


Verwalter mit Nosteal/Noforce-Strategie

unpin(a,b,c)

Verwalter mit Steal/Force-Strategie

unpin(a) unpin(b) unpin(c)flush(a,b,c)

natürliche Autonomie der Pufferverwaltung

20


crash recovery algorithms

steal update-in-place nosteal or shadowing

noforce force

with-undo no-undo

noforce force

with-undo/with-redo with-undo/no-redo no-undo/with-redo no-undo/no-redo

Konsequenzen für Crash-Recovery

undo: Beseitige Wirkung der Transaktionredo: Stelle Wirkung der Transaktion wieder her

21



Vorgehen bei Update-in-placeVorgehen bei Update-in-place

22


Grundlage der Recovery

Basis-Fehler-Resistenz:

undo: Um im Fehlerfall die Transaktion zurücksetzen zu können, muss der alte Zustand jeder betroffenen Seite (before image) auf einem anderen Block gesichert werden. Dies geschieht über eine eigene logische Datei, die Logdatei.

Dort muss zusätzlich vermerkt werden, zu welcher Seite das before image gehört.

Zusätzlich ist das WAL (write-ahead Log)-Protokoll einzuhalten.

redo: Um im Fehlerfall die Transaktion wieder herstellen zu können, muss der neue Zustand jeder betroffenen Seite (after image) gesichert werden. Dies geschieht ebenfalls über die Logdatei.

23


Write-ahead Log-Protokoll

Datenbasis

Log

PPuffer

1. write P2. Speichere P

3. Speichere P`s Before-image

Systemzusammenbruch nach (2): (3) wird nicht ausgeführt

Bei Abbruch kann die Änderung von Ti nicht rückgängig gemacht werden, da das Before-image verlorengegangen ist.

Ti

WAL: Reihenfolge 1 - 3 - 2.

24


Beispiel für Steal/Force und Update-in-place

Systempuffer

P13P13

Platte Logt6:fetch/pin(P13)

t9:flush(P13)

t4:flush(P13)

P13

t2:fetch/pin(P13)

t4:Sichern des Before image von P13 auf die Log-DateiP13 t5: fetch/pin(P45)

P45P45

BOT

t1

commit

t8

Segment-Verwalter für T4711

Puffer- Verwaltung

EOT

t10t9

flush(P13)

read (P13)

t2

fetch/pin (P13)

t4

steal(P13)

write/unfix(P13)

t3

unpin(P13)

read(P45)

t5

fetch/pin(P45)

read(P13)

t6

fetch/pin(P13)

write/unfix(P13)

t7

unpin(P13)

25


crash recovery algorithms

steal update-in-place no-steal or shadowing

noforce force

with-undo no-undo

noforce force

with-undo/with-redo with-undo/no-redo no-undo/with-redo no-undo/no-redo

Keine Recovery-Aktionen

falls sich eine Aktion der Transaktion t nur in der Datenbasis auswirkt, wenn commit von t im Log vermerkt ist.

Optionen bei Crash-Recoveryundo kann notwendig sein um zu garantierendass sich eine Aktion der Transaktion t nur in der Datenbasis auswirkt, wenn commit von t im Log vermerkt ist.

Keine Recovery-Aktionensofern falls commit von t im Log vermerkt ist, sich auch alle Aktionen von t in der Datenbasis widerspiegeln.

redo kann notwendig sein um zu garantieren dasssofern falls commit von t im Log vermerkt ist, sich auch alle Aktionen von t in der Datenbasis widerspiegeln.

26


Transaktionen

undo

1(0)

j(1)

i(1)

2(1)

1(1)

p(0)

n+1(0)

n(0)

m(0)

k(0)

2(0)

op1(0) op

k-1(0)

op1(1) op

i-1(1)

01

01

01

01

1

Kompensation

Rekonstruktion


Von einer Transaktion bewirkter Endzustand

Seiten

27


Transaktionen

redo

1(0)

j(1)

i(1)

2(1)

1(1)

p(0)

n+1(0)

n(0)

m(0)

k(0)

2(0)

op1(0) op

k-1(0)

op1(1) op

i-1(1)

01

01

01

01

Rekonstruktion


Von einer Transaktion bewirkter Endzustand

Seiten

1

Kompensation

28


Bewertung

Option Kosten

no-undoIm Normalbetrieb sehr aufwendig wegen Pufferüberlastung.

no-redoHohe Seitentransferrate bei commit, dagegen ist force ins Log weitaus schneller.

no-undo / no-redo

Sofortiger Neustart möglich, aber im Normalbetrieb sehr aufwendig!

with-undo / with-redo

Übliche Wahl, da im Normalbetrieb am wenigsten aufwendig. Aufwand fällt stattdessen beim Neustart an.

Bei endlicher commit-Dauer physisch unmöglich! Zusatzmaßnahmen

29



Logging im NormalbetriebLogging im Normalbetrieb

30


Rolle des Backup-Verwalters

Log-datei


Scheduler




Sperren-Verwalter

Puffer- Verwalter

Daten-basis

p3 p2 p17 p24 p18 p57

p42 p8 p67 p19 p33 p81

p46 p25 p54 p66 p9 p91

p14 p68 p31 p29 p48 p47

p1 p5 p99 p23 p24 p56

p62 p15 p49 p36 p93 p7

Log-seiten

d4 d43 d17 d15 d2 d58

d5 d9 d26 d69 d6 d16

d46 d68 d55 d32 d97 d49

d25 d20 d67 d30 d49 d37

d19 d34 d10 d24 d25 d94

d63 d82 d49 d92 d57 d8

Daten-seiten

restart


unpindo(flush)

fetch, flush


Segment-Verwalter

31


Transaktionale Auswirkungen

Log-datei


Scheduler




Sperren-Verwalter

Puffer- Verwalter

Daten-basis

p3 p2 p17 p24 p18 p57

p42 p8 p67 p19 p33 p81

p46 p25 p54 p66 p9 p91

p14 p68 p31 p29 p48 p47

p1 p5 p99 p23 p24 p56

p62 p15 p49 p36 p93 p7

Log-seiten

d4 d43 d17 d15 d2 d58

d5 d9 d26 d69 d6 d16

d46 d68 d55 d32 d97 d49

d25 d20 d67 d30 d49 d37

d19 d34 d10 d24 d25 d94

d63 d82 d49 d92 d57 d8

Daten-seiten

restart


fetch, flush


Segment-Verwalter

Zentrale Voraussetzung Serialisierbarkeit:Operatoren verschiedener Transaktionen

beeinflussen sich gegenseitig nicht,Sperrende Scheduler: Transaktionen

könnten auch sequenziell in der Reihenfolge ihrer commits ablaufen.

unpindo(flush)

Folge:Commit-Operation muss als

letzte Operation im Log vermerkt werden,

Commit-Operationen sind somit in der Serialisierbarkeits- Reihenfolge vermerkt.

32


Transaktionale Auswirkungen

Log-datei


Scheduler




Sperren-Verwalter

Puffer- Verwalter

Daten-basis

p3 p2 p17 p24 p18 p57

p42 p8 p67 p19 p33 p81

p46 p25 p54 p66 p9 p91

p14 p68 p31 p29 p48 p47

p1 p5 p99 p23 p24 p56

p62 p15 p49 p36 p93 p7

Log-seiten

d4 d43 d17 d15 d2 d58

d5 d9 d26 d69 d6 d16

d46 d68 d55 d32 d97 d49

d25 d20 d67 d30 d49 d37

d19 d34 d10 d24 d25 d94

d63 d82 d49 d92 d57 d8

Daten-seiten

restart


fetch, flush


Segment-Verwalter

Zentrale Voraussetzung Serialisierbarkeit:Operatoren verschiedener Transaktionen

beeinflussen sich gegenseitig nicht,Sperrende Scheduler: Transaktionen

könnten auch sequenziell in der Reihenfolge ihrer commits ablaufen.

unpindo(flush)

Jede für das Logging bedeutsame Operation (bot, write, commit) wird mit einer monoton steigenden Sequenznummer (die Historie widerspiegelnd) markiert.

Log entspricht Historie: Jeder Log-Eintrag wird mit dieser Nummer (Log-Sequenznummer (LSN)) versehen.

Jede Datenseite trägt in ihrem Kopf eine Seiten-Sequenznummer (PSN).

Dies ist die LSN der letzten write-Operation.

33


Schreiben des Log

Log-datei


Scheduler




Sperren-Verwalter

Puffer- Verwalter

Daten-basis

p3 p2 p17 p24 p18 p57

p42 p8 p67 p19 p33 p81

p46 p25 p54 p66 p9 p91

p14 p68 p31 p29 p48 p47

p1 p5 p99 p23 p24 p56

p62 p15 p49 p36 p93 p7

Log-seiten

d4 d43 d17 d15 d2 d58

d5 d9 d26 d69 d6 d16

d46 d68 d55 d32 d97 d49

d25 d20 d67 d30 d49 d37

d19 d34 d10 d24 d25 d94

d63 d82 d49 d92 d57 d8

Daten-seiten

restart


fetch, flush


Segment-Verwalterunpin

do(flush)

Mit Beginn einer neuen Transaktion wird ein begin-Eintrag in den Log-Puffer geschrieben.

Bei write wird ein write-Eintrag in den Log-Puffer geschrieben.

Bei commit wird ein commit-Eintrag in den Log-Puffer geschrieben und dann der Pufferinhalt in den Log überführt (force).

Würde man bis flush warten, so könnte ein Daten-Eintrag nach dem commit-Eintrag zu liegen kommen!

Würde man noch zuwarten, so hätte commit keine persistente Wirkung!

34


Database Cache

Log Buffer

Stable Database

Stable Log

VolatileMemory

StableStorage

page qpage q

page ppage p

page ppage p

page qpage q

3155

3155

2788

4219

4215

page z page z 4217

write(b,t17)...

page zpage z4158

4208

4216 write(q,t19) 4199

4217 write(z,t17) 4215

4218 commit(t19) 4216

4219 write(q,t17) 4217

4220 begin(t20) nil

page bpage b4215

page bpage b4215

(page/log)sequencenumbers

Beispiel für die Sequenznummern

35


Datenstrukturen

var DatabaseCache: set of Page indexed by PageNo;type Page: record of PageNo: identifier; PageSeqNo: identifier; Status: (clean, dirty) /* only cache*/; Contents: array [PageSize] of char; end;var LogBuffer: ordered set of LogEntry indexed by LogSeqNo;type LogEntry: record of LogSeqNo: identifier; TransId: identifier; PageNo: identifier; ActionType: (write, full-write, begin, commit, rollback); UndoInfo: array of char; RedoInfo: array of char; PreviousSeqNo: identifier; end;

type TransInfo: record of TransId: identifier; LastSeqNo: identifier; end;var ActiveTrans: set of TransInfo indexed by TransId

Höchste für die Transaktion vergebene LSN

LSN.

PSN.

Verkettung innerhalb der Transaktion

36


write (pageno, transid): %DatabaseCache[pageno].Contents := modified contents; s := current sequence number; DatabaseCache[pageno].PageSeqNo := s; DatabaseCache[pageno].Status := dirty; newlogentry.LogSeqNo := s; newlogentry.ActionType := write; newlogentry.TransId := transid; newlogentry.PageNo := pageno; newlogentry.UndoInfo := information to undo update (before-image for full-write); newlogentry.RedoInfo := information to redo update (after-image for full-write); newlogentry.PreviousSeqNo := ActiveTrans[transid].LastSeqNo; ActiveTrans[transid].LastSeqNo := s; LogBuffer += newlogentry;

Umsetzung im Backup-Verwalter (1)

log data entry

already done

37


Umsetzung im Puffer-Verwalter

write-ahead

flush auf Eintrag möglicherweise bereits früher erfolgt!

fetch (pageno): Find slot in DatabaseCache and set its

PageNo := pageno; DatabaseCache[pageno].Contents := StableDatabase[pageno].Contents; DatabaseCache[pageno].PageSeqNo := StableDatabase[pageno].PageSeqNo; DatabaseCache[pageno].Status := clean;

flush (pageno): if there is logentry in LogBuffer with logentry.PageNo = pageno then force ( ); end /*if*/; StableDatabase[pageno].Contents := DatabaseCache[pageno].Contents; StableDatabase[pageno].PageSeqNo := DatabaseCache[pageno].PageSeqNo; DatabaseCache[pageno].Status := clean;

force ( ): StableLog += LogBuffer; LogBuffer := empty;

38


Umsetzung im Backup-Verwalter (2)

begin (transid): s := current sequence number; newtransentry.TransId := transid; ActiveTrans += newtransentry; ActiveTrans[transid].LastSeqNo := s; newlogentry.LogSeqNo := s; newlogentry.ActionType := begin; newlogentry.TransId := transid; newlogentry.PreviousSeqNo := nil; LogBuffer += newlogentry;

commit (transid): s := current sequence number; newlogentry.LogSeqNo := s; newlogentry.ActionType := commit; newlogentry.TransId := transid; newlogentry.PreviousSeqNo := ActiveTrans[transid].LastSeqNo; LogBuffer += newlogentry; ActiveTrans -= transid; force ( );

log BOT entry

log commit entry

39



Recovery am Beispiel Redo-WinnersRecovery am Beispiel Redo-Winners

40


Rolle des Recovery-Verwalters

Log-datei


Scheduler




Sperren-Verwalter

Puffer- Verwalter

Daten-basis

p3 p2 p17 p24 p18 p57

p42 p8 p67 p19 p33 p81

p46 p25 p54 p66 p9 p91

p14 p68 p31 p29 p48 p47

p1 p5 p99 p23 p24 p56

p62 p15 p49 p36 p93 p7

Log-seiten

d4 d43 d17 d15 d2 d58

d5 d9 d26 d69 d6 d16

d46 d68 d55 d32 d97 d49

d25 d20 d67 d30 d49 d37

d19 d34 d10 d24 d25 d94

d63 d82 d49 d92 d57 d8

Daten-seiten

restart


fetch, flush



do(flush)

41


Aufgabenverteilung

Log-datei


Scheduler




Sperren-Verwalter

Puffer- Verwalter

Daten-basis

p3 p2 p17 p24 p18 p57

p42 p8 p67 p19 p33 p81

p46 p25 p54 p66 p9 p91

p14 p68 p31 p29 p48 p47

p1 p5 p99 p23 p24 p56

p62 p15 p49 p36 p93 p7

Log-seiten

d4 d43 d17 d15 d2 d58

d5 d9 d26 d69 d6 d16

d46 d68 d55 d32 d97 d49

d25 d20 d67 d30 d49 d37

d19 d34 d10 d24 d25 d94

d63 d82 d49 d92 d57 d8

Daten-seiten

restart


pin, unpin

fetch, flush


Segment-Verwalter

Enges Zusammenwirken erforderlich!

42


Winners and losers

Winner: Winner transactions are those transactions for which a commit log entry is encountered.

Loser: Loser transactions are those transactions for which no commit entry exists in the log, i.e., that were still active during system crash.

Assumptions: All write actions during normal operation write entire pages

(“full-write”).

Transactions that have been aborted have been rolled back during normal operation and, hence, can be disregarded.

43


Simple Three-Pass Algorithm

Analysis pass: Determine start of log from master record. Perform forward scan to determine winners and losers.

Redo pass:

Perform forward scan to redo all winner actions in chronological (LSN) order (until end of log is reached).

Undo pass:

Perform backward scan to traverse all loser log entries in reverse chronological order and undo the corresponding actions.

Since these transactions must follow the last committed transaction in the serial order, their effects can be undone without endangering the committed transactions.

44


restart ( ): analysis pass ( ) returns losers; redo pass ( ); undo pass ( ); for each page p in DatabaseCache do

if DatabaseCache[p].Status = dirty then flush (p);end /*if/;end /*for*/;

reinitialize StableLog;

Simple Three-Pass Algorithm

Three passes

Because undo/redo use the cache, the cache must be cleared before resuming normal operation.

45


analysis pass ( ) returns losers:var losers: set of record TransId: identifier; LastSeqNo: identifier; end /*indexed by TransId*/; losers := empty; min := LogSeqNo of oldest log entry in StableLog; max := LogSeqNo of most recent log entry in StableLog; for i := min to max do case StableLog[i].ActionType: begin: losers += StableLog[i].TransId; losers[StableLog[i].TransId].LastSeqNo := nil; commit: losers -= StableLog[i].TransId; write: losers[StableLog[i].TransId].LastSeqNo := i; end /*case*/; end /*for*/;

Analysis Pass

We register losers only.

Each ta is a potential loser.

ta is a winner!

Forward scan

46


redo pass ( ): min := LogSeqNo of oldest log entry in StableLog; max := LogSeqNo of most recent log entry in StableLog; for i := min to max do if StableLog[i].ActionType = write and StableLog[i].TransId not in losers then pageno = StableLog[i].PageNo; fetch (pageno); full-write (pageno) with contents from StableLog[i].RedoInfo; end /*if*/; end /*for*/;

Redo Pass

Restore the winner no matter how much of it is already in stable database!

Forward scan: restore latest valid state according to history

47


undo pass ( ): while there exists t in losers such that losers[t].LastSeqNo <> nil do nexttrans = TransId in losers such that losers[nexttrans].LastSeqNo = max {losers[x].LastSeqNo | x in losers}; nextentry = losers[nexttrans].LastSeqNo; if StableLog[nextentry].ActionType = write then pageno = StableLog[nextentry].PageNo; fetch (pageno); full-write (pageno) with contents from StableLog[nextentry].UndoInfo; losers[nexttrans].LastSeqNo := StableLog[nextentry].PreviousSeqNo; end /*if*/; end /*while*/;

Undo Pass

Set of losers not yet exhausted?

Simulate backward scan on actions

Restore loser’s latest state no matter how much of it still is in stable database!

Losers’ next entry

48


1st crash 2nd crash

resumenormaloperation

restartcomplete

analysispass

redopass

undopass

analysispass

redopass

t1

t2

t3

t4

t5

flush(d) flush(d)

1st restart(incomplete)

2nd restart(complete)

w(a)

w(b)

w(c)

w(d)

w(d)

w(a)

w(d)

w(e)

w(b)

flush(b)

w(f)

Sample Scenario

49


Sample Scenario Data StructuresSequence number: action Change of cached database

[PageNo: SeqNo]Change of stable database [PageNo: SeqNo]

Log entry added to log buffer [LogSeqNo: action

Log entries added to stable log [LogSeqNo‘s]

1: begin (t1) 1: begin (t1)


3: write (a, t1) a: 3 3: write (a, t1)



6: write (b, t3) b: 6 6: write (b, t3)

7: write (c, t2) c: 7 7: write (c, t2)

8: write (d, t1) d: 8 8: write (d, t1)

9: commit (t1) 9: commit (t1) 1, 2, 3, 4, 5, 6, 7, 8, 9

10: flush (d) d: 8




14: commit (t3) 14: commit (t3) 11, 12, 13, 14

15: flush (d) d: 11


17: write (e, t2) e: 17 17: write (e, t2)


19: flush (b) b: 18 16, 17, 18

20: commit (t4) 20: commit (t4) 20

21: write (f, t5) f: 21 21: write (f, t5)

SYSTEM CRASH

50


First restart

Sequence number: action Change of cached database [PageNo: SeqNo]

Change of stable database [PageNo: SeqNo]



redo (3) a: 3

redo (6) b: 6

flush (a) a: 3

redo (8) d: 8

flush (d) d: 8

redo (11) d: 11

SECOND SYSTEM CRASH

Analysis pass: losers = {t2, t5}

Redo pass + :

51


Second restart





redo (3) a: 3

redo (6) b: 6

redo (8) d: 8

redo (11) d: 11

redo(16) d: 16

undo(18) b: 6

undo(17) e: 0

undo(13) a: 3

undo(7) c: 0

SECOND RESTART COMPLETE: RESUME NORMAL OPERATION

Analysis pass: losers = {t2, t5}

Redo pass + undo pass:

52


Transaction aborts

Problem: Write actions are logged before the outcome of the transaction becomes known. Transaction abort requires a rollback.

All logging information would then have to be removed. Otherwise the assumption that losers follow winners in the serial order would no longer apply.

A system crash may occur during rollback, and the abort would have to recover from this crash.

53


Transaction rollback

Solution: Treat a rolled back transaction as a winner. Create compensation log entries for inverse operations

during transaction rollback.

Complete rollback by creating rollback log entry.

During crash recovery, aborted transactions with complete rollback are winners (and are redone in the right serial order), incomplete aborted transactions are losers.

54


Transaction rollbackabort (transid): logentry := ActiveTrans[transid].LastSeqNo; while logentry is not nil and logentry.ActionType = write do newlogentry.LogSeqNo := new sequence number; newlogentry.ActionType := compensation; newlogentry.PreviousSeqNo := ActiveTrans[transid].LastSeqNo; newlogentry.RedoInfo := inverse action of the action in logentry; newlogentry.UndoInfo := inverse action of inverse action of action in logentry; ActiveTrans[transid].LastSeqNo := newlogentry.LogSeqNo; LogBuffer += newlogentry; write (logentry.PageNo) according to logentry.UndoInfo; logentry := logentry.PreviousSeqNo; end /*while*/ newlogentry.LogSeqNo := new sequence number; newlogentry.ActionType := rollback; newlogentry.TransId := transid; newlogentry.PreviousSeqNo := ActiveTrans[transid].LastSeqNo; LogBuffer += newlogentry; ActiveTrans -= transid; force ( );

55


Sample Scenario

crash

t1 w(a)

flush(a)

t2 w(a)

t3 w(a)

t4 w(a)w(b)

rollback

rollback

56


Sample Scenario Data Structures







3: commit (t1) 3: commit (t1) 1, 2, 3



6: abort (t2)

7: compensate(5) a: 7 7: compensate (a, t2)

8: rollback (t2) 8: rollback (t2) 4, 5, 7, 8



11: commit (t3) 11: commit (t3) 9, 10, 11




15: abort (t4)

16: compensate(14) a: 16 16: compensate (a, t4)

17: flush (a) a: 16 12, 13, 14, 16

SYSTEM CRASH

57


Restart





redo (2) a: 2

redo (5) a: 5

redo (7) a: 7

redo (10) a: 10

undo(16) a: 14

undo(14) a: 10

undo(13) b: 0

RESTART COMPLETE: RESUME NORMAL OPERATION

Analysis pass: losers = {t4}

Redo pass + undo pass:

58


Alternativen

Der einfache redo-winners Algorithmus ist für praktische Zwecke meist zu ineffizient.

Weitere grundsätzliche Ansätze in der Vorlesung “Transaktionsverwaltung”.

59



Nicht-Transaktionale ZuverlässigkeitNicht-Transaktionale Zuverlässigkeit

60


Segmente

Recovery in der Segmentschicht

1

1(0)

j(1)

i(1)

2(1)

1(1)

p(0)

n+1(0)

n(0)

m(0)

k(0)

2(0)

op1(0) op

k-1(0)

op1(1) op

i-1(1)

01

01

01

01

Kompensation

Rekonstruktion


Segmentspezifischer Sicherungspunkt

Seiten

61


Rolle des Backup-Verwalters

Log-datei


Scheduler




Sperren-Verwalter

Puffer- Verwalter

Daten-basis

p3 p2 p17 p24 p18 p57

p42 p8 p67 p19 p33 p81

p46 p25 p54 p66 p9 p91

p14 p68 p31 p29 p48 p47

p1 p5 p99 p23 p24 p56

p62 p15 p49 p36 p93 p7

Log-seiten

d4 d43 d17 d15 d2 d58

d5 d9 d26 d69 d6 d16

d46 d68 d55 d32 d97 d49

d25 d20 d67 d30 d49 d37

d19 d34 d10 d24 d25 d94

d63 d82 d49 d92 d57 d8

Daten-seiten


fetch, flush



do(flush)

restart

entfällt

Ignoriert (zunächst) Transaktionsgrenzen

62


B2

Bk+2

B3

Bk+3

B4

...

B5

...

Bk+n

Bk

B1

Bk+1

P1 P2 P3 ... Pk P1‘ P2‘ P3‘ ... Pn‘

Segment S1

Segment S2

B2 B4 B5 ... Bk+2 B1 Bk B3 ... Bk+3

Seitentabelle von S1

Seitentabelle von S2

Erinnerung: Indirekte Seitenabbildung

63


Schattenspeicher-Verfahren (1) Zuverlässigkeit, indem in bestimmten zeitlichen Abständen

Sicherungspunkte durchgeführt werden. Bei einer zwischenzeitlichen Änderung einer Seite wird die

Version des letzten Sicherungspunktes aufbewahrt (Schattenseite), und die geänderte Seite wird in einem neuen Block gespeichert.

Es existieren zwei Seitentabellen: Die aktuelle Seitentabelle verweist auf die Blöcke, die die

aktuellen Versionen der Seiten enthalten.

Die Schattenseitentabelle verweist auf die Schattenseiten (also die Blöcke, die die Versionen der Seiten vom letzten Sicherungspunkt enthalten).

64


P1 P2 P3 P4 P5 ... Pi ...

2 0 0 5 0 ... j ...

B1 B2 B3 B4 B5 ... Bj ... Bk ...

Segment 4711

Schatten-seitentabelle aktuelle Seitentabelle

Datei 15

Schattenspeicher-Verfahren (2)

= Schattenbit

3 0 0 5 0 ... j ...

Anzeige der Modifikation einer Seite seit dem letzten Sicherungspunkt

65


P1 P2 P3 P4 P5 ... Pi ...

2 0 0 5 0 ... j ...

B1 B2 B3 B4 B5 ... Bj ... Bk ...

Segment 4711


Datei 15


= Schattenbit

3 0 0 5 0 ... j ...

Bei einem Sicherungspunkt werden die Blöcke der Schattenseiten freigegeben, und die Einträge der aktuellen Seitentabelle werden in die Schattenseitentabelle kopiert.

66


P1 P2 P3 P4 P5 ... Pi ...

2 0 0 5 0 ... j ...

B1 B2 B3 B4 B5 ... Bj ... Bk ...

Segment 4711


Datei 15


= Schattenbit

3 0 0 5 0 ... j ...

Bei Störungen wird auf den letzten Sicherungspunkt zurückgesetzt.

Das Rücksetzen auf den Zustand des letzten Sicherungspunktes erfolgt durch Freigabe der seit dem letzten Sicherungspunkt modifizierten Seiten und Kopieren der Einträge der Schattenseitentabelle in die aktuelle Seitentabelle.

67


P1 P2 P3 P4 P5 ... Pi ...

2 0 0 5 0 ... j ...

2 0 0 5 0 ... j ...

B1 B2 B3 B4 B5 ... Bj ... Bk ...

Segment 4711


Datei15

Schattenspeicher-Algorithmen (1)

algorithm read_page input Seitennummer P; output Nummer des Blocks mit der aktuellen Version von P; begin Sei B der Eintrag zu P in der aktuellen Seitentabelle; return B; end;

68


Schattenspeicher-Algorithmen (2)algorithm write_page

inputSeitennummer P; begin if das Schattenbit zu Seite P ist gesetzt

** P wurde seit dem letzten Sicherungspunkt modifiziert then begin

Sei B der Eintrag zu P in der aktuellen Seitentabelle;** Es wird stets in existierende Seiten geschrieben

Schreibe die neue Version von P in Block B; end; else begin

** P wurde seit dem letzten Sicherungspunkt nicht modifiziert Allokiere einen neuen Block B'; Trage Block B' in die aktuelle Seitentabelle in den Eintrag für

Seite P ein; Schreibe die neue Version von P in den Block B';

Setze das Schattenbit zu Seite P in der aktuellen Seitentabelle; end;

end;

69


P1 P2 P3 P4 P5 ... Pi ...

2 0 0 5 0 ... j ...

B1 B2 B3 B4 B5 ... Bj ... Bk ...

2 0 0 5 0 ... j ...

Segment 4711


Datei15


= Schattenbit

3 0 0 5 0 ... j ...

write_page(P1);

x

70


algorithm delete_page input Nummer P der zu löschenden Seite begin

if Schattenbit zu Seite P ist gesetzt then beginSei B der Eintrag zu P in der aktuellen

Seitentabelle; Gib Block B frei;

end; Trage 0 in die aktuelle Seitentabelle in den Eintrag

für Seite P ein; Setze das Schattenbit zu Seite P in der aktuellen

Seitentabelle; end;


71


3 0 0 5 0 ... k ...

P1 P2 P3 P4 P5 ... Pi ...

2 0 0 5 0 ... j ...

B1 B2 B3 B4 B5 ... Bj ... Bk ...

Segment 4711


Datei15


= Schattenbit

delete_page(P4);

3 0 0 0 0 ... k ...

x

72



algorithm create_page output Nummer P der neuen Seite begin

Suche eine Seitennummer P, der kein Block zugeordnet ist (Blocknummer 0 in

beiden Seitentabellen); Allokiere einen neuen Block B; Trage Block B in die aktuelle Seitentabelle in den

Eintrag für Seite P ein; Setze das Schattenbit zu Seite P in der aktuellen

Seitentabelle;return P;

end;

73


3 0 0 0 0 ... k ...

P1 P2 P3 P4 P5 ... Pi ...

2 0 0 5 0 ... j ...

B1 B2 B3 B4 B5 ... Bj ... Bk ...

Segment 4711


Datei15

= Schattenbit

create_page;


3 1 0 0 0 ... k ...

74


Setzen eines Sicherungspunktes (1)algorithm Checkpoint

input Nummer S des Segments, das gesichert werden soll;begin

foreach Seite P des Segments S do if Schattenbit zu Seite P ist gesetzt then begin

Sei B der Eintrag zu P in der aktuellen Seitentabelle;Sei B' der Eintrag zu P in der Schattenseitentabelle;if B‘0 then Gib Block B‘ frei; Trage Block B in die Schattenseitentabelle

in den Eintrag für Seite P ein; Lösche das Schattenbit zu Seite P; end;

end;

75


P1 P2 P3 P4 P5 ... Pi ...

2 0 0 5 0 ... j ...

B1 B2 B3 B4 B5 ... Bj ... Bk ...

Segment 4711


Datei15

= Schattenbit

3 1 0 0 0 ... k ...

1. Gib die Blöcke der Schattenseiten frei

F F F

Setzen eines Sicherungspunktes (2)

76


3 1 0 0 0 ... k ...

P1 P2 P3 P4 P5 ... Pi ...

2 0 0 5 0 ... j ...

B1 B2 B3 B4 B5 ... Bj ... Bk ...

Segment 4711


Datei15

= Schattenbit

2. Kopieren der Einträge der aktuellen Seitentabelle und Löschen der Schattenbits:

Setzen eines Sicherungspunktes (2)

3 1 0 0 0 ... k ...

3 1 0 0 0 ... k ...

77


(2)

(1)

(0)

checkpoint(S1)

Atomares Sichern (1)

Checkpoint segment Swrite_page(P1) write_page(P1)

Transaktion

ResetToLastCheckpoint

Sicherungspunkt: Zustand peripher zu sichern

78


Atomares Sichern (1)algorithm CheckpointMitSicherungDurchRekonstruktion

input Nummer S des Segments, das zurückgesetzt werden soll;beginKopiere die Schatten- und aktuelle Seitentabelle;Kopiere die Blöcke, die im weiteren freigegeben werden;


Sei B der Eintrag zu P in der aktuellen Seitentabelle;Sei B' der Eintrag zu P in der Schattenseitentabelle;if B‘0 then Gib Block B‘ frei; Trage Block B in die Schattenseitentabelle

in den Eintrag für Seite P ein; Lösche das Schattenbit zu Seite P; end;

Werfe Kopien weg;end;

79


(2)

(1)

(0)

checkpoint(S1)

Atomares Sichern (2)

Checkpoint segment Swrite_page(P1) write_page(P1)

Transaktion

ResetToLastCheckpoint

Sicherungspunkt: Zustand peripher zu sichern

80


Atomares Sichern (2)algorithm CheckpointMitSicherungDurchKompensation

input Nummer S des Segments, das zurückgesetzt werden soll;beginLege eine Log-Datei an;


Sei B der Eintrag zu P in der aktuellen Seitentabelle;Sei B' der Eintrag zu P in der Schattenseitentabelle;Protokolliere Eintrag von Block B‘ für Seite P in der Log-Datei;if B‘0 then begin

Protokolliere Freigabe und Inhalt von B' in der Log-Datei;

Gib Block B‘ frei; end;Trage Block B in die aktuelle Schattenseitentabelle

in den Eintrag für Seite P ein; Lösche das Schattenbit zu Seite P;

end;Lösche Log-Datei;end;

81


Rücksetzen auf letzten Sicherungspunkt

algorithm ResetToLastCheckpoint

input S ist Segment, das zurückgesetzt werden soll;

begin

foreach Seite P des Segments S do

if Schattenbit zu Seite P ist gesetzt then begin

Sei B der Eintrag zu P in der aktuellen Seitentabelle;

Sei B' der Eintrag zu P in der Schattenseitentabelle;

if B0 then Gib Block B frei;

Trage Block B' in die aktuelle Seitentabelle

in den Eintrag für Seite P ein;

Lösche das Schattenbit zu Seite P;

end;

end;

82


Freispeicherverwaltung

Häufig wird die Freispeicherverwaltung für die Datei an das Schattenspeicher-Verfahren angepasst.

Es werden dabei zwei Datenstrukturen (bspw. Freispeicherlisten oder Bitleisten) für die Markierung der freien Blöcke einer Platte geführt: eine aktuelle und eine Schattenversion.

Die aktuelle Version führt die Belegungen beider Segmentversionen vereinfachte Prüfung auf freien Block!

Zum Ende des Durchführens eines Sicherungspunktes wird die aktuelle Version auf die Schattenversion kopiert, zum Ende des Rücksetzens auf einen Sicherungspunkt wird die Schattenversion auf die aktuelle Version kopiert.

83


Bewertung des Schattenspeicherkonzepts

Vorteile: Einfaches Zurücksetzen auf Sicherungspunkt. Einfacher Wiederanlauf nach Fehlerfall, da mit Schattenseiten

ein konsistenter Zustand der DB vorliegt.Nachteile:

Zerstörung von Nachbarschaften: Durch die Allokation neuer Blöcke bei Änderungen ist es nicht möglich, häufig gemeinsam benötigte Seiten in benachbarten Blöcken zu halten.

Sicherungspunkte verursachen punktuell hohe E/A. Zwischen zwei Sicherungspunkten belegen geänderte Seiten

zwei Blöcke (hoher Speicherbedarf; mögliche Reduktion durch kürzere Sicherungsintervalle).

Zusammenhang zwischen Transaktionen und Sicherungspunkten nur mit hohem Zusatzaufwand herstellbar.

Recovery beschränkt durch maximal 2 Zustände pro Seite.

84


Twin-Block-Verfahren (1) Vereinfachtes Shadowing mit direkter Seitenabbildung.

Jeder Seite Pi werden zwei benachbarte Blöcke zugeordnet, d.h. die Übergang zwischen den beiden logischen Blöcken ist minimal.

Beispiel:B8 B1

B2

B3

B4B5

B6

B7

P1

P1‘

P2

P2‘P3

P3‘

P4

P4‘

85


Twin-Block-Verfahren (2)

Auf den beiden einer Seite zugeordneten Blöcken sind zwei verschiedene Versionen der Seite gespeichert: die aktuelle Version der Seite, die

von der letzten schreibenden Aktion (aktuelle oder letzte abgeschlossene) erzeugt wurde,

die Version, die von der vorletzten schreibenden Aktion erzeugt wurde.

Seien Bj und Bj+1 die Blöcke zu Seite Pi. Auf Block Bj wird ein Markierungsbit gespeichert: enthält Bj die aktuelle Version der Seite, dann ist das Bit 1, ansonsten 0.

B8 B1

B2

B3

B4B5

B6

B7

P1

P1‘

P2

P2‘P3

P3‘

P4

P4‘

86


Twin-Block-Verfahren (3)

Ursprünglich nicht transaktionsbezogen, lässt sich aber so abwickeln:

read: Es werden beide Blöcke eingelagert. Anhand des Bits wird die aktuelle Version festgestellt. Lese- und Schreiboperationen werden auf dem

Seitenrahmen durchgeführt, der die aktuelle Version der Seite enthält.

Bei flush oder spätestens bei commit einer schreibenden Transaktion wird der neue Zustand der Seite auf den Block zurückgeschrieben,

der die ältere Version der Seite enthält, und das Markierungsbit auf dem ersten Block invertiert.

Das Before image der Seite bleibt somit auf dem anderen Block erhalten.

87


Beispiel für das Twin-Block-VerfahrenTransaktion T4712 fixiert Seite Pi (auf Bj + Bj+1) zum Lesen

T4712EOT

Platte

(Da das Markierungsbit nicht gesetzt ist, enthält Bj+1 die aktuelle Version der Seite Pi)

read(Pi) commit

Systempuffer

= Markierungsbit gesetzt= Markierungsbit nicht gesetzt

Bj+1

Einlagern von Bj

und Bj+1

Pi0 Pi1

Bj

88


T4713EOTread (Pi)BOT speichere(Pi)

Systempuffer

= Markierungsbit gesetzt= Markierungsbit nicht gesetzt

Beispiel für das Twin-Block-VerfahrenTransaktion T4712 fixiert Seite Pi (auf Bj + Bj+1) zum Lesen und Schreiben

Platte

Bj+1Bj

Pi1

Einlagern von Bj

und Bj+1

Pi0

(Da das Markierungsbit nicht gesetzt ist, enthält Bj+1 die aktuelle Version der Seite Pi)

Modifizieren des aktuellen Zustands

jB Bj+1Einbringen des neuen Zustands in Block Bj und Setzen des Markierungsbits

write(Pi)

89


Beurteilung

Vorteile Geringer Verwaltungsaufwand. Einfache Implementierung. Schnelle Zugriffe, da die Blöcke zu einer Seite benachbart

sind.

Nachteile Doppelter Speicherplatzbedarf für die Datenbasis

unabhängig von der Häufigkeit von Änderungen an Seiten. Pro fetch einer Seite zwei Blockzugriffe. Nur transaktionsbezogen wenn (wegen Markierungsbit)

Striktes 2-Phasen-Sperrprotokoll mit force (nur 2 Zustände!), bei abort Rücksetzen des Bit bei geänderten Seiten.

Universität Karlsruhe (TH) © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Kapitel 4...

Documents

Transcript of Universität Karlsruhe (TH) © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Kapitel 4...