Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Universität Karlsruhe (TH) © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Kapitel 4 Zuverlässigkeit und Recovery in der Segmentschicht.

Ähnliche Präsentationen


Präsentation zum Thema: "Universität Karlsruhe (TH) © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Kapitel 4 Zuverlässigkeit und Recovery in der Segmentschicht."—  Präsentation transkript:

1 Universität Karlsruhe (TH) © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Kapitel 4 Zuverlässigkeit und Recovery in der Segmentschicht

2 2 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 3 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Architektur im Detail – 2. Schritt Protokoll- datei Transaktion 1Transaktion 2... Transaktion n Scheduler Segment- Verwalter Schedule 1Schedule n Sperren-Verwalter Puffer- Verwalter Daten- basis p3p3 p2p2 p 17 p 24 p 18 p 57 p 42 p8p8 p 67 p 19 p 33 p 81 p 46 p 25 p 54 p 66 p9p9 p 91 p 14 p 68 p 31 p 29 p 48 p 47 p1p1 p5p5 p 99 p 23 p 24 p 56 p 62 p 15 p 49 p 36 p 93 p7p7 Protokoll- seiten d4d4 d 43 d 17 d 15 d2d2 d 58 d5d5 d9d9 d 26 d 69 d6d6 d 16 d 46 d 68 d 55 d 32 d 97 d 49 d 25 d 20 d 67 d 30 d 49 d 37 d 19 d 34 d 10 d 24 d 25 d 94 d 63 d 82 d 49 d 92 d 57 d8d8 Daten- seiten Transaktionsverwaltung Recovery Konflikt-resistenter Gesamt-Schedule Persistenz Fehler-Resistenz Performanz eigene Vorlesung letztes Kapitel dieses Kapitel

4 4 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Kapitel 4.1 Fehlermodell

5 5 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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) op 1 (0) op k-1 (0) op 1 (1) op i-1 (1) op 1 (2) Operation 0-Operationen Konstruktion 0-konsistente Zustände

6 6 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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) op 1 (0) op k-1 (0) op 1 (1) op i-1 (1) op 1 (2) Operationen 1-Operation Letzter 0-konsistenter Zustand Kommt nicht zum erfolgreichen Ende Gilt also nicht mehr

7 7 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 Letzter 1-konsistenter 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) op 1 (0) op k-1 (0) op 1 (1) op i-1 (1) op 1 (2) Operationen 1-Operation Letzter 0-konsistenter Zustand Letzter 1-konsistenter 0-Zustand Kompensation

8 8 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Kompensation i Inverse Funktionen (Kompensationsfunktionen): Kompensationen von Operationen der Ebene i, die vor dem Abbruch abgeschlossen waren, sind zulässig, falls 1. 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 9 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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) op 1 (0) op k-1 (0) op 1 (1) op i-1 (1) op 1 (2)

10 10 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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) op 1 (0) op k-1 (0) op 1 (1) op i-1 (1) Kompensation Rekonstruktion 0-Konsistenz durch RAID usw. gesichert. Seiten ? Entwurfsentscheidung: Wahl von j (1)

11 11 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Kapitel 4.2 Transaktionale Zuverlässigkeit

12 12 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 13 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Transaktionale Architektur d. Segmentschicht Log- datei Transaktion 1Transaktion 2... Transaktion n Scheduler Recovery- Backup- Verwalter Historie 1Historie n Globale Historie aus read, write, allocate, unfix, commit, abort Sperren-Verwalter Puffer- Verwalter Daten- basis p3p3 p2p2 p 17 p 24 p 18 p 57 p 42 p8p8 p 67 p 19 p 33 p 81 p 46 p 25 p 54 p 66 p9p9 p 91 p 14 p 68 p 31 p 29 p 48 p 47 p1p1 p5p5 p 99 p 23 p 24 p 56 p 62 p 15 p 49 p 36 p 93 p7p7 Log- seiten d4d4 d 43 d 17 d 15 d2d2 d 58 d5d5 d9d9 d 26 d 69 d6d6 d 16 d 46 d 68 d 55 d 32 d 97 d 49 d 25 d 20 d 67 d 30 d 49 d 37 d 19 d 34 d 10 d 24 d 25 d 94 d 63 d 82 d 49 d 92 d 57 d8d8 Daten- seiten restart fetch, flush read, write, allocate, unfix Segment- Verwalter Isolation Atomizität Einbring- Strategien Transaktionsverwaltung

14 14 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Kapitel Segment-Verwalter

15 15 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 16 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 17 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 Verwalter mit Nosteal-Strategie read(a,b,c)

18 18 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Verdrängungs- und Auslagerungsstrategie (2) 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). Transaktions- verhalten 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 19 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Verdrängungs- und Auslagerungsstrategie (3) Verdrängungs- und Auslagerungsstrategie lassen sich beliebig kombinieren. unpin(a,b,c) flush(a,b,c) Verwalter mit Nosteal/Force-Strategie Transaktions- verhalten write(a) unfix(a) write(b) unfix(b) write(c) unfix(c) commitread(a,b,c) flush(a)flush(b)flush(c) Verwalter mit Steal/Noforce-Strategie unpin(a)unpin(b)unpin(c)flush(a)flush(b)flush(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 20 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 crash recovery algorithms steal update-in-placenosteal or shadowing noforceforce with-undo no-undo noforceforce with-undo/with-redowith-undo/no-redono-undo/with-redono-undo/no-redo Konsequenzen für Crash-Recovery undo: Beseitige Wirkung der Transaktion redo: Stelle Wirkung der Transaktion wieder her

21 21 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Kapitel Vorgehen bei Update-in-place

22 22 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 23 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Write-ahead Log-Protokoll Datenbasis Log P Puffer 1. write P 2. Speichere P 3. Speichere P`s Before-image Systemzusammenbruch nach (2): (3) wird nicht ausgeführt Bei Abbruch kann die Änderung von T i nicht rückgängig gemacht werden, da das Before-image verlorengegangen ist. TiTi WAL: Reihenfolge

24 24 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Beispiel für Steal/Force und Update-in-place Systempuffer P13 Platte Log t6:fetch/pin(P13) t9:flush(P13) t4:flush(P13) P13 t2:fetch/pin(P13) t4:Sichern des Before image von P13 auf die Log- Datei P13 t5: fetch/pin(P45) P45 BOT t1 commit t8 Segment- Verwalter für T4711 Puffer- Verwaltung EOT t10 t9 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 25 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 crash recovery algorithms steal update-in-placeno-steal or shadowing noforceforce with-undo no-undo noforceforce with-undo/with-redowith-undo/no-redono-undo/with-redono-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-Recovery undo kann notwendig sein um zu garantieren dass sich eine Aktion der Transaktion t nur in der Datenbasis auswirkt, wenn commit von t im Log vermerkt ist. Keine Recovery-Aktionen sofern 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 dass sofern falls commit von t im Log vermerkt ist, sich auch alle Aktionen von t in der Datenbasis widerspiegeln.

26 26 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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) op 1 (0) op k-1 (0) op 1 (1) op i-1 (1) Kompensation Rekonstruktion 0-Konsistenz durch RAID usw. gesichert. Von einer Transaktion bewirkter Endzustand Seiten

27 27 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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) op 1 (0) op k-1 (0) op 1 (1) op i-1 (1) Rekonstruktion 0-Konsistenz durch RAID usw. gesichert. Von einer Transaktion bewirkter Endzustand Seiten 1 Kompensation

28 28 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Bewertung OptionKosten no-undo Im Normalbetrieb sehr aufwendig wegen Pufferüberlastung. no-redo Hohe 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 29 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Kapitel Logging im Normalbetrieb

30 30 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Rolle des Backup-Verwalters Log- datei Transaktion 1Transaktion 2... Transaktion n Scheduler Recovery- Backup- Verwalter Historie 1Historie n Globale Historie aus read, write, allocate, unfix, commit, abort Sperren-Verwalter Puffer- Verwalter Daten- basis p3p3 p2p2 p 17 p 24 p 18 p 57 p 42 p8p8 p 67 p 19 p 33 p 81 p 46 p 25 p 54 p 66 p9p9 p 91 p 14 p 68 p 31 p 29 p 48 p 47 p1p1 p5p5 p 99 p 23 p 24 p 56 p 62 p 15 p 49 p 36 p 93 p7p7 Log- seiten d4d4 d 43 d 17 d 15 d2d2 d 58 d5d5 d9d9 d 26 d 69 d6d6 d 16 d 46 d 68 d 55 d 32 d 97 d 49 d 25 d 20 d 67 d 30 d 49 d 37 d 19 d 34 d 10 d 24 d 25 d 94 d 63 d 82 d 49 d 92 d 57 d8d8 Daten- seiten restart Transaktionsverwaltung unpin do(flush) fetch, flush read, write, allocate, unfix Segment- Verwalter

31 31 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Transaktionale Auswirkungen Log- datei Transaktion 1Transaktion 2... Transaktion n Scheduler Recovery- Backup- Verwalter Historie 1Historie n Globale Historie aus read, write, allocate, unfix, commit, abort Sperren-Verwalter Puffer- Verwalter Daten- basis p3p3 p2p2 p 17 p 24 p 18 p 57 p 42 p8p8 p 67 p 19 p 33 p 81 p 46 p 25 p 54 p 66 p9p9 p 91 p 14 p 68 p 31 p 29 p 48 p 47 p1p1 p5p5 p 99 p 23 p 24 p 56 p 62 p 15 p 49 p 36 p 93 p7p7 Log- seiten d4d4 d 43 d 17 d 15 d2d2 d 58 d5d5 d9d9 d 26 d 69 d6d6 d 16 d 46 d 68 d 55 d 32 d 97 d 49 d 25 d 20 d 67 d 30 d 49 d 37 d 19 d 34 d 10 d 24 d 25 d 94 d 63 d 82 d 49 d 92 d 57 d8d8 Daten- seiten restart Transaktionsverwaltung fetch, flush read, write, allocate, unfix 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. unpin do(flush) Folge: Commit-Operation muss als letzte Operation im Log vermerkt werden, Commit-Operationen sind somit in der Serialisierbarkeits- Reihenfolge vermerkt.

32 32 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Transaktionale Auswirkungen Log- datei Transaktion 1Transaktion 2... Transaktion n Scheduler Recovery- Backup- Verwalter Historie 1Historie n Globale Historie aus read, write, allocate, unfix, commit, abort Sperren-Verwalter Puffer- Verwalter Daten- basis p3p3 p2p2 p 17 p 24 p 18 p 57 p 42 p8p8 p 67 p 19 p 33 p 81 p 46 p 25 p 54 p 66 p9p9 p 91 p 14 p 68 p 31 p 29 p 48 p 47 p1p1 p5p5 p 99 p 23 p 24 p 56 p 62 p 15 p 49 p 36 p 93 p7p7 Log- seiten d4d4 d 43 d 17 d 15 d2d2 d 58 d5d5 d9d9 d 26 d 69 d6d6 d 16 d 46 d 68 d 55 d 32 d 97 d 49 d 25 d 20 d 67 d 30 d 49 d 37 d 19 d 34 d 10 d 24 d 25 d 94 d 63 d 82 d 49 d 92 d 57 d8d8 Daten- seiten restart Transaktionsverwaltung fetch, flush read, write, allocate, unfix 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. unpin do(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 33 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Schreiben des Log Log- datei Transaktion 1Transaktion 2... Transaktion n Scheduler Recovery- Backup- Verwalter Historie 1Historie n Globale Historie aus read, write, allocate, unfix, commit, abort Sperren-Verwalter Puffer- Verwalter Daten- basis p3p3 p2p2 p 17 p 24 p 18 p 57 p 42 p8p8 p 67 p 19 p 33 p 81 p 46 p 25 p 54 p 66 p9p9 p 91 p 14 p 68 p 31 p 29 p 48 p 47 p1p1 p5p5 p 99 p 23 p 24 p 56 p 62 p 15 p 49 p 36 p 93 p7p7 Log- seiten d4d4 d 43 d 17 d 15 d2d2 d 58 d5d5 d9d9 d 26 d 69 d6d6 d 16 d 46 d 68 d 55 d 32 d 97 d 49 d 25 d 20 d 67 d 30 d 49 d 37 d 19 d 34 d 10 d 24 d 25 d 94 d 63 d 82 d 49 d 92 d 57 d8d8 Daten- seiten restart Transaktionsverwaltung fetch, flush read, write, allocate, unfix Segment- Verwalter unpin 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 34 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Database Cache Log Buffer Stable Database Stable Log Volatile Memory Stable Storage page q page p page q page z 4217 write(b,t 17 )... page z write(q,t 19 ) write(z,t 17 ) commit(t 19 ) write(q,t 17 ) begin(t 20 ) nil page b 4215 page b 4215 (page/log) sequence numbers Beispiel für die Sequenznummern

35 35 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 36 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 37 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 38 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 39 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Kapitel Recovery am Beispiel Redo-Winners

40 40 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Rolle des Recovery-Verwalters Log- datei Transaktion 1Transaktion 2... Transaktion n Scheduler Recovery- Backup- Verwalter Historie 1Historie n Globale Historie aus read, write, allocate, unfix, commit, abort Sperren-Verwalter Puffer- Verwalter Daten- basis p3p3 p2p2 p 17 p 24 p 18 p 57 p 42 p8p8 p 67 p 19 p 33 p 81 p 46 p 25 p 54 p 66 p9p9 p 91 p 14 p 68 p 31 p 29 p 48 p 47 p1p1 p5p5 p 99 p 23 p 24 p 56 p 62 p 15 p 49 p 36 p 93 p7p7 Log- seiten d4d4 d 43 d 17 d 15 d2d2 d 58 d5d5 d9d9 d 26 d 69 d6d6 d 16 d 46 d 68 d 55 d 32 d 97 d 49 d 25 d 20 d 67 d 30 d 49 d 37 d 19 d 34 d 10 d 24 d 25 d 94 d 63 d 82 d 49 d 92 d 57 d8d8 Daten- seiten restart Transaktionsverwaltung fetch, flush read, write, allocate, unfix Segment- Verwalter unpin do(flush)

41 41 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Aufgabenverteilung Log- datei Transaktion 1Transaktion 2... Transaktion n Scheduler Recovery- Backup- Verwalter Historie 1Historie n Globale Historie aus read, write, allocate, unfix, commit, abort Sperren-Verwalter Puffer- Verwalter Daten- basis p3p3 p2p2 p 17 p 24 p 18 p 57 p 42 p8p8 p 67 p 19 p 33 p 81 p 46 p 25 p 54 p 66 p9p9 p 91 p 14 p 68 p 31 p 29 p 48 p 47 p1p1 p5p5 p 99 p 23 p 24 p 56 p 62 p 15 p 49 p 36 p 93 p7p7 Log- seiten d4d4 d 43 d 17 d 15 d2d2 d 58 d5d5 d9d9 d 26 d 69 d6d6 d 16 d 46 d 68 d 55 d 32 d 97 d 49 d 25 d 20 d 67 d 30 d 49 d 37 d 19 d 34 d 10 d 24 d 25 d 94 d 63 d 82 d 49 d 92 d 57 d8d8 Daten- seiten restart Transaktionsverwaltung pin, unpin fetch, flush read, write, allocate, unfix Segment- Verwalter Enges Zusammenwirken erforderlich!

42 42 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 43 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 44 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 45 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 46 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 47 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 losers latest state no matter how much of it still is in stable database! Losers next entry

48 48 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 1 st crash2 nd crash resume normal operation restart complete analysis pass redo pass undo pass analysis pass redo pass t1t1 t2t2 t3t3 t4t4 t5t5 flush(d) 1 st restart (incomplete) 2 nd restart (complete) w(a) w(b) w(c) w(d) w(a) w(d) w(e) w(b) flush(b) w(f) Sample Scenario

49 49 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Sample Scenario Data Structures Sequence number: actionChange 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 [LogSeqNos] 1: begin (t 1 ) 2: begin (t 2 ) 3: write (a, t 1 )a: 33: write (a, t 1 ) 4: begin (t 3 ) 5: begin (t 4 ) 6: write (b, t 3 )b: 66: write (b, t 3 ) 7: write (c, t 2 ) c: 7 7: write (c, t 2 ) 8: write (d, t 1 )d: 88: write (d, t 1 ) 9: commit (t 1 ) 1, 2, 3, 4, 5, 6, 7, 8, 9 10: flush (d)d: 8 11: write (d, t 3 )d: 1111: write (d, t 3 ) 12: begin (t 5 ) 13: write (a, t 5 )a: 1313: write (a, t 5 ) 14: commit (t 3 ) 11, 12, 13, 14 15: flush (d)d: 11 16: write (d, t 4 )d: 1616: write (d, t 4 ) 17: write (e, t 2 )e: 1717: write (e, t 2 ) 18: write (b, t 5 )b: 1818: write (b, t 5 ) 19: flush (b)b: 1816, 17, 18 20: commit (t 4 ) 20 21: write (f, t 5 )f: 2121: write (f, t 5 ) SYSTEM CRASH

50 50 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 First restart Sequence number: actionChange 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 [LogSeqNos] 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 SYSTEMCRASH Analysis pass: losers = {t 2, t 5 } Redo pass + :

51 51 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Second restart Sequence number: actionChange 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 [LogSeqNos] 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 RESTARTCOMPLETE: RESUMENORMAL OPERATION Analysis pass: losers = {t 2, t 5 } Redo pass + undo pass:

52 52 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 53 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 54 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Transaction rollback abort (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 55 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Sample Scenario crash t1t1 w(a) flush(a) t2t2 w(a) t3t3 t4t4 w(b) rollback

56 56 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Sample Scenario Data Structures Sequence number: actionChange 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 [LogSeqNos] 1: begin (t 1 ) 2: write (a, t 1 )a: 22: write (a, t 1 ) 3: commit (t 1 ) 1, 2, 3 4: begin (t 2 ) 5: write (a, t 2 )a: 55: write (a, t 2 ) 6: abort (t 2 ) 7: compensate(5) a: 7 7: compensate (a, t 2 ) 8: rollback (t 2 ) 4, 5, 7, 8 9: begin (t 3 ) 10: write (a, t 3 )a: 1010: write (a, t 3 ) 11: commit (t 3 ) 9, 10, 11 12: begin (t 4 ) 13: write (b, t 4 )b: 1313: write (b, t 4 ) 14: write (a, t 4 )a: 1414: write (a, t 4 ) 15: abort (t 4 ) 16: compensate(14) a: 1616: compensate (a, t 4 ) 17: flush (a) a: 1612, 13, 14, 16 SYSTEM CRASH

57 57 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Restart Sequence number: actionChange 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 [LogSeqNos] 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 RESTARTCOMPLETE: RESUMENORMAL OPERATION Analysis pass: losers = {t 4 } Redo pass + undo pass:

58 58 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Alternativen Der einfache redo-winners Algorithmus ist für praktische Zwecke meist zu ineffizient. Weitere grundsätzliche Ansätze in der Vorlesung Transaktionsverwaltung.

59 59 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Kapitel 4.3 Nicht-Transaktionale Zuverlässigkeit

60 60 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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) op 1 (0) op k-1 (0) op 1 (1) op i-1 (1) Kompensation Rekonstruktion 0-Konsistenz durch RAID usw. gesichert. Segmentspezifischer Sicherungspunkt Seiten

61 61 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Rolle des Backup-Verwalters Log- datei Transaktion 1Transaktion 2... Transaktion n Scheduler Recovery- Backup- Verwalter Historie 1Historie n Globale Historie aus read, write, allocate, unfix, commit, abort Sperren-Verwalter Puffer- Verwalter Daten- basis p3p3 p2p2 p 17 p 24 p 18 p 57 p 42 p8p8 p 67 p 19 p 33 p 81 p 46 p 25 p 54 p 66 p9p9 p 91 p 14 p 68 p 31 p 29 p 48 p 47 p1p1 p5p5 p 99 p 23 p 24 p 56 p 62 p 15 p 49 p 36 p 93 p7p7 Log- seiten d4d4 d 43 d 17 d 15 d2d2 d 58 d5d5 d9d9 d 26 d 69 d6d6 d 16 d 46 d 68 d 55 d 32 d 97 d 49 d 25 d 20 d 67 d 30 d 49 d 37 d 19 d 34 d 10 d 24 d 25 d 94 d 63 d 82 d 49 d 92 d 57 d8d8 Daten- seiten Transaktionsverwaltung fetch, flush read, write, allocate, unfix Segment- Verwalter unpin do(flush) restart entfällt Ignoriert (zunächst) Transaktionsgrenzen

62 62 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 63 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 64 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 P1 P2 P3 P4 P5... Pi j B1 B2 B3 B4 B5... Bj... Bk... Segment 4711 Schatten- seitentabelle aktuelle Seitentabelle Datei 15 Schattenspeicher-Verfahren (2) = Schattenbit j Anzeige der Modifikation einer Seite seit dem letzten Sicherungspunkt

65 65 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 P1 P2 P3 P4 P5... Pi j B1 B2 B3 B4 B5... Bj... Bk... Segment 4711 Schatten- seitentabelle aktuelle Seitentabelle Datei 15 Schattenspeicher-Verfahren (3) = Schattenbit j Bei einem Sicherungspunkt werden die Blöcke der Schattenseiten freigegeben, und die Einträge der aktuellen Seitentabelle werden in die Schattenseitentabelle kopiert.

66 66 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 P1 P2 P3 P4 P5... Pi j B1 B2 B3 B4 B5... Bj... Bk... Segment 4711 Schatten- seitentabelle aktuelle Seitentabelle Datei 15 Schattenspeicher-Verfahren (4) = Schattenbit 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 67 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 P1 P2 P3 P4 P5... Pi j j B1 B2 B3 B4 B5... Bj... Bk... Segment 4711 Schatten- seitentabelle aktuelle Seitentabelle Datei15 Schattenspeicher-Algorithmen (1) algorithmread_page inputSeitennummer P; output Nummer des Blocks mit der aktuellen Version von P; beginSei B der Eintrag zu P in der aktuellen Seitentabelle; return B; end;

68 68 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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;

69 69 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 P1 P2 P3 P4 P5... Pi j B1 B2 B3 B4 B5... Bj... Bk j Segment 4711 Schatten- seitentabelle aktuelle Seitentabelle Datei15 Schattenspeicher-Algorithmen (2) = Schattenbit j write_page(P1); x

70 70 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 algorithm delete_page input Nummer P der zu löschenden Seite begin if Schattenbit zu Seite P ist gesetzt then begin Sei 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; Schattenspeicher-Algorithmen (3)

71 71 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI k P1 P2 P3 P4 P5... Pi j B1 B2 B3 B4 B5... Bj... Bk... Segment 4711 Schatten- seitentabelle aktuelle Seitentabelle Datei15 Schattenspeicher-Algorithmen (3) = Schattenbit delete_page(P4); k x

72 72 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Schattenspeicher-Algorithmen (4) 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 73 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI k P1 P2 P3 P4 P5... Pi j B1 B2 B3 B4 B5... Bj... Bk... Segment 4711 Schatten- seitentabelle aktuelle Seitentabelle Datei15 = Schattenbit create_page; Schattenspeicher-Algorithmen (4) k

74 74 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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;

75 75 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 P1 P2 P3 P4 P5... Pi j B1 B2 B3 B4 B5... Bj... Bk... Segment 4711 Schatten- seitentabelle aktuelle Seitentabelle Datei15 = Schattenbit k 1. Gib die Blöcke der Schattenseiten frei FFF Setzen eines Sicherungspunktes (2)

76 76 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI k P1 P2 P3 P4 P5... Pi j B1 B2 B3 B4 B5... Bj... Bk... Segment 4711 Schatten- seitentabelle aktuelle Seitentabelle Datei15 = Schattenbit 2. Kopieren der Einträge der aktuellen Seitentabelle und Löschen der Schattenbits: Setzen eines Sicherungspunktes (2) k k

77 77 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 (2) (1) (0) checkpoint(S1) Atomares Sichern (1) Checkpoint segment S write_page(P1) Transaktion ResetToLastCheckpoint Sicherungspunkt: Zustand peripher zu sichern

78 78 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Atomares Sichern (1) algorithm CheckpointMitSicherungDurchRekonstruktion input Nummer S des Segments, das zurückgesetzt werden soll; begin Kopiere die Schatten- und aktuelle Seitentabelle; Kopiere die Blöcke, die im weiteren freigegeben werden; 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; Werfe Kopien weg; end;

79 79 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 (2) (1) (0) checkpoint(S1) Atomares Sichern (2) Checkpoint segment S write_page(P1) Transaktion ResetToLastCheckpoint Sicherungspunkt: Zustand peripher zu sichern

80 80 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Atomares Sichern (2) algorithm CheckpointMitSicherungDurchKompensation input Nummer S des Segments, das zurückgesetzt werden soll; begin Lege eine Log-Datei an; 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; 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 81 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 B 0 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;

82 82 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 83 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 84 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Twin-Block-Verfahren (1) Vereinfachtes Shadowing mit direkter Seitenabbildung. Jeder Seite P i werden zwei benachbarte Blöcke zugeordnet, d.h. die Übergang zwischen den beiden logischen Blöcken ist minimal. Beispiel: B8 B1 B2 B3 B4 B5 B6 B7 P1 P2 P3 P4

85 85 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 B j und B j+1 die Blöcke zu Seite P i. Auf Block B j wird ein Markierungsbit gespeichert: enthält B j die aktuelle Version der Seite, dann ist das Bit 1, ansonsten 0. B8 B1 B2 B3 B4 B5 B6 B7 P1 P2 P3 P4

86 86 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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 87 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Beispiel für das Twin-Block-Verfahren Transaktion T4712 fixiert Seite P i (auf B j + B j+1 ) zum Lesen T4712 EOT Platte (Da das Markierungsbit nicht gesetzt ist, enthält B j+1 die aktuelle Version der Seite P i ) read(P i ) commit Systempuffer = Markierungsbit gesetzt = Markierungsbit nicht gesetzt B j+1 Einlagern von B j und B j+1 P i0 P i1 BjBj

88 88 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 T4713 EOTread (P i )BOT speichere(P i ) Systempuffer = Markierungsbit gesetzt = Markierungsbit nicht gesetzt Beispiel für das Twin-Block-Verfahren Transaktion T4712 fixiert Seite P i (auf B j + B j+1 ) zum Lesen und Schreiben Platte B j+1 BjBj P i1 Einlagern von B j und B j+1 P i0 (Da das Markierungsbit nicht gesetzt ist, enthält B j+1 die aktuelle Version der Seite P i ) Modifizieren des aktuellen Zustands B j+1 Einbringen des neuen Zustands in Block B j und Setzen des Markierungsbits write(P i )

89 89 © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 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.


Herunterladen ppt "Universität Karlsruhe (TH) © 2009 Univ,Karlsruhe, IPD, Prof. LockemannDBI 4 Kapitel 4 Zuverlässigkeit und Recovery in der Segmentschicht."

Ähnliche Präsentationen


Google-Anzeigen