Kapitel 9 – Paralleler Zugriff auf DB
Werbung
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)
