Kapitel 14: Recovery Oliver Vornberger

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.
1 ecash : das Geld auf der Festplatte Oliver Vornberger Fachbereich Mathematik/Informatik Universität Osnabrück Osnabrück
Rücksetzen Bisher betrachtetes Scheduling gewährleistet Isolation, d.h. Serialisierbarkeit, setzt jedoch voraus, dass Transaktionen abgebrochen und rückgesetzt.
Transaktionsverwaltung
B-Bäume.
© A. Kemper / A. Eickler1 Fehlerbehandlung (Recovery) 1.Lokaler Fehler in einer noch nicht festgeschriebenen (committed) Transaktion Wirkung muss zurückgesetzt.
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.
Objektrelationales Mapping mit JPA Working with Persistent Objects Jonas Bandi Simon Martinelli.
1 Fehlerbehandlung (Recovery) 1.Lokaler Fehler in einer noch nicht festgeschriebenen (committed) Transaktion Wirkung muss zurückgesetzt werden R1-Recovery.
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.
Datenbanksysteme für FÜ SS 2000 Seite Worzyk FH Anhalt Transaktionen und Parallelverarbeitung Eigenschaften von Transaktionen Konsistenz Isolation.
Kapitel 13: Mehrbenutzersynchronisation
Fachbereich Mathematik/Informatik Universität Osnabrück
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.
Einige Begriffe zum Anfang.... Transaktionsprozedur: Folge primitiver Operationen als Einheit der Konsistenz und der Robustheit. Transaktion (TA): Ausführung.
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:
Modellierung von Transaktionen Zur Formalisierung der ACID-Garantien muss Verhalten von Transaktionen modelliert werden. Folge aus der Forderung nach lokaler.
Synchronisation paralleler Transaktionen AIFB SS Konzept der Transaktion 4.2 Konzept der Transaktion (1/4) Eine Transaktion ist ein in sich geschlossener,
Datensicherung, ein wichtiger Punkt in der EDV
Backup und Recovery sehr großer Datenbanken
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
Vorlesung Datenbanksysteme vom Physische Datenorganisation
Festschreibe-Protokoll (1) Globales Zwei-Phasen-Festschreibe-Protokoll (2- Phasen-Commit, 2PC): Phase 1: –Koordinator benachrichtigt Ressourcen, dass Commit.
Transaktion Huang Zhenhao FU Shuai.
Datenbanksysteme Technische Grundlagen Transaktions-Konzept, Mehrbenutzer-Synchronisation, Fehlerbehandlung Prof. Dr. Manfred Gruber FH München.
ComMusic-Programm Ehrungsanträge
Concurrent Versions System
Vorlesung Datenbanksysteme WS 2.0 Christoph Koch (Subject: DBVO:...
ADAT©2004,2006 Dipl. - Ing. Walter SabinSeite: 48 Version 1.0a Recovery Wiederherstellung eines konsistenten Datenbankzustandes nach Fehlersituationen.
Lokales 2-Phasen-Festschreibe- Protokoll Segment-Verwalter führt commit(T i ) in zwei Phasen aus: Phase 1: Sicherstellung der Wiederholbarkeit. –Für jedes.
Transaktionen Dr. Heidrun Bethge Datenbanken II.
8 Erzeugen und Verwalten von Tabellen Ziele Kennenlernen der wichtigsten Datenbankobjekte Anlegen von Tabellen Datentypen zur Definition von Spalten.
Fehlerbehandlung (Recovery)
Transaktionsverwaltung
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.
Persistenz: Objekt-Lebensdauer In RDBMS wird Lebensdauer von Werten durch ihren Typ festgelegt: Instanzen von Relationstypen sind persistent, alle anderen.
Sicherung gegen Medienverlust (1) Medienverlust = Verlust der Datenbasis und/oder des Protokolls. Vorbeugung durch periodische Sicherung von Datenbasis.
Synchronisation mit Zeitmarken (1) Zeitmarken-Synchronisation = einfaches, aber ineffizientes Verfahren zur Gewinnung konfliktserialisierbarer Schedules.
Recovery    AIFB SS (1/6) Durchführung der Recovery-Maßnahmen(1/6) Transaktions-Fehler (TF) T1 T2 T3 Zeitt Transaktion T2 wird vom.
unpin(a,b,c) flush(a,b,c)
Vs Verteilte Transaktionen Situation:Fragmentierung: Ein Datenbestand ist über mehrere Stationen verteilt (z.B. verteilte Datenbank, verteiltes Dateisystem,...)
Transaktionsverwaltung Beispiel einer typischen Transaktion in einer Bankanwendung: 1.Lese den Kontostand von A in die Variable a: read(A,a); 2.Reduziere.
Seminar zur Administration von Datenbankmanagementsystemen 8. 6
Prof. Dr. T. Kudraß1 Transaktionsmanagement - Einführung.
Datenbanktechnik 1 Datenbanktechnik II Kapitel 3.0 bis 4.0.
Transaktionsverwaltung Beispiel einer typischen Transaktion in einer Bankanwendung: 1.Lese den Kontostand von A in die Variable a: read(A,a); 2.Reduziere.
Übung – Recovery Manager Undo Redo Algorithmus
Vorlesung #7 Fehlerbehandlung
Transaktionsabbruch, System Crash, Media Failure
Vorlesung #7 Fehlerbehandlung
Vorlesung #7 Fehlerbehandlung
Vorlesung #10 Fehlerbehandlung
Redo/Undo Ersetzungsstrategie: LRU
 Präsentation transkript:

Kapitel 14: Recovery Oliver Vornberger Fachbereich Mathematik/Informatik Universität Osnabrück 49069 Osnabrück oliver@uos.de

Fehlerklassen lokaler Fehler in einer noch nicht festgeschriebenen Transaktion Fehler mit Hauptspeicherverlust Fehler mit Hintergrundspeicherverlust

Lokaler Fehler in einer Transaktion Grund: Fehler im Anwendungsprogramm Abort systemgesteuerter Abbruch einer Transaktion Behebung: Änderungen der abgebrochenen Transaktion rückgängig machen (lokales undo) Frequenz: minütlich Aufwand: Millisekunden

Fehler mit Hauptspeicherverlust Grund: Stromausfall, Hardwareausfall, Betriebssystemproblem Behebung: alle durch nicht abgeschlossene Transaktionen schon in die materialisierte Datenbasis eingebrachten Änderungen müssen rückgängig gemacht werden (globales undo) alle noch nicht in die materialisierte Datenbasis eingebrachten Änderungen durch abgeschlossene Transaktionen müssen nachvollzogen werden (globales redo). Frequenz: täglich Aufwand: Minuten

Fehler mit Hintergrundspeicherverlust Grund: head crash Feuer/Erdbeben Betriebssystemproblem Behebung: Archivkopie + Logarchiv Frequenz: jährlich Aufwand: Stunden

Lokales Zurücksetzen einer Transaktion Eine Historie heißt rücksetzbar, falls immer die schreibende Transaktion Tj vor der lesenden Transaktion Ti ihr commit ausführt. Eine Transaktion darf erst dann ihr commit durchführen, wenn alle Transaktionen, von denen sie gelesen hat, beendet sind. Falls nicht: Schreibende Transaktion könnte nicht zurückgesetzt werden, da die lesende dann einen nicht existenten Wert gelesen hätte.

Speicherhierarchie A' D C' C B P A Einlagerung Auslagerung Hintergrundspeicher DBMS-Puffer Für die Dauer eines Zugriffs wird die Seite im Puffer fixiert. Werden Daten geändert, so wird die Seite als dirty markiert.

Ersetzen von Pufferseiten ¬steal: Die Ersetzung von Seiten, die von einer noch aktiven Transaktion modifiziert wurden, ist ausgeschlossen. steal: Jede nicht fixierte Seite darf ausgelagert werden.

Zurückschreiben von Pufferseiten force: Beim commit einer Transaktion werden alle von ihr modifizierten Seiten in die materialisierte Datenbasis zurückkopiert. ¬force: Modifizierte Seiten werden nicht unmittelbar nach einem commit, sondern ggf. auch später, in die materialisierte Datenbasis zurückkopiert.

Kombinationsmöglichkeiten force ¬force ¬steal steal Kein Redo kein Undo Redo kein Undo Kein Redo Undo Redo Undo

Einbringstrategie update-in-place Jeder ausgelagerten Seite P entspricht eine Seite P im Hintergrundspeicher Twin-Block-Verfahren Jeder ausgelagerten Seite P werden zwei Seiten P0 und P1 im Hintergrundspeicher zugeordnet mit dem letzten und vorletzten Zustand. Zurückschreiben erfolgt jeweils auf den vorletzten Zustand.

Systemkonfiguration steal ¬force update-in-place Kleine Sperrgranulate Seiten können Änderungen von abgeschlossenen und nicht abgeschlossenen Transaktionen enthalten

Struktur der Log-Einträge Redo-Information Undo-Information LSN (Log Sequence Number) Transaktionskennung TA PageID PrevLSN

Beispiel einer Log-Datei T1 T2 Log [LSN, TA, PagelD, Redo, Undo, PrevLSN] BOT [#1, T1, BOT, 0] r(A, a1) BOT [#2, T2, BOT, 0] r(C, c2) a1 := a1 - 50 w(A, a1) [#3, T1, PA, A-=50, A+=50, #1] c2 := c2 + 100 w(C, c2) [#4, T2, PC, C+=100, C-=100, #2] r(B, b1) b1 := b1 + 50 w(B, b1) [#5, T1, PB, B+=50, B-=50, #3] commit [#6, T1, commit, #5] r(A, a2) a2 := a2 - 100 w(A, a2) [#7, T2, PA, A-=100, A+=100, #4] commit [#8, T2, commit, #7]

Logische versus physische Protokollierung Logische Protokollierung: Notiere Undo-Operation, um vorherigen Zustand zu erzeugen Notiere Redo-Operation, um Nachfolgezustand zu erzeugen Physische Protokollierung: Notiere Before-Image statt Undo-Operation Notiere After-Image statt Redo-Operation Before-Image = Undo-Code angewendet auf After-Image After-Image = Redo-Code angewendet auf Before-Image

Before-Image versus After-Image Beim Anlegen eines Log-Eintrages wird die neu generierte LSN in einen reservierten Bereich der Seite geschrieben. Wenn die LSN der Seite einen kleineren Wert als die LSN des Log-Eintrags enthält, handelt es sich um das Before-Image. Ist die LSN der Seite größer oder gleich der LSN des Log-Eintrags, dann wurde bereits das After-Image auf den Hintergrundspeicher propagiert.

Speicherhierarchie zur Datensicherung

WAL-Prinzip (Write Ahead) Bevor eine Transaktion festgeschrieben (committed) wird, müssen alle zu ihr gehörenden Log-Einträge geschrieben werden. (wegen Redo) Bevor eine modifizierte Seite ausgelagert werden darf, müssen alle Log-Einträge, die zu dieser Seite gehören, in die Log-Datei geschrieben werden. (wegen undo)

Wiederanlauf nach einem Fehler Transaktion T1 ist ein Winner und verlangt ein Redo. Transaktion T2 ist ein Loser und verlangt ein Undo. Analyse: Winner und Loser ermitteln (commit !) Log-Datei vorwärts: Redo, falls erforderlich (LSN !) Log-Datei rückwärts: Undo

Sicherungspunkte

Recovery-Arten

Sicherung der Datenbank EXEC sp_addumpdevice 'disk', 'unidump', 'c:\dump\unidump.dat'‚ backup database uni to unidump restore database uni from unidump

Sicherung der Log-Datei EXEC sp_addumpdevice 'disk', 'unilog', 'c:\dump\unilog.dat' backup log uni to unilog from unilog restore log uni from unilog