Kapitel 9 – Paralleler Zugriff auf DB

Seite 1 von 8
www.jurijs-skripte.de.vu
DBMS - Kapitel 9
Kapitel 9 – Paralleler Zugriff auf DB
FEHLERFÄLLE BEI UNKONTROLLIERTER ARBEIT
Verloren gegangene Änderung
- Da beide Anwendungen abwechselnd lesen und ändern, wird die Änderung der ersten
Anwendung von der zweiten Anwendung nicht wahrgenommen und überschrieben
Inkonsistente Sicht/nicht wiederholbares Lesen
- Zwei Anwendungen lesen gleichzeitig denselben Wert und eine der beiden Anwendungen ändert
ihn danach. Die andere Anwendung hat folglich einen falschen Wert im Hauptspeicher.
Inkonsistente DB
- Da manche Operationen nicht kommutativ sind, können durch unterschiedliche Reihenfolgen
(aber gleichen Operationen) 2 Werte, die vorher gleich werden, ungleich werden.
Phantomproblem
- Werden zwischen 2 Anfragen Elemente in die Datenbank eingefügt, kann das Ergebnis der 2.
Anfrage Elemente anzeigen, die es bei der 1. Anfrage noch nicht gab (auch wenn 2. Anfrage
möglicherweise sogar die Restriktivere ist)
- Definition Transaktion: Eine Menge semantisch zusammengehörender Operationen einer
Anwendung. Diese Menge belässt die DB in einem konsistenten Zustand. Dabei muss eine
Transaktion nicht zwangsläufig Werte ändern
TRANSAKTIONEN IN SQL
- BEGIN_OF_TRANSACTION (BOT)
- END_OF_TRANSACTION/COMMIT (EOT)
ACID-KRITERIUM
- In einer DB muss jede Transaktion diesem Kriterium genügen
Atomicity (Unteilbarkeit)
- Transaktionen müssen entweder ganz oder gar nicht durchgeführt werden
Alles-oder-Nichts Prinzip
- Im Fall von Fehlern müssen die bisher Durchgeführten Änderungen der Transaktion komplett
rückgängig gemacht werden
Consistency (Konsistenz)
- Bis zum Transaktionsende müssen alle durch die Transaktion herbeigerufenen inkonsistenten
Zustände auch wieder beseitigt werden
„Weiches Kriterium“: Viele Inkonsistenzen kann die DB nicht entdecken (z.B. Tippfehler)
Isolation
- Eine Transaktion muss so ablaufen, als wäre sie die einzige im System.
- Parallele Transaktionen dürfen sich nicht beeinflussen
Parallelität ist nur dann erlaubt, wenn sie die DB in denselben Zustand versetzt, in dem sie auch
ohne Parallelität sein würde
Durability (Dauerhaftigkeit)
- Änderungen von abgeschlossenen Transaktionen müssen alle späteren Fehler überleben.
- Definition Serialisierbarkeit: Liegt vor, wenn es möglich ist, zu den parallel ausgeführten
Operationen vieler Transaktionen mindestens eine Möglichkeit zu finden, alle Transaktionen
nacheinander auszuführen, wobei immer noch derselbe DB-Endzustand erzeugt und dieselben
Ausgabedaten produziert werden
Die durch die einzelnen Transaktionen vorgegebene Reihenfolge der Operationen muss aber
stets erhalten bleiben
- Eine Menge von Transaktionen ist für das DB dann korrekt synchronisiert, wenn sie serialisierbar
sind
- Definition Schedule bzw. Historie: Eine beliebige Anordnung der Teiloperationen einer Menge von
gegebenen Transaktionen. Die durch die einzelnen Transaktionen vorgegebenen Reihenfolgen der
Teiloperationen muss aber gewahrt werden
Zusammenfasser: Jurij Weinblat, SoSe 2010. Alle Angaben ohne Gewähr. Quelle: Internetrecherche,
Vorlesungsunterlagen von Prof. Dr. Rainer Unland, Mitschriften (Universität Duisburg-Essen)
Seite 2 von 8
www.jurijs-skripte.de.vu
DBMS - Kapitel 9
Idee: Lässt man Parallelität zu, können beliebige Schedule mit der gleichen
Wahrscheinlichkeit entstehen
- Definition Serielle Schedule: Hierbei werden zuerst alle Teiloperationen einer Transaktion
ausgeführt, dann der nächsten etc.
- Definition Serialisierbarer Schedule: Erzeugen denselben DB-Zustand und dieselben Ausgaben wie
irgendein serieller Schedule
Praxisfern, da meist in Echtzeit neue Transaktionen hinzukommen und andere erfolgreich
abgearbeitet werden
- Definition Scheduler: Diese Komponente bildet ankommende serielle Teiloperationen
(Ausgangsschedule) auf serialisierbare Schedule (Ergebnisschedule) ab
Hierbei muss in Echtzeit entschieden werden, ob die Teiloperation ausgeführt werden darf,
verzögert wird oder zurückgewiesen wird (und dessen Transaktion rückgängig gemacht wird)
Muss mit einem n(p)-vollständigen Problem umgehen können, ermöglicht also nicht immer
optimale Lösungen
FOLGENDE KRITERIEN BESTIMMEN DIE QUALITÄT DES SCHEDULERS
Durchlässigkeit
- Inwieweit ist der Scheduler in der Lage, alle serielle & serialisierbaren Schedules tatsächlich „live“
durchzulassen → Je weniger Eingriffe, desto höher die Parallelität
Steuerungsvermögen
- Inwieweit ist der Scheduler in der Lage, nicht serialisierbare Ausgangsschedules sofort in
serialisierbare Schedules umzuwandeln, ohne sie erst später zurücksetzen zu müssen
Steht im Konflikt mit der Durchlässigkeit (lässt sich an)
Aufwand
- Wie viel direkten und indirekten Aufwand (z.B. Transaktionszurücksetzung) entsteht durch die
Arbeit des Schedulers
Definition: Konflikt
- Wenn zwei Teiloperationen unterschiedlicher Transaktionen auf dasselbe Objekt zugreifen, wobei
mind. eine davon dies schreibend tut
Definition: Abhängigkeit
- Die Reihenfolge zweier im Konflikt stehender Operationen definiert eine Abhängigkeit zwischen
diesen beteiligten Transaktionen
Eine Schedule ist nicht serialisierbar, falls zwei Operationen eine wechselseitige Abhängigkeit
haben.
Definition: Abhängigkeitsgraph
- Jede im Schedule vorkommende Transaktion wird als Knoten dargestellt
- Jede Abhängigkeit zwischen den Transaktionen wird als gerichtete Kante dargestellt, wobei die
Kante bei der Transaktion anfängt, die zuerst im Schedule steht und auf die Transaktion zeigt, die
als zweites im Schedule steht
Definition Serialisierbarkeitskriterium: Hat der Abhängigkeitsgraph keinen Zyklus, ist die Schedule
serialisierbar
Kein hinreichendes Kriterium, da es wirkungslose Transaktionen außeracht lässt (Enthalten
Teiloperationen, die einen Wert schreiben, ohne ihn vorher gelesen zu haben → Kann man
folgenlos weglassen, da ihr Wert später „blind“ überschieben wird)
In diesem Fall kann eine Schedule serialisierbar sein, auch wenn das Kriterium nicht erfüllt ist
KLASSIFIKATION VON SYNCHRONISATIONSVERFAHREN
Optimistische Vorgehensweise
Pessimistische/Präventive Vorgehensweise
- Greifen ein, wenn Serialisierbarkeit schon
- Greift zusätzlich auch dann, wenn Konsistenzverletzt wurde →Durch Zurücksetzen
verletzung auftreten könnte
Feststellung durch Graph
- Bekannte Vertreter und in DBMS
- Synchronisieren Transaktionen nur durch ihr
vorherrschend: Sperrverfahren
zurücksetzen
Gut, wenn es viele Konflikte gibt
Gut, wenn es kaum Konflikte gibt
Zusammenfasser: Jurij Weinblat, SoSe 2010. Alle Angaben ohne Gewähr. Quelle: Internetrecherche,
Vorlesungsunterlagen von Prof. Dr. Rainer Unland, Mitschriften (Universität Duisburg-Essen)
Seite 3 von 8
www.jurijs-skripte.de.vu
DBMS - Kapitel 9
- Die optimistischen Verfahren haben ein sehr schlechtes Steuerungsvermögen, hat aber einen
akzeptablen Aufwand
SPERRVERFAHREN
- Idee: Alle, von einer Transaktion benötigten, Objekte werden gesperrt. Somit werden Konflikte
vorgebeugt, da alle anderen Transaktionen, die diese Objekte auch nutzen wollen, in einen
Wartezustand versetzt werden.
- Im Hauptspeicher gibt es eine Sperrtabelle folgenden Aufbaus → Objekt; Sperre (kann ziemlich
groß, setzen und Prüfen bedeutet Aufwand!)
Der Scheduler muss stets klären
- ob das gesperrte Objekt der aktuellen Transaktion gehört
- Was für Sperrarten es gibt und was für Einheiten sperrbar sind → Sperrmodi
- Wann und für wie lange Sperren vergeben werden → Sperrprotokoll
- Was mit bereits gesperrten Objekten passiert → Kollisionsstrategie
Sperrmodi
- Dabei stehen die Schreiboperationen im Mittelpunkt, da sie die Konflikte verursachen, während
Leseoperationen miteinander kompatibel sind
- Definition Lesesperre/Shared Lock: Erlaubt anderen Transaktionen das Setzen von Sperren,
Schreibsperren sind hingegen verboten
- Definition Schreibsperre/exclusive Lock: Der „Setzer“ darf schreiben & lesen, die anderen nichts
Ein Objekt darf mehrere Lesesperren haben, andere Kombinationen sind verboten
Die Effizienz der Sperrverfahren hängt auch vom Sperrgranulat (je feiner, desto höher die
mögliche Parallelität)ab (Allerdings bedeutet das Setzen einer Sperre Aufwand)
Das Sperren von Objekten funktioniert meist physikalisch nicht, da die Festplatte als kleinste
Einheit den Sektor hat, der oft mehrere Objekte speichert und stets komplett gelesen
werden muss → Sektor ist intern das kleinste Sperrgranulat
- Definition Sperrhierarchie: Eine Hierarchie der sperrbaren DB-Einheiten
DB → Segment → Tabelle → Zeile/Objekte (Das Sperren einer Obereinheit sperrt auch die
Untereinheiten)
Durch die Wahl der Hierarchiestufe bestimmt man über den Sperraufwand und die mögliche
Parallelität
Beim Setzer einer Sperre muss überprüft werden, ob nicht bereits ein Objekt höherer oder
auch tieferer Stufe gesperrt ist (Sie Untersuchung fängt oben an)
- Definition Warnsperre/intention lock: Werden auf dem Sperrgranulat höherer Ebene gesetzt, um
die Absicht auszugrücken, ein Objekt weiter unten zu sperren (ermöglichen zu erkennen, ob auf
einer tieferen Ebene ein Sperrgranulat bereits inkompatibel gesperrt wurde)
Sperrmodi Warnsperren
- IS: Absicht, weiter unten ein Sperrgranulat lesend zu sperren
- IX: Absicht, weiter unten ein Sperrgranulat schreibend zu sperren
- SIX: Absicht, weiter unten ein Objekt erst lesend und danach schreibend zu sperren (weil nach
dem Lesen mit einer hohen Wahrscheinlichkeit geschrieben wird)
- Definition Zweiphasen-Sperrprotokoll: Eine Transaktion muss wohlgeformt (muss jeder zu
bearbeitende Objekt erst sperren) und zweiphasig (darf nach der Sperrenfreigabe dieses Objekt
nicht mehr erneut sperren) sein
Zuerst wird alles gesperrt und dann nach und nach wieder freigegeben
Ansonsten sind trotz Sperren Inkonsistenzen möglich
Um die Parallelität zu fördern, wird dabei zu Beginn die am wenigsten restriktive Sperre
angefordert uns später, bei Bedarf, verschärft (beides aber nur in Phase 1)
Haben eine Wachstumsphase (Sperren werden angefordert) und Schrumpfungsphase
(Sperren werden freigegeben und dürfen nicht erneut angefordert werden)
Zusammenfasser: Jurij Weinblat, SoSe 2010. Alle Angaben ohne Gewähr. Quelle: Internetrecherche,
Vorlesungsunterlagen von Prof. Dr. Rainer Unland, Mitschriften (Universität Duisburg-Essen)
Seite 4 von 8
www.jurijs-skripte.de.vu
DBMS - Kapitel 9
- Definition Fortgepflanztes Rollback: Der Abbruch einer Transaktion führt zum Zurücksetzen
anderer, möglicherweise bereits abgeschlossener, Transaktionen
Kann nur dann auftreten, falls die vorherige Transaktion ihre geänderten Objekte bereits vor
ihrem Abschluss z.T. freigibt
Steht um Widerspruch mit den ACID-Kriterien
- Definition Striktes Zweiphasen-Sperrprotokoll: Die Freigabe aller gesperrten Objekte erfolgt als
atomare Operation → Vermeidet fortgepflanztes Rollback. → Default bei DB
Löst alle o.g. Probleme außer das Phantomproblem
Schränkt die Parallelität ein
- Definition Deadlock: Transaktionen warten wechselseitig darauf, dass der jeweils andere Prozess
ihnen ein bestimmtes Objekt freigibt
Kriterien, die einen Deadlock ermöglichen
- Gegenseitiger Ausschluss: Betriebsmittel stehen den Prozessen exklusiv zur Verfügung
- Nichtentziehbarkeit: Kein Zwangsentzug des Betriebsmittels, sondern Freigabe durch den
„Besitzer“-Prozess (sonst keine Zweiphasigkeit)
- Warte-und-Halte-Fest-Bedingung: Kriegt ein Prozess ein Betriebsmittel nicht, wartet er und
entsperrt die bereits erhaltenen Betriebsmittel nicht
- Mehrfachanforderung: Prozesse dürfen mehrere Betriebsmittel sperren
- Definition Preclaiming: Alle von einer Transaktion möglicherweise benötigten Transaktionen
werden auf einmal gesperrt (Wenn das nicht klappt, wartet die Transaktion)
Die Transaktion soll stets auf alle benötigten Daten zugreifen dürfen
Starvationproblem muss verhindert werden: Eine wartende Transaktion darf nicht stets von
anderen Transaktionen überholt werden (insb. Bei häufig angefragten Daten)
Verhindert Deadlocks (Kriterium der Mehrfachanforderung wird außer Kraft gesetzt), es
muss aber stets bekannt sein, welche Daten die Transaktion braucht (nicht immer der Fall →
Erfordert viel weiträumigere, vorbeugende Sperren)
Schränkt die Parallelität ein und wird kaum in der Praxis implementiert
VERFAHREN ZUR BEHANDLUNG VON DEADLOCKS
- Verhinderung → Preclaiming
- Vermeidung (Betriebsmittel werden nur dann zugeteilt, wenn es mind. Eine Möglichkeit gibt,
einen Deadlock zu vermeiden → Keine Anwendung, da zu komplex) → Im laufenden Betrieb
- Auflösung durch Zeitbeschränkung (time-out) → Problem der Zeitspannenwahl
Dem Prozess werden seine Betriebsmittel entzogen und er wird zurückgesetzt
Klappt immer, Aufwand ist relativ gering, aber setzt oft die teuerste Transaktion zurück
- Erkennung und Auflösung
Es wird ein Wartegraph aufgebaut, der Deadlocks erkennt (erkennbar an Zyklus)
Bei einem Deadlock wird eine der Transaktionen (die vorher definierte Bedingungen erfüllt)
zurückgesetzt (und eine kurze Zeit blockiert)
Deadlockerkennung verursacht aber einen hohen Aufwand
SPERRMANAGER
- Kümmert sich um die Synchronisation von Transaktionen
- Setzt Sperren und gibt sie wieder frei (Prüft, ob Sperre gesetzt werden kann→ Sonst Warten)
Informationen über Sperren stehen in der Sperrtabelle
- Erkennung und Verhinderung von Deadlocks (in periodischen Zeitabständen)
- Verhindert dauerhafte Blockaden durch „gerechte“ Sperren
Der Sperrmanager wird dann aktiviert, wenn sperren gesetzt, verschärft oder entfernt werden
Zusammenfasser: Jurij Weinblat, SoSe 2010. Alle Angaben ohne Gewähr. Quelle: Internetrecherche,
Vorlesungsunterlagen von Prof. Dr. Rainer Unland, Mitschriften (Universität Duisburg-Essen)
Seite 5 von 8
www.jurijs-skripte.de.vu
DBMS - Kapitel 9
PRÄDIKATSPERREN (GEGENTEIL: PHYSIKALISCHE SPERREN DIE OBEN BEHANDELTEN)
- Eignen sich zur Lösung des Phantomproblems (die vorherigen Sperren gelten nur für Objekte, die
bereits in der Datenbank sind)
- Definition Prädikatensperre: Sperren auf logischer Ebene, die durch ein Prädikat (=Bedingung)
beschrieben werden, dass eindeutig die zu sperrende Objektmenge abgrenzt (und damit auch die
Objekte, die erst später dazukommen bzw. alle potenziellen Datensätze)
- Problem: 2 durch Prädikate beschriebene Objektmengen können sich überlappen (n(p)vollständiges Problem) Nicht in DBMS implementiert!
- Kann annähernd über Zugriffspfade gelöst werden, indem Änderungen an Zugriffspfaden
temporär sperrt Dazu muss es aber Zugriffpfade geben
KONSISTENZ- BZW. ISOLATIONSSTUFEN
Je nachdem, wie restriktiv die gewählte Stufe ist, vermeidet man bestimmte Probleme, aber
schränkt die Parallelität ein
Betreffen aber nur das Lesen: Schreibvorgänge müssen stets konsistenzbewahrend sein!
- READ COMMITED: Lesesprerren werden frühzeitig wieder aufgelöst (sofort, nachdem das Objekt
gelesen wurde) Garantiert aber, dass der gelesene Datensatz irgendwann eine Bedeutung
hatte
- READ UNCOMMITED: Kann auch Werte zurückliefern, die als Zwischenergebnis bei der
Transaktionsdurchführung verstanden werden können. Hatte also evt. nie Gültigkeit
Recovery
- Ein Konzept, dass die DB in einen eindeutigen und konsistenten Zustand zurückversetzt
- Dabei geht es darum, die Änderungen von noch nicht abgeschlossenen Transaktionen rückgängig
zu machen und die Änderungen von abgeschlossenen Transaktionen unangetastet zu lassen
- Definition Recoveryereignis: Ein Ereignis, dass zum (teilweisen) Abbruch aller laufenden
Transaktionen führen oder Daten korrumpieren kann
- Definition Transaktionsrecoveryereignis: Lässt sich einer auslösenden Transaktion zuordnen.
Seine Auswirkungen betreffen nur diese Transaktion
3 FÄLLE VON TRANSAKTIONSRECOVERYEREIGNISEN
Anwendungsbedingte Transaktionsrecoveryereignisse
- Fehler abseits des DBMS
- Können durch eine Anwendung verursacht werden: Prozeduraufruf mit falschen Parametern
- Können durch den Anwender verursacht werden: Fehleingaben
Systembedingte Transaktionsrecoveryereignisse
- Müssen von der DBMS im z.B. im Rahmen der operationalen Integrität erkannt werden
- Beispiele: Synchronisationskonflikte, Deadlocks, Zugriffsverletzungen
Kaskadierende Transaktionsrecoveryereignisse
- Tretten als Folge anderer Transaktionsrecoveryereignisse auf
- Z.B. bei Wechselwirkungen zwischen Transaktionen
Erzeugen ein fortgepflanztes Rollback: Es müssen auch andere Transaktionen zurückgesetzt
werden
- Definition Umgebungsrecoveryereignis: Systemressourcen fallen temporär (Rechnerabsturz) oder
dauerhaft (Plattendeffekt) aus.
AUSWIRKUNGEN VON UMGEBUNGSRECOVERYEREIGNISSEN
Hauptspeicherrecoveryereignisse
- Der Inhalt des Hauptspeichers geht zum Beispiel durch einen Systemabsturz verloren
- Dadurch gehen auch Informationen über die laufenden Transaktionen und die Sperrtabelle
verloren
Sekundärspeicherrecoveryereignisse
- Z.B. infolge eines Headcrashs geht der Festplatteninhalt verloren
Zusammenfasser: Jurij Weinblat, SoSe 2010. Alle Angaben ohne Gewähr. Quelle: Internetrecherche,
Vorlesungsunterlagen von Prof. Dr. Rainer Unland, Mitschriften (Universität Duisburg-Essen)
Seite 6 von 8
www.jurijs-skripte.de.vu
DBMS - Kapitel 9
BEDEUTUNG FÜR DAS ACID-KRITERIUM: ATOMICITY (UNTEILBARKEIT)
- Solange die Transaktion nicht erfolgreich beendet wurde, muss sie rückgängig gemacht werden
können
BEDEUTUNG FÜR DAS ACID-KRITERIUM: DURABILITY (DAUERHAFTIGKEIT)
- Jede erfolgreich beendete Transaktion muss jeden Fehlerfall überleben
- Definition UNDO: Dabei wird die DB auf einen früheren, konsistenten Zustand zurückgesetzt.
Dazu kann entweder ein Backup eingespielt werden, oder die durchgeführten Operationen
rückgängig gemacht werden
Damit werden Datensätze entfernt, die keine Gültigkeit haben
- Definition REDO: Dabei wird ein verloren gegangener konsistenter DB-Zustand wiederhergestellt.
Dies kann durch das Einspielen eines Backups oder durch das Wiederholen der nicht
gespeicherten Transaktionen erfolgen.
Um die Änderungen von eigentlich bereits erfolgreich abgeschlossenen Transaktionen in die
DB einzuspielen
WANN IST EIN REDO UND WANN EIN UNDO DURCHZUFÜHREN?
- Dies hängt entscheidend davon ab, wie die Transaktion geendet ist
Wurde bereits Teile in den Sekundärspeicher zurückgeschrieben? UNDO!
Ist eine Transaktion abgeschlossen worden, aber es wurden nicht alle Änderungen
zurückgeschrieben: REDO!
2 BESONDERHEITEN IN HINBLICK AUF DAS UNDO
- Steal: Wenn eine Transaktion zu jedem Zeitpunkt Daten modifizieren kann, müssen spezielle
Vorkehrungen für das UNDO getroffen werden
- ¬Steal: Wenn eine Transaktion nur zum Schluss Daten modifizieren kann, brauchen keine
Vorkehrungen für das UNDO getroffen werden
2 BESONDERHEITEN IN HINBLICK AUF DAS REDO
- Force: Alle von der Transaktion modifizierten Daten müssen vor ihrem Ende in den
Sekundärspeicher zurückgeschrieben werden: Keine Vorkehrungen für das REDO notwendig
- ¬Force: Alle von der Transaktion modifizierten Daten können auch nach ihrem Ende in den
Sekundärspeicher zurückgeschrieben werden: Spezielle Vorkehrungen für das REDO notwendig!
LOGDATEI
- Definition Logdatei: Eine Datei, in der jeder Transaktionsbeginn und –ende und jede
Änderungsoperation der DB in richtiger Reihenfolge protokolliert werden
Enthält Informationen über den letzten konsistenten DB-Zustand und überlebt Fehler
REDO und UNDO stützen sich auf diese Logdatei
Generell kann logisch und physikalisch protokolliert werden
- Definition Logische Protokollierung: Es wird protokolliert, welche Änderungsoperation mit
welchen Operanden auf welche Spalte durchgeführt wurde
Für das Gelingen eines UNDO muss es eine gültige inverse Operation geben
- Definition Physikalische Protokollierung: Hier werden sämtliche Werte vor der Änderung
(=Before-Image) und nach der Änderung (After-Image) protokolliert
Das Before-Image muss vor der Modifikation der DB erstellt werden
Das After-Image muss spätestens zusammen mit dem Transaktionsende erstellt werden
WAL-Prinzip: Alle Logeinträge einer Transaktion müssen vor ihrem Ende geschrieben werden
(Write Ahead Log)
Zusammenfasser: Jurij Weinblat, SoSe 2010. Alle Angaben ohne Gewähr. Quelle: Internetrecherche,
Vorlesungsunterlagen von Prof. Dr. Rainer Unland, Mitschriften (Universität Duisburg-Essen)
Seite 7 von 8
www.jurijs-skripte.de.vu
DBMS - Kapitel 9
BEMERKUNGEN
- Die Reihenfolge der Logdateieinträge ist wesentlich und müssen der Realität ensprechen.
Es ist nicht möglich, dass zunächst nur die Einträge für die endenden Transaktionen
eingetragen werden
- Logateieinträge werden als Ringpuffer verwaltet: Am einen Ende kommen neue Logdateieinträge
rein, am anderen Ende werden sie in den Sekundärspeicher geschrieben
Damit können die Folgen der Systemabstürze mit Hauptspeicherverlust behoben werden
- Logdateieinträge werden oft noch zusätzlich redundant in ein Logarchiv gespeichert
Damit können die Folgen beliebig schwerer Recovryereignisse behandelt werden
Enthält mehr Recoverydaten als die Logdatei
ROLLBACK
- DBMS setzt im laufenden Betrieb wegen eines Transaktionrecoveryereignisses bestimmte
Transaktionen zurück. Deren Änderungen werden dabei rückgängig gemacht.
- Dieser Prozess kann in der Regel parallel zu anderen Transaktionen ablaufen
Vorgehen bei ¬Steal: Freigeben der betroffenen Hauptspeicherseiten
Vorgehen bei Steal: Dabei geht man die Logdatei zurück und nutzt die Before-Images, um die
veränderten Werte wiederherzustellen.
SYSTEMNEUSTART
- Wird nach einen Systemabsturz notwendig. Dabei geht der gesamte Hauptspeicher- und
Pufferinhalt verloren (Listen aktiver Transaktionen, Sperren)
- DB kann danach inkonsistent sein, da Transaktionen aktiv gewesen sein könnten
Dabei wird die Logdatei rückwärts gelesen und zu jedem BOT das EOT gesucht
Vorhanden: Transaktion war bereits beendet eventuell REDO
Nicht vorhanden: Transaktion war nicht beendet eventuell UNDO
CHECKPOINTS
Helfen dabei festzustellen, bis wann rückwärts gelesen werden muss
- Definition Checkpoint: Werden in regelmäßigen Abständen in die Logdatei geschrieben und
geben Auskunft darüber, welche Transaktionen zum aktuellen Zeitpunkt aktiv waren.
All die Transaktionen, die im letzten Checkpoint stehen bzw. danach gestartet wurden und bis
zum Absturz nicht beendet wurden konnten nicht erfolgreich abgeschlossen werden
- Problem mit der ¬Force-Strategie: Wurden alle abgeschlossenen Transaktionen tatsächlich
beendet
Mit dem Anlegen eines Checkpoints müssen alle bereits abgelaufenen Transaktionen ihre
Änderungen auch geschrieben haben Es müssen nur die Transaktionen nach dem Checkpoint
wiederholt werden.
REDO/UNDO kann höchstens überflüssig sein, gefährdet aber nie die Konsistenz der DB
Checkpoints mit Systemstillstand
- Zum Erstellungszeitpunkt gibt es keine aktiven Transaktionen mehr (wenn doch, erst
Transaktionen ablaufen lassen).
- Sehr einfach, Rollback über einen Checkpoint hinaus ist nie notwendig
Minimale Logdatei: Startet mit dem letzten Checkpoint
- Nachteil: Das Warten auf unfertige Transaktionen verursacht Wartezeiten
Checkpoints im laufenden Betrieb
- Checkpoints werden unabhängig von aktuell ablaufenden Systemaktivitäten erstellt
In der Logdatei geschriebene Aktivitäten sind atomar (=abgeschlossen)
Geht man davon aus, dass alle vor dem Checkpoint bereits abgelaufenen Transaktionen auch
ihre Daten geschrieben haben, ist ein REDO nur für die Transaktionen nach dem Checkpoint
notwendig (bei UNDO schon)
Unscharfer Checkpoint
- Logdatei ist eindeutig durchnummeriert und es wird in der Logdatei festgehalten, welche
Arbeitsspeicherinhalte noch nicht zurückgeschrieben wurden
Zusammenfasser: Jurij Weinblat, SoSe 2010. Alle Angaben ohne Gewähr. Quelle: Internetrecherche,
Vorlesungsunterlagen von Prof. Dr. Rainer Unland, Mitschriften (Universität Duisburg-Essen)
Seite 8 von 8
www.jurijs-skripte.de.vu
DBMS - Kapitel 9
Sicherungspunkte
- Befinden sich innerhalb von Transaktionen
- Auf diese können Transaktionen gezielt zurückgesetzt werden (partial rollback) und
Recoveryereignisse können darauf ansetzen
- Bieten Vorteile bei langen Transaktionen, die Stunden, Tage oder Wochen dauern
REKONSTRUKTION
- Definition Dump: Eine Sicherheitskopie der gesamten DB auf einem nichtflüchtigen Medium
Müssen regelmäßig erstellt und an unterschiedlichen Orten verwahrt werden (und nicht auf
demselben Medium wie die DB)
Haben dieselben Probleme wie Checkpoints und es gibt dieselben Dumptypen
KOMPENSATION
- Das Gegenstück zu Transaktionen, die durch Ausführung von inversen Operationen die
betrachtete Transaktion kompensieren können
2 Voraussetzungen für Kompensation
1. Lange Transaktionen lassen sich in eigenständige Untereinheiten zerlegen
2. Zu jeder dieser Untereinheiten gibt es eine Kompensationstransaktion
Kompensationen garantieren keine Serialisierbarkeit Da die Ausgaben an den Benutzer
unwiderruflich sind
Zusammenfasser: Jurij Weinblat, SoSe 2010. Alle Angaben ohne Gewähr. Quelle: Internetrecherche,
Vorlesungsunterlagen von Prof. Dr. Rainer Unland, Mitschriften (Universität Duisburg-Essen)