Koordinationssobjekte

Transkript

1 3 Koordination nebenlšufiger Prozesse 3.1 Elementare Koordinationsoperationen EinfŸhrung Wenn Prozesse unabhšngig und isoliert voneinander ablaufen, besteht keine Notwendigkeit zur Koordination Koordinationssobjekte Kooperationen manifestieren sich in eigenstšndigen Objekten Prozess Prozess Koordinationsobjekt Koordination ist jedoch erforderlich bei Kooperation: Prozesse arbeiten an einer gemeinsamen Aufgabe und mÿssen interagieren, z.b. sich synchronisieren Beispiel: Ein Prozess fÿllt einen Pufferplatz mit Daten, die von einem anderen Prozess Ÿber eine Datenleitung Ÿbertragen werden sollen. Konkurrenz: Prozesse stehen im Wettbewerb um gemeinsame Betriebsmittel, die exklusiv belegt werden mÿssen. Auch dafÿr mÿssen sie sich synchronisieren Beispiel: Zwei Prozesse wollen je eine Datei auf einem Drucker ausgeben Diese Koordinationsobjekte tragen einen Namen bestehen aus - Koordinationsoperationen - Koordinationsdaten Operationen Daten Beziehungen An einer Koordination kšnnen mehr als zwei Prozesse beteiligt sein Signalisierung Bei der Signalisierung soll eine einfache Reihenfolgebeziehung hergestellt werden. Ein Abschnitt B einem Prozess P2 soll nach einem Abschnitt A in einem Prozess P1 ausgefÿhrt werden. P2 wartet auf die Beendigung des Abschnitts A durch P1 1:1- Koordination m:n - Koordination Ein Prozess kann an mehreren Koordinationen beteiligt sein P1 kann auch eine GerŠtetŠtigkeit (E/A-Operation) darstellen. Dazu werden die Operationen signal und wait angeboten, die eine gemeinsame binšre Variable s benutzen P1 A P2 signal(s) wait(s) B 1 Koordinationsobjekt mehrere Koordinationsobjekte

2 Grundformen der Signalisierung In ihrer einfachsten Form kšnnen die Operationen folgenderma en realisiert werden: signal(s) set s no wait(s) s set? reset s Dies bedeutet ein aktives Warten (busy waiting) an der Signalisierungsvariablen s. Ist die Wartezeit zu lange, so sollte der Prozessor freigegeben werden: (Signalisieren mit Wartezustand) signal(s) set s process waiting? yes deblock process wait(s) s set? reset(s) no block Beispiel fÿr Signalisierungsobjekt module one_to_one_signalization; export SIGNAL, WAIT; import DEBLOCK, BLOCK; var signal_object = record S: signal = reset; // initialization WP: process = empty procedure SIGNAL(SO: signal_object); SO.S := set; if SO.WP /= empty then // a process is waiting DEBLOCK(SO.WP) // deblock it procedure WAIT(SO: signal_object); if SO.S = reset then BLOCK(SO.WP); SO.S := reset end signalization. // wait for signal Wechselseitige (symmetrische) Signalisierung Beispiel fÿr Implementierung Ein symmetrischer Einsatz der Operationen bewirkt, dass sowohl A1 als auch A2 ausgefÿhrt sind, bevor B1 oder B2 ausgefÿhrt werden. P1 A1 signal(s1) wait(s2) B1 P2 A2 signal(s2) wait(s1) B2 Die Prozesse P1 und P2 synchronisieren sich an dieser Stelle. Wir kšnnen das Operationspaar als eine Operation sync zusammenfassen: P1 A1 sync(s) B1 P2 A2 sync(s) B2 module synchronization; export SYNC; import DEBLOCK, BLOCK; var signal_object = record S: signal = reset; // initialization WP: process = empty procedure SYNC(SO: signal_object); if SO.S = reset // I am first and then SO.S := set; // indicate my arrival and BLOCK(SO.WP); // wait for my partner else // I am second and DEBLOCK(SO.WP); // deblock my waiting partner SO.S:= reset // and reset the signal for reuse end end synchronization. Da P1 und P2 an dieser Stelle aufeinander warten, spricht man auch von einem Rendezvous

3 3.1.3 Kritische Abschnitte Beispiel: Ein Prozess fÿgt ein Element in eine doppelt verkettete Liste ein, ein anderer Prozess greift nebenlšufig ebenfalls auf die Liste zu Listenoperation ãeinfÿgenò aufgelšst in Einzelschritte (a) Kritischer Abschnitt Noch ein Beispiel: Zwei Prozesse P1 und P2 inkrementieren eine gemeinsame Variable s. Der Ablauf beider Prozesse wÿrde demnach den Wert der Variablen um 2 erhšhen. Aufgelšst in Maschinenbefehle kšnnte sich in einem Einprozessorsystem mit VerdrŠngung (oder auch in einem Mehrprozessorsystem) eine Befehlsfolge ergeben, bei der eine Erhšhung verlorengeht: (b) (c) P1 s := s+1 P2 s := s+1 P1 load s add 1 store s P2 load s add 1 store s Speicherzelle s s = 4 s = 5 s = 5 (d) (e) Die beiden Prozesse Eine AusfŸhrung der beiden Prozesse In den Situationen c) und d) sieht ein zweiter Prozess eine inkonsistente Listenstruktur Kritische Abschnitte Anforderungen an den Umgang mit kritischen Abschnitten NebenlŠufiger Zugriff von Prozessen auf gemeinsame Daten schafft offensichtlich Probleme. Man nennt eine Operationsfolge, bei der ein nebenlšufiger Zugriff oder eine verzahnte AusfŸhrung zu Fehlern fÿhren kann, ist einen kritischer Abschnitt (critical section). Ein kritischer Abschnitt darf immer nur von hšchstens einem Prozess betreten werden. Prozesse mÿssen sich gegenseitig ausschlie en (mutual exclusion) P1 Kritischer Abscnitt Datenstruktur P2 Kritischer Abscnitt Gegenseitiger Ausschluss: Hšchsten ein Prozess im kritischen Abschnitt Keine Verzšgerung anderer Prozesse in unkritischen Abschnitten Keine Verklemmung: Prozesse dÿrfen sich nicht gegenseitig blockieren Kein Verhungern: Ein Prozess muss nach endlicher Zeit den kritischen Abschnitt betreten kšnnen Verzšgerungsfreies Betreten des kritischen Abschnitts, wenn er frei ist Endliche Aufenthaltszeit im kritischen Abschnitt Keine Annahmen Ÿber die relative Prozessgeschwindigkeit Keine Annahmen Ÿber die Anzahl der Prozesse Keine Annahmen Ÿber die Reihenfolge der Prozesse

4 Lšsungsversuch 3-13 Wir betrachten den folgenden Einsatz von elementaren Signalisierungsoperationen (vgl. 3-6) P1 wait(s) A signal(s) s = set P2 wait(s) B signal(s) A und B kšnnen nicht nebenlšufig ausgefÿhrt werden: Entweder A vor B oder B vor A, d.h. es findet keine berlappung in der AusfŸhrung von A und B statt. Die AusfŸhrungen von A und B schlie en sich gegenseitig aus (mutual exclusion) Die Signalisierungsoperationen kšnnen anscheinend auch dazu verwendet werden, um kritische Abschnitte zu sichern. Szenario 3-14 Drei Prozesse wollen einen mit signal und wait gesicherten kritischen Abschnitt betreten P1 P2 P3 wait(s): s set? yes reset s enter critical section signal(s) set(s) process waiting? yes deblock wait(s): s set?: no block (P2 becomes ready) enter critical section wait(s): s:set? yes reset s enter critical section P2 und P3 betreten den kritischen Abschnitt: der gegenseitige Ausschluss hat versagt. Warum? Sperren 3-15 Wir korrigieren das wait aus (3-5, bzw. 3-6) entsprechend und geben den Operationen besser passende Namen: Sperren (lock) und Entsperren (unlock) lock(s) s set? block set s no Initialisierung: s = reset unlock(s) reset s process waiting? no deblock process Von der Struktur entspricht das lock dem wait und das unlock dem signal. Anmerkung: Im Unterschied zur Formulierung des signal weiter oben wird hier jedoch die Variable s in einer Schleife abgefragt, um den Fall zu berÿcksichtigen, dass zwischen dem Deblockieren des auf die Sperre wartenden Prozesses und dem Setzen der Sperre ein weiterer Prozess die Sperre setzen kšnnte. Implementierungsbeispiel module locking; export LOCK, UNLOCK; import DEBLOCK, BLOCK; var lock_object = record L: lock_variable = reset; // initialization WP: queue of process = empty procedure LOCK(LO: lock_object); while LO.L = set do BLOCK(LO.WP); // enqueue process LO.L := set; procedure UNLOCK(LO: lock_object); LO.L := reset; if LO.WP = non_empty then // a process is waiting DEBLOCK(LO.WP) // deblock first of queue end locking. 3-16

5 Semaphore Beispielimplementierung Sperrobjekte zur Sicherung kritischer Abschnitte sind in der Betriebssystemliteratur auch unter dem Begriff ãsemaphorò bekannt. EingefŸhrt ca 1965 von E.W. Dijkstra ist ein Semaphor eine Art ZŠhlsperre S, deren Operationen P(S) und V(S) statt LOCK(S) und UNLOCK(S) genannt wurden. P (entspr. lock) dekrementiert einen ZŠhler, V (entspr. unlock) inkrementiert diesen ZŠhler. (Daher verwendet man manchmal auch die Bezeichner DOWN(S) und UP(S).) Semaphore gibt es in verschiedenen Varianten ZŠhler / binšre Variable Initialisierung mit 0 / mit einem Wert k > 0 Als ãzšhlsperrenò sind sie mšchtiger als einfache binšre Sperren. Man kann z.b. erreichen, dass sich hšchstens k Prozesse in einem Bereich aufhalten. module semaphore_synchronization; export P, V; import DEBLOCK, BLOCK; var semaphore = record C: integer = 1; // process counter // C=1: free, C<=0: occupied // if C<0 : C is the number of // waiting processes WP: queue of process = empty procedure P(S: semaphore); S.C := S.C-1; if S.C < 0 then BLOCK(S.WP); // enqueue process procedure V(S: semaphore); S.C := S.C+1; if S.C <= 0 then DEBLOCK(S.WP) // deblock first of queue end semaphore Szenario Zwei Prozesse wollen einen mit lock und unlock gesicherten kritischen Abschnitt betreten P1 P2 lock(s): s set? no lock(s): s set? no set s enter critical section set s enter critical section Probleme durch verzahnte AusfŸhrung Es kann nicht ausgeschlossen werden, dass zwischen der Abfrage der Bedingung und der Aktion ein Umschalten stattfindet und vor der RŸckkehr zum unterbrochenen Prozess ein anderer Prozess die Bedingung Šndert. Pi Pj no condition yes action autom. Umschalten condition := no P1 und P2 betreten den kritischen Abschnitt. Der Gegenseitige Ausschluss hat versagt Was ist passiert? 3-19 Das Auswerten der Bedingung und die Aktion darauf mÿssen als zusammen als unteilbare Aktion realisiert, werden, d.h. sie bilden einen kritischen Abschnitt! Zur Sicherung eines kritischen Abschnitts haben wir Operationen eingefÿhrt, die selbst einen (kurzen) kritischen Abschnitt darstellen! Wie lšsen wir diese Rekursion auf? 3-20

6 Realisierung der Unteilbarkeit elementarer Koordinationsoperationen Einprozessorsystem Besitzt der Prozessor keinen Unterbrechungsmechanismus, so kann auch keine Unterbrechung der kritischen Koordinationsoperation stattfinden. Besitzt der Prozessor einen Unterbrechungsmechanismus, so kann fÿr die Dauer der kritischen Operation die Unterbrechungssperre gesetzt werden, Dadurch haben wir das Problem auf den vorigen Fall zurÿckgefÿhrt. Signale von Peripherie Unterbrechungssperre Prozessor Dies gelingt aber nur bei Einprozessormaschinen. Im Mehrprozessorsystem kann es trotz Unterbrechungsverbot zu einer verzahnten AusfŸhrung von kritischen Operationen kommen, wenn sie eben simultan auf zwei Prozessoren bearbeitet werden, deren Speicherzugriffe dann verzahnt ablaufen. FŸr diesen Fall mÿssen wir uns etwas Neues ausdenken Maskenregister Die Kernoperation wird dann durch ein disable interrupt und enable interrupt geklammert. disable interrupt critical operation enable interrupt Mehrprozessorsystem Unteilbare Maschinenoperation Wir verwenden ein sync-flag (binšre Variable) mit aktivem Warten, um eine Koordinationsoperation als kritischen Abschnitt zu sichern: yes Prozessor 1 Prozessor 2 sync_flag set? set sync_flag critical operation reset sync_flag sync_flag set? set sync_flag critical operation reset sync_flag yes In Mehrprozessorsystemen ist die Unterbrechung nicht ausreichend. Um die Rekursion aufzulšsen, gibt es i.d.r. einen Maschinenbefehl, der in einer unteilbaren Operation den Wert einer Bedingungsvariable abfragt und sie gleichzeitig setzt: test_and_set(reg, x) := {load reg, x; x:=1} UnabhŠngig von ihrem Wert wird die Variable x auf 1 gesetzt. Galt x=0, so wird x auf 1 gesetzt, andernfalls bleibt der Wert unveršndert bei 1. Solche Maschinenbefehle haben z.t. unterschiedliche Namen (compare-and-swap, fetchand-add,..) und auch z.t. unterschiedliche Semantik. Gemeinsam ist jedoch das unteilbare Abfragen und Schreiben einer Variable. Leider hilft das nichts! Wir erhalten dieselbe Situation wie in 3-27 Diese Lšsung ist falsch!

7 Lšsung fÿr Multiprozessorfall Mit Verwendung des test-and-set-befehls kann dann eine richtige Lšsung angegeben werden: yes sync_flag set? set sync_flag critical operation reset sync_flag unteilbare Maschinenoperation Ist die Minisperre sync_flag belegt, so wird in einer Mini-Schleife der Wert immer wieder abgefragt. Man nennt dies ãaktives WartenÒ (busy waiting). Eine solche Sperre wird auch als ãspin lockò bezeichnet. Aktives Warten bedeutet eine gewisse Verschwendung von RechenkapazitŠt, kann aber toleriert werden, da Kooperationsoperationen relativ kurz sind. Wichtiger Hinweis Alle bisher eingefÿhrten Operationen zur Koordination von Prozessen (signal/wait, lock/unlock, P/V) bilden kurze kritische Abschnitte! FŸr alle diese Operationen muss ihre Unteilbarkeit sichergestellt sein. Dies kann - je nach Situation - durch Unterbrechungssperren oder unteilbare Maschinenoperationen realisiert werden. Wir gehen jetzt davon aus, dass alle Operationen zur Prozessinteraktion entsprechend geschÿtzt sind Software-Lšsung fÿr gegenseitigen Ausschluss Obwohl fast immer auf Unterbrechungssperren und unteilbare Maschinenoperationen zurÿckgegriffen werden kann, ist ein gegenseitiger Ausschluss auch ohne Hardware- UnterstŸtzung zu realisieren. Die auf Peterson (1981) zurÿckgehende Lšsung sei fÿr den Spezialfall von nur 2 Prozessen hier skizziert. Sie kann auf n Prozesse erweitert werden. Mit interested_x gibt der jeweilige Prozess x seine Eintrittsabsicht kund. Die Variable favored_process wird nur wirksam, wenn beide Prozesse interessiert sind und bewirkt eine Entscheidung (in diesem Fall fÿr den, der zuerst kommt) Prozess 1 Prozess Monitor Der gegenseitige Ausschluss funktioniert nur, wenn sich alle Teilnehmer daran halten und die lock- und unlock-operationen korrekt einsetzen. Es ist daher besser, die korrekte Nutzung der Operationen zu erzwingen. Dies gilt insbesondere fÿr Anwendungsprogrammierer. Manche Programmiersprachen stellen daher Objekte zur VerfŸgung, die den Umgang mit kritischen Abschnitten erleichtern. interested_1 := true favored_process := 2 interested_2 := true favored_process := 1 Ein solches Objekt, das den gegenseitigen Ausschluss sicherstellt, ohne dass der Programmierer explizit Sperroperationen einfÿgt, hei t Monitor. yes favored_process = 2 && interested_2? critical operation interested_1 :=false favored_process = 1 && interested_1? yes critical operation interested_2 :=false Ein Monitor ist ein Objekt, bestehend aus Prozeduren und Datenstrukturen, das zu jedem Zeitpunkt nur von einem Prozess benutzt werden darf. Ein Monitor wird Ÿblicherweise auf Sprachebene angeboten und muss auf simplere Koordinationsmechanismen (z.b. Semaphore) abgebildet werden

8 Monitor Beispiel Monitor: Das Setzen und Freigeben der Sperren geschieht automatisch. Au er den Entry-Prozeduren kšnnen ggf. weitere interne Prozeduren existieren, die keine Sperren verwenden. Mehrere Prozesse benutzen einen gemeinsamen beschršnkten Pufferbereich: Prozesse kšnnen Daten dort ablegen: deposit(data) Prozesse kšnnen Daten dort abholen: fetch(data) LOCK(S) LOCK(S) LOCK(S) Entry-Prozeduren Neben der Sicherstellung des gegenseitigen Ausschlusses (automatisch durch Monitor) mÿssen offensichtlich noch weitere Bedingungen berÿcksichtigt werden: deposit darf nur aufgerufen werden werden, wenn noch Platz im Puffer fetch darf nur aufgerufen werden, wenn Puffer nicht leer UNLOCK(S) UNLOCK(S) UNLOCK(S) Sperrvariable S 1 n Kooperationsdaten interne Prozedur belegt frei head fetch tail deposit Beispiel Monitor: monitor module bounded_buffer; entry FETCH, DEPOSIT; import BLOCK; DEBLOCK; var buffer_object record array buffer[1:n] of datatype head integer = 1; tail: integer = 1; count: integer =0; WPD, WPF: queue of process = empty; procedure DEPOSIT(BB: buffer_object, data: datatype); blockiert auch while BB.count =n do BLOCK(BB.WPD); den Monitor BB.buffer[BB.tail] := data; BB.tail := BB.tail mod n +1; BB.count := BB.count +1; if BB.WPF /= empty then DEBLOCK(BB.WPF) procedure FETCH(BB: buffer_object, result: datatype); blockiert auch while BB.count =0 do BLOCK(BB.WPF); den Monitor result := BB.buffer[head]; BB.head := BB.head mod n +1; BB.count := BB.count -1; if BB.WPD /= empty then DEBLOCK(WPD ) end bounded_buffer; 3-31 Bedingungssynchronisation 3-32 WŠhrend ein Prozess auf eine Bedingungsvariable (im Beispiel: nicht leer / nicht voll) wartet, muss der Monitor fÿr andere Prozesse freigegeben werden. Die gerade gezeigte Lšsung 3-31 fÿhrt daher zu einer wechselseitigen Blockierung (Verklemmung). Zu diesem Zweck gibt es im Zusammenhang mit Monitoren auf Sprachebene das Konzept der Bedingungssynchronisation: Zwei Operation sind vorgesehen, um die Bedingungssynchronisation zu realisieren wait_c(c) signal_c(c) Prozess gibt Monitor frei und wartet auf das nachfolgende signal_c(c), d.h. das Eintreten der Bedingung c. Danach setzt er im Monitor fort Der Prozess wird auf jeden Fall blockiert! Ein wartender Prozess wird freigegeben. Der Monitor ist wieder belegt. Gibt es keinen wartenden Prozess, so hat die Prozedur keinen Effekt. Die wartenden Prozesse werden (wie auch bei der Signalisierung oder den Semaphoren) in einer Warteschlange verwaltet. Achtung: Beachte den Unterschied zu den Signalisierungsoperationen signal / wait!

9 Beispiel Monitor II (mit Bedingungssynchronisation) monitor module bounded_buffer; entry FETCH, DEPOSIT; import WAIT_C; SIGNAL_C var buffer_object; record array buffer[1:n] of datatype head integer = 1; tail: integer = 1; count: integer = 0; not_full: cond = true; not_empty: cond = false; procedure DEPOSIT(BB: buffer_object, data: datatype); while BB.count =n do WAIT_C(BB.not_full); buffer[tail] := data; BB.tail := BB.tail mod n +1; BB.count := BB.count +1; SIGNAL_C(BB.not_empty) procedure FETCH(BB: buffer_object, result: datatype); while BB.count =0 do WAIT_C(BB.not_empty); result := BB.buffer[head]; BB.head := BB.head mod n +1; BB.count := BB.count -1; SIGNAL_C(BB.not_full) end bounded_buffer; 3-33 Leser-Schreiber-Koordination (Reader-Writer-Problem) 3-34 Nicht alle Prozesse greifen schreibend auf die gemeinsamen Daten zu. Einige lesen nur. Lesezugriffe sind unkritisch. In dem Kooperationsabschnitt dÿrfen sich daher entweder 1 Schreiber oder beliebig viele Leser aufhalten Verallgemeinerung: Es gebe k Sorten von Prozessen. Im Abschnitt dÿrfen sich c 1 Prozesse der Sorte 1 und/oder c 2 Prozesse der Sorte 2 und/oder É c k Prozesse der Sorte k aufhalten Das Leser-Schreiber-Problem ist dann ein Spezialfall mit k=2, c 1 =1 und c 2 = Wenn ein Schreiber den Abschnitt verlšsst und sowohl Leser also auch Schreiber warten, so kann man: nur die Schreiber deblockieren (Schreibervorrang) nur die Leser deblockieren (Leservorrang) alle deblockieren: dann hšngt es vom Scheduling-Verfahren ab (ohne Vorrang) Leser-Schreiber-Kooperation (Schreibervorrang) 3-35 monitor module reader/writer-cooperation entry: RW_LOCK, RW_UNLOCK; import SIGNAL_C, WAIT_C; var RW_LOCK_object record R_COUNT: integer = 0; // counts readers FREE_TO_READ: cond = true; // no writers active W_COUNT: integer = 0; // counts writers FREE_TO_WRITE: cond = true; // no writer or reader active procedure RW_LOCK(LO:RW_LOCK_object; type:{r,w}) if type = R then while LO.W_COUNT>0 do WAIT_C(LO.FREE_TO_READ); LO.R_COUNT:=LO.R_COUNT+1; SIGNAL_C(LO.FREE_TO_READ); else LO.W_COUNT:=LO.W_COUNT+1; while LO.W_COUNT>1 or LO.R_COUNT>0 do WAIT_C(LO.FREE_TO_WRITE) procedure RW_UNLOCK(LO:RW_LOCK_object; type:{r,w}) if type = R then LO.R_COUNT:=LO.R_COUNT-1; if LO.R_COUNT=0 then SIGNAL_C(LO.FREE_TO_WRITE) else LO.W_COUNT:=LO.W_COUNT-1; if LO.W_COUNT>0 then SIGNAL_C(LO.FREE_TO_WRITE) else SIGNAL_C(LO.FREE_TO_READ) end reader/writer-cooperation. Leser-Schreiber-Koordination (ohne Vorrang) 3-36 monitor module reader/writer-cooperation entry: RW_LOCK, RW_UNLOCK; import SIGNAL_C, WAIT_C; var RW_LOCK_object record R_COUNT: integer = 0; // counts readers FREE_TO_READ: cond = true; // no writers active W_COUNT: integer = 0; // counts writers FREE_TO_WRITE: cond = true; // no writer or reader active procedure RW_LOCK(LO:RW_LOCK_object; type:{r,w}) if type = R then while LO.W_COUNT>0 do WAIT_C(LO.FREE_TO_READ); LO.R_COUNT:=LO.R_COUNT+1; SIGNAL_C(LO.FREE_TO_READ); else while LO.W_COUNT>0 or LO.R_COUNT>0 do WAIT_C(LO.FREE_TO_WRITE) LO.W_COUNT:=LO.W_COUNT+1; procedure RW_UNLOCK(LO:RW_LOCK_object; type:{r,w}) if type = R then LO.R_COUNT:=LO.R_COUNT-1; if LO.R_COUNT=0 then SIGNAL_C(LO.FREE_TO_WRITE) else LO.W_COUNT:=LO.W_COUNT-1; SIGNAL_C(LO.FREE_TO_READ); // all processes SIGNAL_C(LO.FREE_TO_WRITE) // are deblocked end reader/writer-cooperation.

10 3.2 Transaktionen EinfŸhrung 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 Beispiel: Bankensoftware T1: 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); T2: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 T1: 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); T2:sum_up(account_1, account_2, sum) temp1 := READ(account_1); temp2 := READ(account_2); sum := temp1 + temp2; Verzahnte AusfŸhrung bewirkt fÿr T2 eine inkonsistente Sicht auf die Daten! T1: 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); T2: 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); 3-39 Durch die Verzahnung geht eine berweisung (T2) verloren: lost update -Problem 3-40

11 Beispiel (Fortsetzung 3): Ausfall T1: 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); Transaktion Entsprechende Kennzeichnung (Klammerung) macht einen Programmabschnitt zur Transaktion: T1:transfer(account_1, account_2, amount) START (oder auch BOT (= 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) Operation wurde zur HŠlfte durchgefÿhrt und hinterlšsst einen inkonsistenten Zustand der Daten Eine Transaktion ist eine Folge von Operationen, die in ihrer Wirkung atomar sein soll Grundlagen Operationen in Transaktionen 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 Anforderungen an Transaktionen (ACID-Principles) Atomicity Consistency 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. Transaktionsoperationen: START Beginn der Transaktion ABORT Abbruch der Transaktion (impliziert RŸcksetzen (Rollback)) COMMIT Ende der Transaktion Wir nehmen an, dass dem ersten Datenzugriff ein START automatisch vorangeht. Wir lassen daher im folgenden der Einfachheit halber das START weg. Isolation Durability Isolation Zwischenergebnisse einer Transaktion sind fÿr andere Transaktionen nicht sichtbar. Dauerhaftigkei: Die nderungen einer beendeten und bestštigten (committed) Transaktion kšnnen weder verloren gehen noch rÿckgšngig gemacht werden

12 T1 T2 T3 Tn Die ACID-Eigenschaften sind gefšhrdet durch Interferenz nebenlšufiger Transaktionen (Konsistenz, Isolation) fehlerhafte Umgebung (AtomaritŠt, Dauerhaftigkeit) Transaktionssysteme benštigen daher Massnahmen zur Koordination von Transaktionen (Concurrency Control) Erhaltung und Wiederherstellung 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 start, read, write, abort, commit Transaktionsverwalter (transaction manager) Rücksetzer (recovery manager) Zustände von Transaktionen COMMIT Beendet (partially committed) TV_COMMIT Bestätigt (committed) Transaktionen und PlŠne (Schedules) Def. Eine Transaktion T i ist eine Folge von Schreib- oder Leseoperationen (w i oder r i ), abgeschlossen durch entweder ein Commit (c i ) oder ein Abort (a i ). Eine Transaktion ist also in sich seriell, d.h. ihre Operationen werden streng hintereinander ausgefÿhrt. Undefiniert (undefined) START Aktiv (active) TV_ABORT Undefiniert (undefined) Man kann eine Transaktion auch als Menge von Operationen mit einer Totalordnung < i auffassen. ABORT Wenn mehrere Transaktionen verzahnt ausgefÿhrt werden, kann es zu Konflikten kommen: 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

13 Plan 3-49 Die nebenlšufige, verzahnte AusfŸhrung einer Menge von Transaktionen bildet einen Plan (schedule) 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) 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) r1(x) r2(x) w3(x) w1(x) w2(y) w3(y) c1 Bestätigte Projektion von S a2 c3 RŸcksetzbarkeit T1 Write(x) Abort T2 Read(x) Commit Dieser Plan ist nicht rÿcksetzbar, da T2 bereits bestštigt ist, obwohl ungÿltige Daten gelesen wurden Def.: Def.: 3-50 Transaktion Ti liest von Transaktion Tj, wenn Ti Datenelemente liest, die vorher von Tj geschrieben wurden. 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 Lesen unbestštigter Daten (dirty read) T1 T2 T3 Write(x) Abort Read(x) Write(y) Commit Read(y) Commit Dieser Plan ist rÿcksetzbar, bewirkt jedoch das RŸcksetzen von T2 und T3. Def.: Ein Plan S vermeidet einen kaskadierenden Abbruch (avoiding cascading abort, S ACA) wenn keine Transaktion aus S unbestštigte Daten liest. berschreiben unbestštigter Daten (dirty write) (Annahme: vor Beginn der Transaktionen sei x=1) T1 Write(x,2) Commit T2 Write(x,3) Abort Hier muss sichergestellt werden, dass der alte Wert (x=2) (before-image) wiederhergestellt wird. T1 Write(x,2) Abort T2 Write(x,3) Commit Hier ist es unnštig, den alten Wert (x=1) wiederherzustellen, da x anschlie end Ÿberschrieben wurde

14 berschreiben unbestštigter Daten (dirty write) Serialisierbarkeit T1 Write(x,2) Abort T2 Write(x,3) Abort Hier muss 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. Interferenzprobleme zwischen Transaktionen werden vermieden, wenn Transaktionen seriell ausgefÿhrt werden. Def.: 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 Wenn wir annehmen, dass eine Transaktion in sich korrekt ist, d.h. die Daten in einem konsistenten Zustand hinterlšsst, 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: Def.: Daten Ein Plan S hei t strikt (S ST ), wenn von keiner Transaktion aus S unbestštigte gelesen oder Ÿberschrieben werden. Def.: Zwei PlŠne S und SÕ hei en Šquivalent, wenn sie dieselben Ausgabewerte liefern und denselben Datenzustand zurÿcklassen. «Def.: Ein Plan S hei t serialisierbar ( S SR), wenn seine bestštigte Projektion C(S) zu einem seriellen Plan Šquivalent ist Serialisierbarkeit 3-55 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. Def.: 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: Def.: Ein Plan S hei t korrekt, wenn er serialisierbar und rÿcksetzbar ist. Beispiel: S 1 S 2 S 3 S 4 r 1 (x) r 1 (y) w 1 (y) w 1 (x) c 1 w 2 (x) r 2 (z) w 2 (y) c 2 r 1 (x) r 1 (y) w 1 (y) w 1 (x) c 1 w 2 (x) r 2 (z) w 2 (y) c 2 r 1 (x) r 1 (y) w 1 (y) w 1 (x) c 1 w 2 (x) r 2 (z) w 2 (y) c 2 r 1 (x) r 1 (y) w 1 (y) w 1 (x) c 1 w 2 (x) r 2 (z) w 2 (y) c 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 (unterschiedliche Konfliktauflšsung) Lediglich S 4 ist serialisierbar, d.h. Šquivalent zum seriellen Plan T 2 < S T 1.

15 Serialisierbarkeitstheorem Serialisierungsgraph (AbhŠngigkeitsgraph) 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) w3(x) r2(x) w3(y) w2(x) c3 c2 Plan S Zusammenhang der Eigenschaften (Mengendiagramm) Rücksetzbare Pläne RC kaskadierenden Abbruch vermeidende Pläne ACA Serialisierbare Pläne SR r1(x) w1(y) c1 Strikte Pläne ST Serielle Pläne T1 T3 T2 Serialierungsgraph SG(S) Theorem (Serialisierbarkeitstheorem) Korrekte Pläne Ein Plan S ist genau dann konfliktserialisierbar, wenn sein Serialisierungsgraph SG(S) azyklisch ist Koordination von Transaktionen Da die Konsistenzwahrung automatisch geschehen soll, muss 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 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 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 Daten

16 SperrenvertrŠglichkeit read_lock write_lock read_lock + - write_lock - - 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. Das Zweiphasen-Sperrprotokoll (ZPP) (Two-Phase-Locking (2PL)) Mithilfe dieser Sperren lšsst sich ein Protokoll angeben, das die Forderung nach Serialisierbarkeit erfÿllt. 1. Eine Transaktion muss 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 Zweiphasen-Sperrprotokoll Modifikation: Striktes Zweiphasensperren Was passiert, wenn Forderung 3 nicht erfÿllt wird? T1 read_lock(x) read(x) read_unlock(x) write_lock(y) write(y) write_unlock(y) commit T2 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 T1 T2 T1, d.h. nicht serialisierbar 3-63 Das normale Zweiphasensperren erzeugt serialisierbare PlŠne, jedoch nicht unbedingt rÿcksetzbare: T1 write_lock(x) write(x) write_unlock(x) abort T2 read_lock(x) read(x) read_unlock(x) commit Daher zusštzliche Forderung: 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. 3-64

17 Anzahl Sperren Anmerkungen: Normales 2PL Das strikte Zweiphasen-Sperren ist das in der Praxis Ÿbliche Verfahren. c Zeit Die Sperren mÿssen nicht vom Programmierer gesetzt werden, sondern werden automatisch vom Planer (Scheduler) als Teil des TVS eingefÿgt und verwaltet. Anzahl Sperren Das 2PL kann (mit Ausnahme der konservativen Variante) zu Verklemmungen (deadlocks) fÿhren. Darauf wird spšter in einem speziellen Kapitel eingegangen. Anzahl Sperren c Zeit Zeit Striktes 2PL Konservatives 2PL 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 c Recovery 3-67 Bisher haben wir uns mit der Synchronisation von Transaktionen zur Sicherstellung der Konsistenz und Isolation befasst. Jetzt kÿmmern wir uns um die Forderung nach AtomaritŠt und Dauerhaftigkeit. Synchronisation (Concurrency Control) Atomicity Consistency Isolation Durability Wiederherstellung (Recovery) Dauerhaftigkeit und AtomaritŠt sind durch das Auftreten von Fehlern gefšhrdet. Es kšnnen mehrere Arten von Fehlern unterschieden werden. Fehlerarten 3-68 Transaktionsfehler Ursachen: Interne Konsistenzverletzung Entscheidung des Transaktionsverwaltungssystems (Verklemmung, externe Konsistenzverletzung, Scheduler) Ma nahmen Jegliche Wirkung dieser Transaktion ungeschehen machen (undo) Systemabbruch Ursachen Fehler im BS Hardwareausfall (Stromversorgung) Fehler im TVS Ma nahmen Wiederherstellung des letzten bestštigten Zustands: evtl. NachfŸhren bestštigter aber verlorengegangener nderungen evt. RŸckgŠngigmachen von nderungen nichtbestštigter Transaktionen Ausfall von Speichermedien Ursachen: Fehler im BS (Treibersoftware) Hardwarefehler: Kanal, Steuereinheit, Bus Mechanische Zerstšrung (head crash) Verlust der Magnetisierung Ma nahmen 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)

18 GrundsŠtzliche Sicherungstechniken Logging Der Zustand eines Datenobjekts entsteht durch die Folge von Datenoperationen, die darauf angewendet werden. Hat man sich diese Folge gemerkt (Log), so ist es mšglich, ausgehend von einem Anfangszustand, jeden mšglichen Zwischenzustand wiederherzustellen. Da dies in der Praxis zu aufwendig ist (Speicherplatz, Laufzeit beim Wiederherstellen), werden periodisch konsistente SchnappschŸsse (Checkpoints) erstellt. Das Log muss dann nur die nderungen seit dem letzten Checkpoint enthalten. FŸr den allgemeinen Fall benštigt der RM die folgenden beiden Operationen: undo: nderungen unbestštigter Transaktionen mÿssen rÿckgšngig gemacht werden redo: Verlorengegangene nderungen bestštigter Transaktionen mÿssen nachgefahren werden. Schattenspeicherverfahren Bei einer Datenoperation wird das alte Datum nicht Ÿberschrieben, sondern eine neue Version des Datums angelegt (shadow version) Zum Commit-Zeitpunkt wird dann die Schatten-Version zur gÿltigen (d.h. bestštigten) Version. Zusammenhang: Checkpoint und erforderliche Aktionen T1 T2 T4 letzter Checkpoint T3 T5 Ausfallzeitpunkt T1: keine Aktion erforderlich T2: redo T3: redo T4: undo T5: undo Zeit Komponenten und ihr Zusammenspiel Das Log Problem: Aus LeistungsgrŸnden werden Teile der Datenbasis im Hauptspeicher gehalten Inhalte des Hauptspeichers kšnnen im Fehlerfall verlorengehen Stabiler Speicher Log read write T1 T2 T3 Tn Planer (scheduler) recovery manager (RM) Pufferverwalter (cache manager) start, read, write, abort, commit read, write, abort, commit fetch flush Transaktion sverwalter (transaction manager) read write read, write Flüchtiger Speicher (Puffer, Cache) Zur Wiederherstellung 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 total geordnet und repršsentieren die AusfŸhrungsreihenfolge. Die Log-EintrŠge werden sofort nach der Operation in den stabilen Speicher gerettet

19 Das Log 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 Pufferverwaltung (Cache Manager, CM) 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 (nichtflÿchtigen) 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. Das Wiederherstellen als Operation muss idempotent sein: Pufferverzeichnis Puffer Jede Folge unvollstšndig durchgefÿhrter Wiederherstellungen gefolgt von einer vollstšndigen Wiederherstellung muss dasselbe Ergebnis haben wie genau eine vollstšndige Wiederherstellung Datenelement Zellennummer Zellennummer dirty bit Inhalt x ' ' y 'New York' : : : : : 3-74 Operationen Der Pufferverwalter unterstÿtzt vier Operationen Wiederherstellungsverfahren Die bei der Wiederherstellung zu ergreifenden Ma nahmen hšngen stark davon ab, wie RM und CM mit den Daten im Puffer umgehen: 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 Weitergabe von nderungen: 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 Ersetzungsstrategie: 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, dass sich im Puffer ausschlie lich unbestštigte, im stabilen Speicher ausschlie lich bestštigte Daten befinden. Dies bedeutet jedoch einen erhšhten Aufwand beim Betrieb. In der Praxis wšhlt man daher einen Kompromiss

20 Mšgliche Situationen Puffer (Hauptspeicher) Stabiler Speicher (Platte) bersicht Ÿber die Wiederherstellungsstrategien I Situation Art der Daten im Puffer Art der Daten im Benštigte stabilen Speicher Operation Benštigte Daten II III I nur unbestštigte nur bestštigte - - II bestštigte und unbestštigte III nur unbestštigte bestštigte und unbestštigte nur bestštigte redo after images undo before images IV IV bestštigte und unbestštigte bestštigte und unbestštigte redo und undo before und after images unbestätigte Daten bestätigte Daten Beispiel (Situation IV) 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}; Beispiel: Situation IV (Fortsetzung) 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 if x cache then c := allocate(x); if Ti committed then c := v; redone = redone {x}; else c := bi(x, Ti); undone = undone {x}; LSN := LSN-1; end do; for each Ti active committed do active := active \ {Ti}; end do; send 'ack' to scheduler;

21 Schattenspeicher (Shadowing) Eine Alternative zum Logging bildet das Schattenspeicher-Verfahren (Shadowing) Dazu gibt es das sogenannte Schattenspeicherverfahren: 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 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 version). Bei Abbruch werden die ãschattendatenò gelšscht. Bei Commit wird der Zeiger vom bisherigen auf das Schattenverzeichnis umgelegt. Voraussetzung dafÿr ist eine atomare AusfŸhrung der Commit-Operation (einschlie lich des Schreibens in den stabilen Speicher). Master Master Directory Copy 0 Directory Copy 1 Directory Copy 0 Directory Copy 1 x y z x y z 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 Shadow version of x Shadow version of y Last committed value of z Last committed value of x Last committed value of y