Beispiel: Bankensoftware. 6 Transaktionen. 6.1 Grundlagen Einführung und Begriffe. Transaktionen. Beispiel (Fortsetzung 1): Verzahnte Ausführung

Transkript

1 6 Transaktionen Beispiel: Bankensoftware 6.1 Grundlagen Einführung und Begriffe Kritische Abschnitte elementares Mittel zur Konsistenzwahrung bei nebenläufigen Zugriffen Programmierer selbst für korrektes Setzen der Sperren verantwortlich Anforderungen an höheres Konzept Automatisches Erzwingen der Konsistenzwahrung Umgang mit verschiedenen kritischen Abschnitten Konsistenzwahrung auch bei Fehlern und Ausfällen Transaktionen : transfer(account_1, account_2, amount) // transfer money from bank account account_1 // to bank account account_2 // part 1: take money from source balance_1 := READ(account_1); balance_1 := balance_1 - amount; WRITE(account_1, balance_1); // part 2: put money to target balance_2 := READ(account_2); balance_2 := balance_2 + amount; WRITE(account_2, balance_2); :sum_up(account_1, account_2, sum) // sum_up the balances of two accounts) temp1 := READ(account_1); temp2 := READ(account_2); sum := temp1 + temp2; Beispiel (Fortsetzung 1): Verzahnte Ausführung Beispiel (Fortsetzung 2): Verzahnte Ausführung : transfer(account_1, account_2, amount) // part 1: take money from source balance_1 := READ(account_1); balance_1 := balance_1 - amount; WRITE(account_1, balance_1); // part 2: put money to target balance_2 := READ(account_2); balance_2 := balance_2 + amount; WRITE(account_2, balance_2); :sum_up(account_1, account_2, sum) temp1 := READ(account_1); temp2 := READ(account_2); sum := temp1 + temp2; Verzahnte Ausführung bewirkt für eine inkonsistente Sicht auf die Daten! : transfer(account_1, account_2, amount) // transfer money from bank account account_1 // to bank account account_2 // part 1: take money from source balance_1 := READ(account_1); balance_1 := balance_1 - amount; WRITE(account_1, balance_1); // part 2: put money to target balance_2 := READ(account_2); : transfer(account_3, account_2, amount) // transfer money from bank account account_1 // to bank account account_2 // part 1: take money from source balance_3 := READ(account_3); balance_3 := balance_3 - amount; WRITE(account_3, balance_3); // part 2: put money to target balance_2 := READ(account_2); balance_2 := balance_2 + amount; WRITE(account_2, balance_2); balance_2 := balance_2 + amount; WRITE(account_2, balance_2); Durch die Verzahnung geht eine Überweisung () verloren: lost update -Problem

2 Beispiel (Fortsetzung 3): Ausfall Transaktion : transfer(account_1, account_2, amount) // part 1: take money from source balance_1 := READ(account_1); balance_1 := balance_1 - amount; WRITE(account_1, balance_1); Ausfall // part 2: put money to target balance_2 := READ(account_2); balance_2 := balance_2 + amount; WRITE(account_2, balance_2); Operation wurde zur Hälfte durchgeführt und hinterläßt einen inkonsistenten Zustand der Daten Entsprechende Kennzeichnung (Klammerung) macht einen Programmabschnitt zur Transaktion: :transfer(account_1, account_2, amount) START (oder auch BOT (= begin of transaction) // transfer money from bank account account_1 // to bank account account_2 // part 1: take money from source balance_1 := READ(account_1); balance_1 := balance_1 - amount; WRITE(account_1, balance_1); // part 2: put money to target balance_2 := READ(account_2); balance_2 := balance_2 + amount; WRITE(account_2, balance_2); COMMIT (oder auch EOT (= end of transaction) Eine Transaktion ist eine Folge von Operationen, die in ihrer Wirkung atomar sein soll Operationen in Transaktionen Anforderungen an Transaktionen (ACID - Principle): Zur grundsätzlichen Betrachtung reicht es aus, sich auf die folgenden fünf Operationen zu beschränken: Datenoperationen: READ(X) WRITE(X,<Wert>) Lies Datum X Schreibe Datum X Transaktionsoperationen: START Beginn der Transaktion ABORT Abbruch der Transaktion (impliziert Rücksetzen (Rollback)) COMMIT Ende der Transaktion Wir nehmen an, daß dem ersten Datenzugriff ein START automatisch vorangeht. Wir lassen daher im folgenden der Einfachheit halber das START weg. A tomicity C onsistency I solation D urability Atomarität Alles-oder-Nichts-Eigenschaft: Die Transaktion wird entweder vollständig ausgeführt oder hinterläßt keinerlei Wirkung. Konsistenz Eine Transaktion führt einen konsistenten Datenzustand wieder in einen solchen über. Isolation Zwischenergebnisse einer Transaktion sind für andere Transaktionen nicht sichtbar. Dauerhaftigkeit: Die Änderungen einer beendeten und bestätigten (committed) Transaktion können weder verloren gehen noch rückgängig gemacht werden

3 Die ACID-Eigenschaften sind gefährdet durch: T3 Tn Interferenz nebenläufiger Transaktionen ( Konsistenz, Isolation) start, read, write, abort, commit fehlerhafte Umgebung ( Atomarität, Dauerhaftigkeit) Transaktionssysteme benötigen daher Maßnahmen zur Koordination von Transaktionen (Concurrency Control) Erhaltung und der Daten und ihrer Konsistenz, d.h. zur Rücksetzung von Transaktionen (Recovery) Die beiden Funktionsbereiche Koordination und Rücksetzung können als eigenständige Module separiert werden Architektur eines Transaktionssystems Planer (scheduler) Pufferverwalter (cache manager) Daten read, write, abort, commit read, write Transaktionsverwalter (transaction manager) Rücksetzer (recovery manager) Zustände von Transaktionen Transaktionen und Pläne (Schedules) Beendet (partially committed) TV_COMMIT Bestätigt (committed) Def. Eine Transaktion Ti ist eine Folge von Schreib- oder Leseoperationen (wi oder ri), abgeschlossen durch entweder ein Commit (ci) oder ein Abort (ai). COMMIT Eine Transaktion ist also in sich seriell, d.h. ihre Operationen werden streng hintereinander ausgeführt, d.h. man kann eine Transaktion auch als Menge von Operationen mit einer Totalordnung < i auffassen Undefiniert (undefined) START Aktiv (active) TV_ABORT Undefiniert (undefined) Wenn mehrere Transaktionen verzahnt ausgeführt werden, kann es zu Konflikten kommen: ABORT Gescheitert (failed) TV_ROLLBACK Zurückgesetzt (aborted) Def. Zwei (Daten)operationen px ( ) T i und q( y) T j stehen in Konflikt zueinander ( p q), wenn sie (1) auf dasselbe Datum zugreifen, d.h. x = y und (2) unterschiedlichen Transaktionen angehören, d.h. i j und (3) mindestens eine von beiden eine Schreiboperation ist

4 Plan Die nebenläufige, verzahnte Ausführung einer Menge von Transaktionen bildet einen Plan (schedule) 6-13 Def. Ein Plan S einer Menge von Transaktionen { T 1,T 2,...,T n } ist eine partiell geordnete Menge aller Transaktionsoperationen mit den folgenden Eigenschaften: (1) Sei p,q T i : p < i q p < S q (Operationsreihenfolge bleibt erhalten) (2) p,q S: p q entweder p < S q ( ) oder ( q < S p) (für Operationen, die in Konflikt stehen, muss eine Reihenfolge festgelegt werden) Ein Plan lässt sich darstellen als gerichteter Graph, dessen Knoten die Operationen und dessen Kanten die Reihenfolge zwischen Operationen festlegen. Jede konkrete Ausführung eines Plans bedeutet ein Ablaufen der Knoten (Operationen) gemäß der gegebenen partiellen Ordnung. Graphentheoretisch entspricht dies einer topologischen Sortierung. Die gibt es aber nur in zyklenfreien Graphen. Der Definition des Plans schließt daher aus, daß der zugehörige Graph Zyklen enthält. w 3 (z) r 3 (y) w 3 (z) c 3 w 3 (z) r 3 (y) w 3 (z) c 3 w 3 (z) r 3 (y) w 3 (z) c kein Plan: nicht alle Konflikte aufgelöst kein Plan: enthält Zyklus Plan: zyklenfrei und alle Konflikte aufgelöst Bestätigte Projektion Rücksetzbarkeit Def. Die bestätigte Projektion eines Plans S (C(S)) ist die Teilmenge von S, die entsteht, wenn man aus S alle Operationen entfernt, die nicht zu in S bestätigten Transaktionen gehören. Plan S r3(x) r2(x) w3(x) w2(y) w3(y) a2 c3 Write(x) Abort Read(x) Commit Dieser Plan ist nicht rücksetzbar, da bereits bestätigt ist, obwohl ungültige Daten gelesen wurden r1(x) w1(x) c1 Transaktion Ti liest von Transaktion Tj, wenn Ti Datenelemente liest, die vorher von Tj geschrieben wurden. Bestätigte Projektion von S 6-15 Ein Plan S heißt rücksetzbar (recoverable, S RC) wenn jede Transaktion T S erst dann bestätigt wird, wenn alle Transaktionen, von denen sie gelesen hat, bereits bestätigt sind oder abgebrochen wurden 6-16

5 Lesen unbestätigter Daten (dirty read) Überschreiben unbestätigter Daten (dirty write) T3 Write(x) Read(x) Write(y) Read(y) Abort Commit Commit (Annahme: vor Beginn der Transaktionen sei x=1) Write(x,2) Write(x,3) Commit Abort Hier muß sichergestellt werden, daß der alte Wert (x=2) (before-image) wiederhergestellt wird. Dieser Plan ist rücksetzbar, bewirkt jedoch das Rücksetzen von und T3. Ein Plan S vermeidet einen kaskadierenden Abbruch (avoiding cascading abort, S ACA) wenn keine Transaktion aus S unbestätigte Daten liest. Write(x,2) Abort Write(x,3) Commit 6-17 Hier ist es unnötig, den alten Wert (x=1) wiederherzustellen, da x anschließend überschrieben wurde Überschreiben unbestätigter Daten (dirty write) Serialisierbarkeit Write(x,2) Abort Write(x,3) Abort Interferenzprobleme zwischen Transaktionen werden vermieden, wenn Transaktionen seriell ausgeführt werden. Ein Plan S heißt seriell, wenn für jedes Paar von Transaktionen alle Operationen der einen vor jeder Operation der anderen ausgeführt werden. r2(x) w2(y) c2 r1(x) w1(x) c1 w3(x) w3(y) c3 Hier muß der ursprüngliche Wert (x=1) wiederhergestellt wird, da beide Transaktionen zurückgesetzt werden. Das Überschreiben unbestätigter Daten schafft offensichtlich Probleme beim Rücksetzen und sollte vermieden werden. Ein Plan S heißt strikt (S ST ), wenn von keiner Transaktion aus S unbestätigte Daten gelesen oder überschrieben werden. Wenn wir annehmen, daß eine Transaktion in sich korrekt ist, d.h. die Daten in einem konsistenten Zustand hinterläßt, dann sind serielle Pläne offensichtlich korrekt Die Idee besteht jetzt darin, einen Plan dann als korrekt anzuerkennen, wenn er die gleiche Wirkung hat wie (irgend)ein serieller: Zwei Pläne S und S heißen äquivalent, wenn sie dieselben Ausgabewerte liefern und denselben Datenzustand zurücklassen. Ein Plan S heißt serialisierbar (S SR), wenn seine bestätigte Projektion C(S) zu einem seriellen Plan äquivalent ist

6 Konfliktserialisierbarkeit Beispiel: Um nun bereits während der Ausführung von Transaktionen die Serialisierbarkeit feststellen und sogar erzwingen zu können, wollen eine schärfere Äquivalenzdefinition verwenden: Def. Zwei Pläne S und S heißen konfliktäquivalent, wenn sie aus denselben Operationen bestehen und Konflikte in gleicher Weise auflösen ( p q: p < S q p < S' q) Wenn in zwei Plänen die gleichen Operationen ausgeführt und dabei alle Konflikte in gleicher Weise aufgelöst werden, dann liefern sie auch das gleiche Ergebnis. Umgekehrt können zwei Pläne (zufällig) das gleiche Ergebnis liefern, obwohl sie in Konflikt stehende Operationen in unterschiedlicher Reihenfolge ausführen. S 1 S 2 S 3 Ein Plan S heißt konfliktserialisierbar (S CSR), wenn seine bestätigte Projektion C(S) zu einem seriellen Plan konfliktäquivalent ist. Anmerkung: Serialisierbarkeit ist unabhängig von Striktheit oder Rücksetzbarkeit! Sie reicht daher als Korrektheitskriterium für die Praxis nicht aus: Ein Plan S heißt korrekt, wenn er konfliktserialisierbar und rücksetzbar ist S S 2 / S 3 / S 4 S 1 ist gar kein Plan, da die Schreibkonflikte auf x nicht aufgelöst sind (Reihenfolge unklar). S 2,S 3,und S 4 sind Pläne, aber nicht äquivalent untereinander. Lediglich S 4 ist konfliktserialisierbar, d.h. konfliktäquivalent zum seriellen Plan T 2 < S T 1. Serialisierbarkeitstheorem Serialisierungsgraph (Abhängigkeitsgraph) Zusammenhang der Eigenschaften (Mengendiagramm) Konfliktserialisierbare Pläne SR Der Serialisierungsgraph (SG) eines Plans S ist ein gerichteter Graph, dessen Knoten die in S bestätigten Transaktionen bilden und der genau dann eine Kante von T i nach T j enthält, wenn eine Operation p i aus T i mit einer Operation q j aus T j in Konflikt steht und p i vor q j ausgeführt wird. r3(x) r1(x) w3(x) w1(y) r2(x) w3(y) c1 w2(x) c3 c2 Plan S Rücksetzbare Pläne RC kaskadierenden Abbruch vermeidende Pläne ACA Strikte Pläne ST Serielle Pläne T3 Serialierungsgraph SG(S) Theorem (Serialisierbarkeitstheorem) Ein Plan S ist genau dann konfliktserialisierbar, wenn sein Serialisierungsgraph SG(S) azyklisch ist 6-23 Korrekte Pläne 6-24

7 6.2 Koordination von Transaktionen Vorgehensweisen von Planern Da die Konsistenzwahrung automatisch geschehen soll, muß von einer beliebig verzahnten Folge von Operationen der nebenläufigen Transaktionen ausgegangen werden. Die Transaktionsverwaltung (bzw. der Planer als Teil der TV) hat dann die Aufgabe, aus dieser Aufruffolge einen Plan mit den gewünschten Eigenschaften (z.b. Serialisierbarkeit) zu schaffen. Da er die Operationen nicht verändern kann, bleiben nur die folgenden Optionen: 1. Sofortige Ausführung der Operation 2. Verzögerung der Ausführung der Operation (um eine Umordnung zu bewirken) 3. Abweisen der Operation (führt zum Abbruch der Transaktion) T 1 T 2 T n Planer (scheduler) Folge F von Operationen Folge F von Operationen Bezüglich der Wahl der Optionen kann man Planer mit unterschiedlichem Verhalten unterscheiden Konservatives Vorgehen Konservative Planer gehen von häufigen Konflikten aus und sind daher sehr vorsichtig. Sie verzögern Operationen so lange, bis kaum noch etwas schiefgehen kann. Den Extremfall bildet der serielle Planer, der alle Transaktionen zwangsserialisert. Aggressives Vorgehen Aggressive Planer neigen dazu, Operationen sofort auszuführen, weil sie davon ausgehen, daß Konflikte ohnehin selten sind. Sollte sich doch ein Konflikt ergeben, so nimmt man in Kauf, Operationen zurückzuweisen, d.h. Transaktionen abzubrechen und zurückzusetzen. konservativ keine Abbrüche lange Verzögerungen aggressiv viele Abbrüche keine Verzögerungen Daten Zweiphasensperren Ähnlich wie bei kritischen Abschnitten werden Sperren benutzt, um in Konflikt stehende Operationen (und damit die aufrufende Transaktion) zu verzögern. Da Lesezugriffe sich gegenseitig nicht stören, werden zwei Sorten von Sperren vorgesehen: Lesesperren und Schreibsperren Sperrenverträglichkeit read_lock write_lock read_lock + - write_lock - - Die Menge der Operationen erweitert sich daher um die Sperroperationen Operation Kurzform Bedeutung read_lock(x) rl(x) Setze Lesesperre auf Datum x write_lock(x) wl(x) Setze Schreibsperre auf Datum x read_unlock(x) ru(x) Lösche Lesesperre auf Datum x write_unlock(x) wu(x) Lösche Schreibsperre auf Datum x Ist eine Lesesperre gesetzt, so können noch weitere Lesesperren gesetzt werden, aber keine Schreibsperre. Ist eine Schreibsperre gesetzt, so können keine weitere Sperren zugelassen werden. Lesesperren werden auch shared locks, Schreibsperren auch exclusive locks genannt

8 Das Zweiphasen-Sperrprotokoll (ZPP) (Two-Phase-Locking (2PL)) Zweiphasen-Sperrprotokoll Was passiert, wenn Forderung 3 nicht erfüllt wird? Mithilfe dieser Sperren läßt sich ein Protokoll angeben, das die Forderung nach Serialisierbarkeit erfüllt. 1. Eine Transaktion muß jedes Datenelement vor dem ersten Zugriff mit einer dem Zugriff entsprechenden Sperre belegen. 2. Kein Datenelement darf mit unverträglichen Sperren belegt werden. 3. Eine Transaktion darf nach der ersten Freigabe einer Sperre keine weitere Sperre setzen. 4. Am Ende der Transaktion müssen alle von ihr gehaltenen Sperren freigegeben sein. Forderung 3 gibt dem Sperrprotokoll seinen Namen, da durch sie die Transaktion in zwei Phasen zerlegt wird, eine, in der Sperren sukzessive erworben werden und eine, in der die Sperren wieder freigegeben werden read_lock(x) read(x) read_unlock(x) write_lock(y) write(y) write_unlock(y) commit write_lock(x) write(x) write_lock(y) write(y) write_unlock(x) write_unlock(y) commit r 1 ( x) < w 2 ( x) w 2 ( y) < w 1 ( y) führt zu Zyklus, d.h. nicht serialisierbar 6-30 Modifikation: Striktes Zweiphasensperren Anzahl Sperren Das normale Zweiphasensperren erzeugt serialisierbare Pläne, jedoch nicht unbedingt rücksetzbare: write_lock(x) write(x) write_unlock(x) abort read_lock(x) read(x) read_unlock(x) commit Anzahl Sperren c Zeit Zeit Normales 2PL Striktes 2PL Daher zusätzliche Forderung: Anzahl Sperren c 5 Alle jemals erworbenen Sperren werden bis zum Ende der Transaktion gehalten. Dadurch werden strikte Pläne erzeugt, die nicht nur rücksetzbar sind, sondern auch kaskadierendes Rücksetzen vermeiden. Zeit Konservatives 2PL 6-31 c 6-32

9 Anmerkungen: 6.3 Das strikte Zweiphasen-Sperren ist das in der Praxis übliche Verfahren. Die Sperren müssen nicht vom Programmierer gesetzt werden, sondern werden automatisch vom Planer (Scheduler) als Teil des TVS eingefügt und verwaltet. Das 2PL kann (mit Ausnahme der konservativen Variante) zu Verklemmungen (deadlocks) führen. Darauf wird später in einem speziellen Kapitel eingegangen. Was als Datenelement zu verstehen ist bzw. was die Einheit der Sperrung ist, hängt vom Einsatzgebiet der Transaktionen ab: Das Spektrum reicht von einzelnen Werten über Sätze bis hin zu Mengen von Dateien. (Sperrgranularität) - kleine Dateneinheiten (feine Granularität) ermöglicht hohe Nebenläufigkeit, bedeutet aber großen Aufwand zur Verwaltung der Sperren - große Dateneinheiten (grobe Granularität) reduziert die Nebenläufigkeit, bedeutet aber geringen Aufwand zur Verwaltung der Sperren 6-33 Synchronisation (Concurrency Control) Atomicity Consistency Isolation Durability 6-34 (Recovery) Dauerhaftigkeit und Atomizität sind durch das Auftreten von Fehlern gefährdet Fehlerarten Für Transaktionssysteme sind drei verschiedene Arten von Fehlern zu unterscheiden Transaktionsfehler Systemabbruch Ausfall von Speichermedien Ausfall von Speichermedien Transaktionsfehler Fehlertyp Ausfall von Speichermedien Fehlertyp Transaktionsfehler Ursachen Fehler im BS (Treibersoftware) Hardwarefehler: Kanal, Steuereinheit, Bus Mechanische Zerstörung (head crash) Verlust der Magnetisierung Ursachen Interne Konsistenzverletzung Entscheidung des Transaktionsverwaltungssystems (Verklemmung, externe Konsistenzverletzung, optim. Verfahren) Häufigkeit ca. 1 mal im Jahr Häufigkeit ca. 1 mal in der Sekunde Maßnahmen zur Benötigte Zeit zur Kopien der Daten auf anderen Medien benötigt Wenn Datenzustand nicht aktuell, müssen die Wirkungen aller seither bestätigten Transaktionen nachgeführt werden (redo) ca. 1 Stunde Maßnahmen zur Benötigte Zeit zur Jegliche Wirkung dieser Transaktion ungeschehen machen (undo) etwa so lange wie eine erfolgreiche Transaktionsverarbeitung

10 Systemfehler Komponenten und ihr Zusammenspiel Fehlertyp Systemfehler T3 Tn Ursachen Fehler im BS Hardwareausfall (Stromversorgung) Fehler im TVS Architektur eines Transaktionssystems Planer (scheduler) start, read, write, abort, commit Transaktionsverwalter (transaction manager) read, write, abort, commit Häufigkeit Maßnahmen zur ca. 1 mal in der Woche des letzten bestätigten Zustands: evtl. Nachführen bestätigter aber verlorengegangener Änderungen evt. Rückgängigmachen von Änderungen nichtbestätigter Transaktionen Stabiler Speicher read write recovery manager (RM) fetch flush Pufferverwalter (cache manager) read write read, write Instabiler Speicher (Puffer) Benötigte Zeit zur ein paar Minuten Log Das Log Das Log Zur eines bestätigten Zustands benötigt der Recovery Manager (RM) zusätzliche Information, die im stabilen Speicher gehalten wird: Das Log ist eine Repräsentation der Ausführung der Transaktionen. Es besteht im wesentlichen aus Einträgen der Form (T i, x, v) T i Transaktionsnummer x Datenelement v Wert für jede durchgeführte Schreiboperation. Die Einträge sind totalgeordnet und repräsentieren die Ausführungsreihenfolge. Zusätzlich unterhält der RM drei Listen: Liste der aktiven Transaktionen (active list) Liste der bestätigten Transaktionen (commit list) Liste der abgebrochenen Transaktionen (abort list) Ein Eintrag (T i, x, v) im Log kann entfernt werden, wenn (1) die Transaktion T i abgebrochen wurde (2) die Transaktion T i bestätigt wurde und eine andere bestätigte Transaktion v überschrieben hat Das Wiederherstellen als Operation muß idempotent sein: Jede Folge unvollständig durchgeführter en gefolgt von einer vollständigen muß dasselbe Ergebnis haben wie genau eine vollständige

11 Pufferverwaltung (Cache Manager, CM) Operationen Aus Leistungsgründen werden aktuelle Daten in einem Pufferbereich im Hauptspeicher gehalten (instabiler oder flüchtiger Speicher) Der Puffer ist organisiert als eine Menge von Zellen, die jeweils ein Datenelement (typischerweise ein (Platten-)Block) aufnehmen können. Jede Zelle besitzt einen Indikator, der angibt, ob der Inhalt mit dem im stabilen Speicher (Platte) übereinstimmt (dirty bit). Der Puffer verfügt über ein Pufferverzeichnis, in dem alle aktuell im Puffer befindlichen Datenelemente und ihre jeweilige Zellennummer eingetragen sind. Pufferverzeichnis Puffer Datenelement Zellennummer Zellennummer dirty bit Inhalt x ' ' y 'New York' : : : : : Der Pufferverwalter unterstützt vier Operationen Flush(c) Ist das dirty-bit gesetzt, wird der Inhalt von Zelle c in den stabilen Speicher kopiert Fetch(x) Eine leere Zelle c wird ausgewählt und Datenelement x vom stabilen Speicher nach c kopiert. Das dirty bit wird auf 0 gesetzt und ein entsprechender Eintrag in das Verzeichnis vorgenommen. (Sollte keine Zelle frei sein, so ist eine freizumachen (flush)) Pin(c) Verhindert das Auslagern (flush) des Inhalts von c Unpin(c) Ermöglicht wieder das Auslagern (flush) des Inhalts von c sverfahren Puffer (Hauptspeicher) Stabiler Speicher (Platte) Strategien Die bei der zu ergreifenden Maßnahmen hängen stark davon ab, wie RM und CM mit den Daten im Puffer umgehen: Weitergabe von Änderungen: FORCE NOFORCE Bei Commit werden alle Änderungen der Transaktion in den stabilen Speicher geschrieben Nach Commit einer Transaktion können sich geänderte Daten im Puffer befinden, die noch nicht "gerettet" wurden FORCE Puffer (Hauptspeicher) KEEP Stabiler Speicher (Platte) Ersetzungsstrategie: KEEP NOKEEP Alle Änderungen einer Transaktion werden bis zum Commit-Zeitpunkt im Puffer gehalten. Der Pufferverwalter darf auch unbestätigte Daten aus dem Puffer verdrängen Um den Aufwand beim Wiederherstellen gering zu halten, ist es wünschenswert, daß sich im Puffer ausschließlich unbestätigte, im stabilen Speicher ausschließlich bestätigte Daten befinden NOFORCE unbestätigte Daten KEEP bestätigte Daten 6-44

12 Puffer (Hauptspeicher) Stabiler Speicher (Platte) sverfahren Für den allgemeinen Fall benötigt der RM die folgenden beiden Operationen: FORCE NOKEEP undo: Änderungen unbestätigter Transaktionen im stabilen Speicher müssen rückgängig gemacht werden Puffer (Hauptspeicher) Stabiler Speicher (Platte) redo: Änderungen bestätigter Transaktionen im Pufferspeicher müssen nachgefahren werden. Je nach der eingesetzten Strategie (keep, force) kann auf redo und/oder undo verzichtet werden. NOFORCE unbestätigte Daten NOKEEP bestätigte Daten Bei Keep/Force ist bei der nicht viel zu tun, allerdings muß im laufenden Betrieb erheblicher Aufwand getrieben werden. Bei Nokeep/Noforce ist ein effizienter Normalbetrieb möglich zu Lasten der aufwendigen Übersicht über die sstrategien Strategie Benötigte Daten Benötigte Operation 6-47 Art der Daten im Puffer Art der Daten im stabilen Speicher Keep/Force - - nur unbestätigte nur bestätigte Keep/Noforce after images redo bestätigte und unbestätigte nur bestätigte Nokeep/Force before images undo nur unbestätigte bestätigte und unbestätigte Nokeep/Noforce before und after images redo und undo bestätigte und unbestätigte bestätigte und unbestätigte Beispiel: Nokeep/Noforce Write (Ti, x, v) active := active {Ti}; if x cache then c := Fetch(x); LSN := LSN +1; /* Log Serial Number log[lsn] := (Ti, x, v); c := v; send 'ack' to scheduler; Read (Ti, x) if x cache then c := Fetch(x); send 'ack' to scheduler; Commit(Ti) committed := committed {Ti}; send 'ack' to scheduler; active := active \ {Ti}; Abort(Ti) for each x updated by Ti do; if x cache then c := Fetch(x); c := bi(x,ti); /* before image end do; aborted := aborted {Ti}; send 'ack' to scheduler; active := active \ {Ti}; 6-48

13 Beispiel: Nokeep/Noforce (Fortsetzung) Beispiel Keep/Force mit Schattenspeicher Restart for each cache slot c do; c := empty; end do; redone := ; undone := ; while LSN > 0 and redone undone database do (Ti, x, v) = log[lsn]; if x redone undone then begin if x cache then c := allocate(x); if Ti committed then begin c := v; redone = redone {x}; end; else begin c := bi(x, Ti); undone = undone {x}; end; end; LSN := LSN-1; end do; for each Ti active committed do active := active \ {Ti}; end do; send 'ack' to scheduler; Keep/Force bildet das andere Ende des Spektrums. Das Verfahren benötigt keinen Aufwand beim Neustart, da sich der stabile Speicher immer in einem konsistenten Zustand befindet. Voraussetzung jedoch ist, daß es gelingt, die Commit-Operation (einschließlich des Schreibens in den stabilen Speicher) atomar durchzuführen. Dazu gibt es das sogenannte Schattenspeicherverfahren: Änderungen von Transaktionen überschreiben nicht den alten Wert, sondern legen neue Versionen an. Jede Transaktion unterhält zwei Verzeichnisse, die Verweise auf die Datenwerte enthalten. Eines der beiden Verzeichnisse zeigt auf die bestätigten Werte, das andere auf geänderte Werte (shadow pages). Bei Abbruch werden die Schattendaten gelöscht. Bei Commit wird der Zeiger vom bisherigen auf das Schattenverzeichnis umgelegt Master Directory Copy 0 Directory Copy 1 x y z x y z Last committed value of x Last committed value of y Last committed value of z Ti s new version of x Ti s new version of y Master Directory Copy 0 Directory Copy 1 x y z x y z Last committed value of x Last committed value of y Last committed value of z Ti s new version of x Ti s new version of y Master Directory Copy 0 Directory Copy 1 x y z x y z 6-51 Shadow version of x Shadow version of y Last committed value of z Last committed value of x Last committed value of y