Übung – Recovery Manager Undo Redo Algorithmus

Slides:



Advertisements
Ähnliche Präsentationen
Kapitel 15 Verteilte Datenbanken
Advertisements

Transaktionsverwaltung Beispiel einer typischen Transaktion in einer Bankanwendung: 1.Lese den Kontostand von A in die Variable a: read(A,a); 2.Reduziere.
Eine dynamische Menge, die diese Operationen unterstützt,
Rücksetzen Bisher betrachtetes Scheduling gewährleistet Isolation, d.h. Serialisierbarkeit, setzt jedoch voraus, dass Transaktionen abgebrochen und rückgesetzt.
C. Mohan, Bruce Lindsay and R. Obermarck
© A. Kemper / A. Eickler1 Fehlerbehandlung (Recovery) 1.Lokaler Fehler in einer noch nicht festgeschriebenen (committed) Transaktion Wirkung muss zurückgesetzt.
Übung 6.6Schranken 1.Angenommen, Ihr Algorithmus habe einen Aufwand von g(n) = 5n 3 + n für alle n a)Geben sie eine obere Schranke O(g(n)) an. b)Beweisen.
1 Fehlerbehandlung (Recovery) 1.Lokaler Fehler in einer noch nicht festgeschriebenen (committed) Transaktion Wirkung muss zurückgesetzt werden R1-Recovery.
Transaktionsverwaltung Beispiel einer typischen Transaktion in einer Bankanwendung: 1.Lese den Kontostand von A in die Variable a: read(A,a); 2.Reduziere.
Parser generieren Yet Another Compiler – Compiler YACC.
1 Fehlerbehandlung (Recovery) 1.Lokaler Fehler in einer noch nicht festgeschriebenen (committed) Transaktion Wirkung muss zurückgesetzt werden R1-Recovery.
Vorlesung Informatik 2 Algorithmen und Datenstrukturen (27 – Kürzeste Wege) Prof. Th. Ottmann.
Gottfried Vossen 5. Auflage 2008 Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme Kapitel 22: Grundlagen der Crash Recovery.
Transaktionen in verteilten Datenbanken
Prof. Dr. T. Kudraß1 Recovery. Prof. Dr. T. Kudraß2 Fehlerarten: Transaktionsfehler Transaktionsfehler –Freiwilliger Transaktionsfehler durch eine ROLLBACK-Anweisung.
DbjFileManager Paul Fruntzek Michael Stanek. Überblick Unterste Ebene im Schichtenmodell Schnittstelle zum BS (Low-Level) Aufgabenbereich: Persistente.
Datenbanksysteme für FÜ SS 2000 Seite Worzyk FH Anhalt Transaktionen und Parallelverarbeitung Eigenschaften von Transaktionen Konsistenz Isolation.
ExKurs EinfG 1/4 Dr. Barbara Hoffmann LiteraturKompetenz Objekte einfügen: Diagramme und Grafiken Mit dem elektronischen Schreiben ist es Ihnen.
Minimum Spanning Tree: MST
Kapitel 14: Recovery Oliver Vornberger
1 Kapitel 12: Transaktionsverwaltung Oliver Vornberger Fachbereich Mathematik/Informatik Universität Osnabrück Osnabrück
1 Kapitel 12: Transaktionsverwaltung. 2 Transaktion Bündelung mehrerer Datenbankoperationen Mehrbenutzersynchronisation Recovery.
Zuverlässigkeit und Recovery in der Segmentschicht
Universität Karlsruhe (TH) © 2008 Univ,Karlsruhe, IPD, Prof. LockemannDBI 7 Kapitel 7 Zugriffsschicht: Zuverlässigkeit.
Recovery AIFB SS Recovery 5.1 Fehler im Datenbankbetrieb(1/10) (1)Transaktionsfehler (TF) (2)Systemfehler (SF) (3)Speicherfehler (SpF) Fehlerfallen.
RelationentheorieObjektorientierte Datenbanken AIFB SS Das ODMG-Objektmodell vs. relationales Modell (1/9) ODMG-Objektmodell Literal_type Atomic_literal.
Transaktion 1Transaktion 2... Transaktion n Synchronisation durch Scheduler Datenbasis-Verwalter lokaler Schedule 1lokaler Schedule n konfliktserialisierbarer.
Recovery AIFB SS Einbringstrategie der Pufferverwaltung(1/4) Die bestimmt, wann geänderte Seiten in die Datenbank eingebracht werden. Sie.
Recovery AIFB SS (1/8) Sicherungspunkte (Checkpoints) (1/8) (1) Transaktions-Orientierte Sicherungspunkte Transaction-Oriented Checkpoint.
Ausführungsmodell Zustandsübergang einer Transaktion aus Nutzersicht:
Implementierung von S2PL (1) Scheduler als Verwalter von Sperren auf Datenelementen sowie Warteschlangen für Sperren (Sperren-Verwalter). Transaktion 1Transaktion.
Modellierung von Transaktionen Zur Formalisierung der ACID-Garantien muss Verhalten von Transaktionen modelliert werden. Folge aus der Forderung nach lokaler.
Effiziente Algorithmen
Information und Kommunikation
Institut für Wirtschaftsinformatik – Software Engineering, JKU Linz 1 Algorithmen und Datenstrukturen SS 2005 Mag.Th. Hilpold u. Dr. A.Stritzinger Institut.
WS 2012/13 Datenbanksysteme Mi 15:15 – 16:45 R Vorlesung #11 Transaktionsverwaltung.
WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 Vorlesung #6 Fehlerbehandlung.
WS 2011/12 Datenbanksysteme Mi 15:15 – 16:45 R Vorlesung #10 Transaktionsverwaltung.
Vorlesung #9 Fehlerbehandlung
Festschreibe-Protokoll (1) Globales Zwei-Phasen-Festschreibe-Protokoll (2- Phasen-Commit, 2PC): Phase 1: –Koordinator benachrichtigt Ressourcen, dass Commit.
Thread Synchronisation in JAVA
Datenbanksysteme Technische Grundlagen Transaktions-Konzept, Mehrbenutzer-Synchronisation, Fehlerbehandlung Prof. Dr. Manfred Gruber FH München.
ADAT©2004,2006 Dipl. - Ing. Walter SabinSeite: 48 Version 1.0a Recovery Wiederherstellung eines konsistenten Datenbankzustandes nach Fehlersituationen.
ADAT©2004 Dipl. - Ing. Walter SabinSeite: 19 Version 1.0a Programme - Zusatzsoftware Oracle: –Forms –Reports –Designer –Jdeveloper –APEX (Application Express)
Lokales 2-Phasen-Festschreibe- Protokoll Segment-Verwalter führt commit(T i ) in zwei Phasen aus: Phase 1: Sicherstellung der Wiederholbarkeit. –Für jedes.
Übung: Transaktionale Systeme
Fehlerbehandlung (Recovery)
Wiederanlauf nach Systemzusammenbruch Aufgabe: Bei Noforce-Strategie Wiederholung aller noch nicht in die Datenbasis eingebrachten Änderungen bereits abgeschlossener.
Recovery    AIFB SS Grundlegende Annamen(1/2) Um den Erfolg der der Recovery-Maßnahmen zu gewährleisten, werden folgende Annahmen.
Puffer-Verwalter (1) Aufgabe: Performanzkontrolle bzgl. Hauptspeichernutzung. Puffer-Verwalter versucht, Plattenzugriffe durch Vorhalten von häufig benötigten.
Synchronisation paralleler Transaktionen  AIFB SS Serialisierbarkeitsprinzip 4.3 Serialisierbarkeitsprinzip (2/13) Im folgenden wird ein vereinfachtes.
Sicherung gegen Medienverlust (1) Medienverlust = Verlust der Datenbasis und/oder des Protokolls. Vorbeugung durch periodische Sicherung von Datenbasis.
Recovery    AIFB SS (1/6) Durchführung der Recovery-Maßnahmen(1/6) Transaktions-Fehler (TF) T1 T2 T3 Zeitt Transaktion T2 wird vom.
Prof. K. Gremminger Folie 1 Vorlesung Datenbanksysteme SS 2002 Abhängigkeiten zwischen Transaktionen (Fehlerklassen) u Lost-Update-Problem u Dirty Read.
Transaktionsverwaltung Beispiel einer typischen Transaktion in einer Bankanwendung: 1.Lese den Kontostand von A in die Variable a: read(A,a); 2.Reduziere.
WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R Vorlesung #12 Mehrbenutzersynchronisation.
Prof. Dr. T. Kudraß1 Transaktionsmanagement - Einführung.
Transaktionsverwaltung Beispiel einer typischen Transaktion in einer Bankanwendung: 1.Lese den Kontostand von A in die Variable a: read(A,a); 2.Reduziere.
J. Nürnberger2007 / 081 Tabellenkalkulation (3) Arbeiten mit Formeln am Beispiel von OpenOffice.org Calc.
Übung Datenbanksysteme I Besprechung
Vorlesung #7 Fehlerbehandlung
WS 2001/2002 Mehrbenutzerzugriff auf GIS-Daten
Transaktionsabbruch, System Crash, Media Failure
Vorlesung #7 Fehlerbehandlung
Vorlesung #7 Fehlerbehandlung
"MANUELLE" PHYSICAL STANDBY SYSTEME FÜR STANDARD EDITION UNTER RAC.
Vorlesung #10 Fehlerbehandlung
1. Die rekursive Datenstruktur Liste 1.3 Rekursive Funktionen
3. Die Datenstruktur Graph 3.3 Durchlaufen von Graphen
Redo/Undo Ersetzungsstrategie: LRU
 Präsentation transkript:

Übung – Recovery Manager Undo Redo Algorithmus Vorlesung Datenbanksysteme 2 Übung – Recovery Manager Undo Redo Algorithmus

Aufgabe - Recovery Das Datenbanksystem habe für dieses Schedule zwei LRU-Cache-Slots reserviert. Der Recovery Manager unterstützt Undo/Redo. Beschreiben Sie die Vorgänge bei der Ausführung des Schedules, indem Sie eine Tabelle vom Typ (1) verwenden. Beschreiben Sie anschließend den Restart-Vorgang. Benutzen Sie hierzu eine Restart-Tabelle vom Typ (2). Kennzeichnen Sie in den Tabellen einen dirty Cache-Slot durch ein * und einen unbestätigten Wert in der Datenbasis durch Einklammern z.B.(<WERT>). T1 T2 T3   READ(D) D:=D+15 WRITE(D) A:=15 WRITE(A) READ(C) C:=2*C WRITE(C) READ(B) B:=B+A WRITE(B) COMMIT READ(A) A:=A+15 B:=B*C READ(E) E:=E+B WRITE(E)  SYSTEMCRASH

Ausführung - Tabelle vom Typ (1) Tabelle Typ (1) Operation Logeintrag Slot 1 Slot 2 Datenbasis Listen   X V A B C D E Aktiv Commit Abort (Init.) [T0,A,5],[T0,B,10], [T0,C,1],[T0,D,0], [T0,E,1] - 5 10 1 --- T0 READ3(D) WRITE3(D) WRITE1(A) READ2(C) WRITE2(C) READ1(B) WRITE1(B) COMMIT1 READ3(A) WRITE3(A) READ2(B) WRITE2(B) COMMIT2 READ3(B) READ3(E) WRITE3(E) Stand beim Crash

Ausführung - Tabelle vom Typ (2) Listen: Aktiv={T3}, Commit={T0,T1,T2}, Abort={} Tabelle Typ (2) Logeintrag Slot 1 Slot 2 Datenbasis Listen   X V A B C D E undone redone Vor Recovery - 30 10 2 15 1 --- [T3,E,51] [T2,B,50] [T3,A,30] [T1,B,25] [T2,C,2] [T1,A,15] [T3,D,15] Nach Flush

Undo/Redo Algorithmus RM-WRITE(ti,x,v): Füge Ti zur Aktiv-Liste hinzu, falls sie noch nicht dort ist. Wenn x noch nicht im Cache ist, fetche x. Füge [Ti,x,v] in die Log-Datei ein. Schreibe v in den Cache Slot, der von x belegt ist. Bestätige (Acknowledge) dem Scheduler die Verarbeitung des RM-WRITE. Anmerkung zu Schritt 4: Hier und in allen weiteren Fällen gilt, dass, wenn ein Wert in einen Cache Slot geschrieben wird, das dirty-bit gesetzt wird.

Undo/Redo Algorithmus RM-READ(Ti,x): Wenn x nicht im Cache ist, fetche x. Gib den Wert von x an den Scheduler. RM-COMMIT(Ti): Füge Ti der Commit-Liste hinzu. Bestätige dem Scheduler das Commitment von Ti. Lösche Ti aus der Aktiv-Liste.

Undo/Redo Algorithmus RM-ABORT(Ti): Für jedes Datenobjekt x, das durch Ti verändert wurde Wenn x nicht im Cache ist, belege einen Slot für x. Schreibe das Before-Image von x, in Bezug auf Ti , in den Slot von x. Anmerkung: Der Wert ist jetzt nur im Cache wiederhergestellt, Der CM schreibt diesen Wert erst beim Flushen in die stable Database. Füge Ti der Abort-Liste hinzu. Bestätige dem Scheduler die Durchführung des RM-ABORT. Lösche Ti aus der Aktiv-Liste.

Undo/Redo Algorithmus RESTART: Lösche alle Cache Slots. Bei einem Systemfehler ist der Hauptspeicher betroffen, Werten im Cache kann also nicht vertraut werden. Setzte redone = {} & undone = {} Dies sind lokale Variablen der Restart-Prozedur, sie halten fest, für welche Datenobjekte der letzte committed Wert wiederhergestellt wurde (durch Undo oder Redo).

Undo/Redo Algorithmus Beginne mit dem letzten Eintrag im Log und gehe rückwärts bis zum Anfang des Log. Wiederhole die folgenden Schritte bis entweder redone  undone = {alle Datenobjekte} oder es keine Einträge mehr im Log gibt. Für alle Einträge [Ti,x,v] im Log, falls x  redone  undone, dann Falls x nicht im Cache ist, fetche x. wenn Ti in der Commit-Liste ist, kopiere v in den Slot von x und setzte redone = redone  { x }. - Der letzte committed Wert von x ist jetzt nur im Cache wiederhergestellt. sonst (Ti in Abort- oder Aktiv-Liste aber nicht in der Commit-Liste) kopiere das Before-Image von x bezüglich Ti (im log), in den Slot von x und setzte undone = undone  { x }.

Undo/Redo Algorithmus Entferne jede Transaktion Ti die sowohl in der Commit-Liste als auch in der Aktiv-Liste ist, aus der Aktiv-Liste. Bestätige dem Scheduler die Durchführung des RESTART. (Der Scheduler wartet, bis der Restart beendet ist)

Ausführung - Tabelle vom Typ (1) Tabelle Typ (1) Operation Logeintrag Slot 1 Slot 2 Datenbasis Listen   X V A B C D E Aktiv Commit Abort (Init.) [T0,A,5],[T0,B,10], [T0,C,1],[T0,D,0], [T0,E,1] - 5 10 1 --- T0 READ3(D) WRITE3(D) [T3,D,15] D* 15 T3 WRITE1(A) [T1,A,15] A* T3,T1 READ2(C) <15> WRITE2(C) [T2,C,2] C* 2 T3,T1,T2 READ1(B) WRITE1(B) [T1,B,25] B* 25 COMMIT1 T3,T2 T0,T1 READ3(A) <2> WRITE3(A) [T3,A,30] 30 READ2(B) WRITE2(B) [T2,B,50] 50 COMMIT2 T0,T1,T2 READ3(B) READ3(E) <30> WRITE3(E) [T3,E,51] E* 51 Stand beim Crash

Ausführung - Tabelle vom Typ (2) Listen: Aktiv={T3}, Commit={T0,T1,T2}, Abort={} Tabelle Typ (2)   Logeintrag Slot 1 Slot 2 Datenbasis Listen Kommentar X V A B C D E undone redone Vor Recovery - 30 10 2 15 1 --- [T3,E,51] E* Wert von [T0,E,1] [T2,B,50] B* 50 [T3,A,30] A* E,A Wert von [T1,A,15] [T1,B,25] [T2,C,2] C* B,C Wert von [T2,C,2] [T1,A,15] [T3,D,15] D* E,A,D Wert von [T0,D,0] Nach Flush