Was ist eine Transaktion?

Transkript

1 Frühjahrsemester 2013 CS243 Datenbanken Kapitel 8: Transaktionsverwaltung H. Schuldt Was ist eine Transaktion? Eine Transaktion ist eine Menge von logisch zusammengehörenden Operationen (zumeist in ein Programm eingebunden, aber auch interaktiv möglich) Im Fall von klassischen Datenbanktransaktionen beziehen sich alle Operationen (Lesen bzw. Schreiben von Datenobjekten) auf dasselbe Datenbanksystem Verteilte Transaktionen erlauben Operationen in verschiedenen Datenbanksystemen Transaktionen basieren auf einem generischen Abstraktionskonzept zum Kapseln der enthaltenen Operationen, um für diese bestimmte Ausführungsgarantien durchzusetzen Ausführungsgarantien abgeleitet von ACID-Eigenschaften Diese Garantien werden vom System transparent für den Anwendungsentwickler/ Benutzer bereitgestellt Anwendungsentwickler/Benutzer muss lediglich die Transaktionsgrenzen festlegen (BOT = Begin-of-Transaction bzw. EOT = End-of-Transaction), wird aber von allen anderen Aspekten zur Realisierung der Garantien befreit 8-2 1

2 Transaktionseigenschaften: ACID. Atomicity (Atomarität) Eine Transaktion wird entweder komplett ausgeführt ( commit ) oder erscheint so, als wäre sie nie gestartet worden, d.h. sie hinterlässt keine Effekte ( rollback ). Die Semantik einer Transaktion entspricht also einem Alles-oder-Nichts. Consistency (Konsistenz) Eine Transaktion führt die Datenbank von einem konsistenten Zustand in einen anderen konsistenten Zustand über Isolation Transaktionen, auch wenn parallel ausgeführt, erscheinen so als ob sie isoliert voneinander (d.h. sequentiell) ausgeführt werden Durability (Dauerhaftigkeit/Persistenz) Nach dem Commit einer Transaktion sind ihre Effekte dauerhaft, d.h. überleben auch Systemabstürze 8-3 Durchsetzen von Transaktionseigenschaften Transaktionen sind eine Art Vertrag zwischen einem Anwendungsprogramm und dem Laufzeitsystem der Datenbank Die ACID-Eigenschaften können dabei als Vertragsinhalt angesehen werden, durch welche die Aufgaben der Laufzeitumgebung festgeschrieben sind Die wichtigsten Aufgaben einer Infrastruktur zur Transaktionsverwaltung bestehen aus der korrekten Synchronisation paralleler, konkurrierender Transaktionen (Concurrency Control Æ Isolation) sowie der korrekten Behandlung von System- und Anwendungsfehlern (Recovery Ø Atomarität, Persistenz). Diese Unterscheidung spiegelt sich auch in den Komponenten der Infrastruktur zur Transaktionsverwaltung wieder Für beide Bereiche (Concurrency Control und Recovery) bedarf es zunächst einer eingehenden Untersuchung, was jeweils korrekt bedeutet T Korrektheitskriterien Concurrency Control: Serialisierbarkeitstheorie Recovery: Fehlererholung / Crash-Recovery Auf der Basis dieser Korrektheitskriterien müssen dann Systeme entwickelt werden, welche die verlangten Garantien durchsetzen T Concurrency Control- bzw. Recovery-Protokolle 8-4 2

3 Transaktionsverwaltung Beispiel Szenario: Banküberweisung Klassischer Vertreter von Datenbanktransaktionen Kurzlebige Transaktionen, operieren auf wenigen Datenobjekten Parallele Zugriffe auf Konto-Relationen (bzw. Objekte) Konto (KontoNr, KundenNr, FilialNr, Kontostand) Typische Operationen (z.b. reslisiert durch Embedded SQL-Programme) Debit (KontoNr, Betrag) bucht Betrag von Konto KontoNr ab Credit (KontoNr, Betrag) bucht Betrag auf Konto KontoNr sowie Transfer (KontoNrA, KontoNrB, Betrag), das aus einem Debit(KontoNrA, Betrag) und einem Credit(KontoNrB, Betrag) besteht. 8-5 Transaktionsverwaltung Beispiel. Ich möchte 50.- SFr von meinem Konto abheben Ich möchte meiner Enkelin SFr überweisen Client Debit (4711, 50.- SFr) DBMS Client Transfer (0815, 4711, SFr) = Debit (0815, SFr) Credit (4711, SFr) DB Bank 8-6 3

4 Transaktionsverwaltung Beispiel: Atomarität Ich möchte 50.- SFr von meinem Konto abheben KontoNr Kontostand Ich möchte meiner Enkelin SFr überweisen SELECT kontostand INTO :balancetransa FROM Konto WHERE kontonr = 0815; t balancetransa := balancetransa - 200; Update Konto SET kontostand = :balancetransa Where kontonr = 0815; SELECT kontostand INTO :balancetransb FROM Konto WHERE kontonr = 4711; KontoNr Kontostand *** Programmabbruch *** Transaktionsverwaltung Beispiel: Atomarität Im vorigen Ablauf ist die Alles-oder-Nichts-Semantik der Atomarität verletzt Ein inkonsistenter Zwischenzustand bleibt erhalten (bei der fehlgeschlagenen Überweisung ging Geld verloren!) Abhilfe: für die durch den Systemabsturz abgebrochene Überweisungstransaktion sollte das bereits erfolgte Debit automatisch durch das Datenbanksystem rückgängig gemacht werden T Gefragt sind also geeignete Recovery-Protokolle, die beispielsweise den Zustand einspielen, der direkt vor Beginn der Überweisungstransaktion vorlag 8-8 4

5 Transaktionsverwaltung Beispiel: Isolation Ich möchte 50.- SFr von meinem Konto abheben SELECT Kontostand INTO :balanceatm FROM Konto WHERE NontoNr = 4711; balanceatm := balanceatm 50; Update Konto SET Kontostand = :balanceatm WHERE KontoNr = 4711; t KontoNr Kontostand SELECT Kontostand INTO :balancetransb FROM Konto WHERE KontoNr = 4711; balancetransb := balancetransb + 200; Update Konto SET Kontostand = :balancetransb WHERE KontoNr = 4711; 70.- KontoNr Kontostand Ich möchte meiner Enkelin SFr überweisen Transaktionsverwaltung Beispiel: Isolation Im vorigen Ablauf überschneiden sich die beiden Transaktionen in inkorrekter Weise Die Änderungsoperation der Überweisungstransaktion geht komplett verloren (und damit auch das überwiesene Geld). Das Phänomen wird auch als lost update bezeichnet Der korrekte Endzustand nach kompletter Ausführung beider Transaktionen wäre: KontoNr Kontostand T Das System muss daher die beiden Transaktionen durch geeignete Concurrency Control-Protokolle voneinander isolieren, indem z.b. die Überweisungstransaktion den Kontostand von 4711 erst lesen und verändern kann, nachdem die ATM-Transaktion beendet ist

6 Transaktionsverwaltung Beispiel: Isolation Problemtyp Inkonsistentes Lesen KontoNr Kontostand Transfer von 4711 nach 0815 Prüfen der Summe von 4711 und /* 0815.Kontostand = SFr. */ Update Konto SET Kontostand = Kontostand WHERE KontoNr = 0815; /* 0815.Kontostand = SFr. */ SELECT Kontostand INTO :A FROM Konto WHERE KontoNr = 4711; /* A = SFr. */ SELECT Kontostand INTO :B FROM Konto /* 4711.Kontostand = SFr. */ UPDATE Konto SET Kontostand = Kontostand WHERE Kontonr = 4711 /* 4711.Kontostand = SFr. */ t KontoNr Kontostand WHERE KontoNr = 0815; /* B = SFr. ; A+B = SFR */ 8-11 Transaktionsverwaltung Beispiel: Isolation Problemtyp "Phantomproblem" (Spezialfall des inkonsistenten Lesens) Schema: Abteilungen (AbtNr, AbtName, Budget,...) Angestellte (AngNr, Name, Adresse, Gehalt,..., AbtNr) Integritätsbedingung: Abteilungen.Budget = * (SELECT COUNT(*) FROM Angestellte WHERE Angestellte.AbtNr = Abteilungen.AbtNr ) Finanzprüfung Einstellung eines Mitarbeiters SELECT COUNT(*) FROM Angestellte WHERE AbtNr = 1 /* Resultat: 10 Angestellte */ INSERT INTO Angestellte VALUES (111, 'Hans Meier',..., 1) UPDATE Abteilungen SET Budget = Budget + 200'000 WHERE AbtNr = 1 SELECT Budget FROM Abteilungen WHERE AbtNr = 1 t /* Resultat: 2'200'000 SFr */

7 Transaktionsverwaltung Beispiel Weitere Anforderungen der Beispielanwendung Konsistenz z.b. Einschränkung, dass der Kontostand niemals negativ werden kann Dies wird, wie bereits bekannt, in der Regel durch Integritätsbedingungen zugesichert CREATE ASSERTION positiverkontostand CHECK (NOT EXISTS ( SELECT * FROM Konto WHERE Kontostand < 0 )) T Auch die Konsistenz wird vom System garantiert und muss nicht vom Anwendungsentwickler berücksichtigt werden Dauerhaftigkeit Änderungen am Kontostand durch korrekt (mit Commit) beendete Transaktionen müssen dauerhaft sein, also z.b. auch Systemabstürze überstehen Performanz Natürlich muss das System mehr als zwei Benutzer parallel unterstützen, ohne dass dabei die Synchronisation konkurrierender Transaktionen zu signifikanten Performance-Einbussen führt Read/Write-Modell Die wesentlichen Aspekte von Concurrency Control und Recovery werden auf der Basis des Read/Write-Modells (R/W-Modell) betrachtet Grundlegende Begriffe Datenbank (DB) Menge von Objekten: DB = {o 1, o 2, } Diese Menge ist statisch, Objekte sind in der Regel einzelne Datenseiten Operation (OP) Menge von Operationen: OP = {read, write} Aktion Aktion a œ (OP DB), also entweder read(o i ) oder write(o i ). read(o i ) liefert das Datenobjekt o i zurück write(o i ) schreibt Datenobjekt o i Im Folgenden werden wir die Aktionen in abgekürzter Schreibweise verwenden: r(o i ) für read(o i ) w(o i ) für write(o i ) SQL-Operationen müssen also auf Operationen im R/W-Modell abgebildet werden

8 Transaktion Transaktion (T) Eine Transaktion T ist ein Tupel mit T = ( ACT, < ) bestehend aus einer Menge von Aktionen ACT, zwischen denen eine (partielle) Ordnungsrelation < vorhanden ist Dabei ist: ACT = { a 1, a 2,, a k }» term a 1,, a k sind Aktionen term œ {C, A} ist Terminierungsaktion < (ACT ACT) ist Präzedenzrelation Jede Transaktion T ist entweder durch C (commit) oder A (abort) abgeschlossen. C bzw. A ist hinter allen Aktionen der jeweiligen Transaktion geordnet (bezüglich <), also a i < term für alle 1 i k. Die Präzedenzrelation < legt die Ausführungsreihenfolge der Aktionen einer Transaktion fest < partiell: Parallelität innerhalb einer Transaktion (intra-transaktionale Parallelität) erlaubt < total: sequentieller Ablauf (dies ist der Normalfall) T = ( a 1 < a 2 < < a k < C ) 8-15 Commit bzw. Abort Transaktionen werden dynamisch durch entsprechende DBS-Aufrufe des Anwendungsprogramms (bzw. durch Eingabe von SQL-Befehlen über die Konsole) erzeugt. In SQL gibt es dafür drei Anweisungen: CONNECT... (BOT = Begin-of-Transaction): kennzeichnet den Beginn einer Transaktion. COMMIT WORK bzw. COMMIT (EOT = End-of-Transaction): kennzeichnet das ("erfolgreiche") Ende einer Transaktion und erklärt alle Änderungen der Transaktion für gültig. ROLLBACK WORK bzw. ROLLBACK (RBT = Rollback-Transaction): kennzeichnet das ("erfolglose") Ende einer Transaktion (Abort) und erklärt alle Änderungen der Transaktion für ungültig. Implizit kennzeichnen EOT und RBT ausserdem den Beginn einer neuen Transaktion, die bis zum nächsten EOT, RBT oder DISCONNECT dauert

9 Wiederholung: DB-System-Modell Der TM leitet eingehende Operationen an den Scheduler weiter. Im Falle von verteilten DBMSen beinhaltet dies die Kommunikation sowie die Koordination verteilter Transaktionen. Der Scheduler entscheidet, ob Operationen ausgeführt, zurückgewiesen oder verzögert werden. Aufgabe des RM ist, die DB vor Systemfehlern zu schützen (z.b. wenn der transiente Speicher verloren geht) und zu garantieren, dass die Effekte abgeschlossener Transaktionen dauerhaft sind bzw. dass abgebrochene TA keine Effekte hinterlassen. Der CM (Pufferverwaltung) sorgt für einen effizienten Zugriff auf Daten. Transaktionen Transaktions- Manager (TM) Scheduler Recovery-Manager (RM) read / write Datenbank fetch / flush Cache-Manager (CM) persistenter Speicher read / write / commit / abort read / write / commit / abort read / write / commit / abort flush fetch Log read / write DBMS Data- Manager Cache transienter Speicher Serialisierbarkeitstheorie Die Serialisierbarkeitstheorie befasst sich mit den Korrektheitskriterien für die korrekte parallele Ausführung von Transaktionen Gegeben: Grundannahme G1: Grundannahme G2: = { T 1, T 2,, T n } Menge von Transaktionen, die korrekt parallel ausgeführt werden sollen. Jede Transaktion T i für sich genommen (einzeln, in Isolation ausgeführt) ist korrekt. Jede serielle (sequentielle) Ausführung aller n Transaktionen (in irgend einer Reihenfolge) ist korrekt. Es wird angenommen, dass alle Transaktionen von verschiedenen, unabhängigen Benutzern stammen und dass für diese Benutzer jede beliebige sequentielle Ausführung der Transaktionen akzeptabel ist. Wir benötigen also Kriterien die überprüfen, ob eine gegebene parallele Ausführung mehrerer Transaktionen mit einer solchen seriellen Ausführung übereinstimmt!

10 a 2 2 a 2 n Schedule Die parallele Ausführung der Transaktionen in wird durch einen Schedule reflektiert: Vollständiger Schedule S Dabei ist: Ein vollständiger Schedule S ist ein Tripel S = (,, <). S enthält die Ausführungsfolge aller Aktionen sämtlicher Transaktionen aus unter Wahrung der Präzedenzrelationen. = { T 1, T 2,, T n } Menge von Transaktionen =» ACT i Vereinigung der Aktionen aller Transaktionen in (*) < ( ) partielle Ordnung, wobei gilt: < i < für alle T i, d.h. die Ausführungsfolge der Aktionen in S beachtet die vorgeschriebene Folge innerhalb jeder Transaktion. (*) Ein vollständiger Schedule enthält genau ein C oder ein A für jede Transaktion Schedule t T 1 a 1 3 a 1 2 a 1 1 T 2 a 1 2 T n a 1 n Schedule: Ein Schedule ist ein Präfix eines vollständigen Schedules Ein Schedule S enthält abgeschlossene (C in S) abgebrochene (A in S) aktive (weder C noch A in S) Transaktionen. t a 1 1 a n 2 a n 1 a 2 1 Scheduler Schedule S In einem vollständigen Schedule existieren keine aktiven Transaktionen. Für die Ordnung < eines Schedules gilt: < total: sequentielle Bearbeitung < nicht total: parallele Bearbeitung, z.b. in verteilten Datenbanken

11 Schedule Serieller Schedule: In einem seriellen Schedule ist < total und für beliebige i, k œ {1,.., n} gilt: alle Aktionen von T i werden vor allen Aktionen von T k ausgeführt S ser = a 12 a 22 C 2 a 1n a 2n C n a 11 a 21 C n T 2 T n T 1 Zwei serielle Schedules werden jeweils als korrekt angesehen, liefern i.a. aber verschiedene Datenbank-(Zwischen- oder/und End-) Zustände. Committed Projection: Die committed projection C(S) eines Schedules S erhält man, wenn man aus S alle Aktionen von Transaktionen streicht, die nicht mit commit beendet sind, d.h. einschränkt auf: «T i : C i in S C(S) enthält also weder aktive noch abgebrochene Transaktionen Semantik von Aktionen Die Semantik der Aktionen einer Transaktion in einem Schedule ist wie folgt: Leser: Schreiber: r i (x) liest x von w k (x), wobei w k (x) die letzte Schreibaktion in S vor r i (x) ist. Dabei ist i k und T k ist nicht abgebrochen. w i (x) schreibt x neu. Dieses Schreiben hängt von allen Leseaktionen von T i vor w i (x) ab. Diese Leser (wie oben) lesen von nicht abgebrochenen Transaktionen. Ø Das Ergebnis einer Schreibaktion hängt (in unbekannter Weise; dies ist Sache des Anwendungsprogramms) von allen vorhergehenden Leseaktionen innerhalb der betrachteten Transaktion ab

12 Konflikt-Serialisierbarkeit Konflikt-Serialisierbarkeit basiert auf der grundlegenden Beobachtung, dass manche Aktionen eines Schedules vertauscht werden können, ohne dass sich dabei etwas ändert (sowohl aus der Sicht dieser Aktionen als auch aus der Sicht der jeweiligen Objekte). Dies ist nicht nur im einfachen read/write-modell der Fall sondern kann auch auf beliebige (semantisch reiche) Aktionen verallgemeinert werden. Beispiel: r 1 (x) < r 2 (x) ~ r 2 (x) < r 1 (x) w 1 (x) < w 2 (y) ~ w 2 (y) < w 1 (x) Umgekehrt gibt es jedoch auch Paare von Aktionen, die nicht vertauscht werden können (da diese Vertauschung Auswirkungen auf die Aktionen bzw. die jeweiligen Objekte hat). In solchen Fällen bestehen Abhängigkeiten zwischen diesen Aktionen (bzw. müssen wir Abhängigkeiten annehmen). Beispiel: r 1 (x) < w 2 (x) w 2 (x) < r 1 (x) w 1 (x) < w 2 (x) w 2 (x) < w 1 (x) 8-23 Konfliktrelation Aktionen, die nicht vertauscht werden können, sind in Konflikt. Die Konfliktrelation con gibt an, wann dies für Paare von Aktionen a und a der Fall ist (solche Paare werden auch Konfliktpaare genannt) Konfliktrelation con: con(a, a ) ñ (1) a und a werden auf dasselbe DB-Objekt x angewandt (2) a = read(x) a = write(x) r/w-konflikt a = write(x) a = read(x) w/r-konflikt a = write(x) a = write(x) w/w-konflikt Im Read/Write-Modell sind also zwei Aktionen in Konflikt, wenn sie auf dasselbe Objekt zugreifen und mindestens eine Aktion ein Schreiben ist

13 Abhängigkeitsrelation Die Abhängigkeitsrelation eines Schedules S enthält sämtliche Konfliktpaare aller Transaktionen aus S. Abhängigkeit & Abhängigkeitsrelation: Sei S ein Schedule. Aktion a k ist abhängig von Aktion a i in S, kurz a i Ø a k (1) i k T i und T k sind verschiedene Transaktionen, (2) a i <a k a i kommt vor a k in S, (3) con(a i, a k ) a i und a k sind in Konflikt, (4) C i, C k in S beide Transaktionen sind abgeschlossen. ñ Die Abhängigkeitsrelation dep(s) ist die Menge aller abhängigen Paare in S: dep(s) = {(a i, a k ) œ S a i Ø a k } Beispiele: S 1 = w 1 (a) r 2 (a) r 1 (b) w 2 (b) C 1 C 2 Ò S 1 = w 1 (a) r 1 (b) C 1 r 2 (a) w 2 (b) C 2 Ò 8-25 Konflikt-Äquivalenz Die Abhängigkeitsrelation ist ein Mittel, um die Semantik eines Schedules zu erfassen (und daher, um zwei Schedules zu vergleichen). Konflikt-Äquivalenz: Zwei Schedules S und S sind konflikt-äquivalent, wenn beide Schedules dieselben Aktionen beinhalten und wenn die Abhängigkeitsrelation identisch ist, also dep(s) = dep(s ) ist. Wenn zwischen zwei Transaktionen T i und T k ein Informationsfluss besteht, so kommt er ausschliesslich über die Konfliktpaare von T i und T k zustande. Es gibt keine weitere Informationsübermittlung über Nachrichten oder über weitere (lokale) gemeinsame Variable. Daher ist nur die Reihenfolge der Aktionen in den Konfliktpaaren von Bedeutung. Beispiel: S 1 = w 1 (a) r 2 (a) r 1 (b) w 2 (b) C 1 C 2 Ò S 1 = w 1 (a) r 1 (b) C 1 r 2 (a) w 2 (b) C 2 Ò

14 CPSR Konflikt-Serialisierbarkeit (CPSR): Ein Schedule S ist konflikt-serialisierbar, wenn seine Committed Projection C(S) konflikt-äquivalent zu einem seriellen Schedule S ser ist. Die Klasse der konflikt-serialisierbaren Schedules wird CPSR (Conflict Preserving Serializable) genannt. Konflikt-äquivalente Schedules sind also erzeugbar durch das Kommutieren von Aktionen, die nicht abhängig sind. Beobachtung: Durch die Betrachtung der Committed Projection wird der Einfluss abgebrochener Transaktionen nicht berücksichtigt. Beispiel: S 1 = w 1 (a) r 2 (a) r 1 (b) w 2 (b) C 1 C 2 Ò S 1 = w 1 (a) r 1 (b) C 1 r 2 (a) w 2 (b) C 2 Ò 8-27 Vertauschen von Aktionen Beobachtung: Bei serieller Ausführung werden alle Aktionen einer Transaktion T i vor/nach allen Aktionen einer Transaktion T k ausgeführt. Beispiel: S = a 11 a 21 a 31 a 12 a 13 a 41 Ò falls kein Konflikt ª a 11 a 21 a 31 a 12 a 41 a 13 Ò falls kein Konflikt ª a 11 a 21 a 31 a 41 a 12 a 13 Ò seriell! Wir benötigen daher ein Verfahren zum Nachweis der Existenz eines seriellen Schedules, der durch Vertauschung von Aktionen, die nicht in Konflikt sind, entsteht

15 Serialisierungsgraph Serialisierungsgraph (Abhängigkeitsgraph) Der Serialisierungsgraph (Abhängigkeitsgraph) SG(S) eines Schedules S ist ein Graph dessen Knoten alle mit Commit beendeten Transaktionen in S und dessen Kanten alle Paare (T i, T k ) sind für die gilt: es gibt Aktionen a i T i und a k in T k mit (a i, a k ) dep(s). Beispiel: S 1 = r 11 (a) r 12 (a) w 21 (a) r 13 (a) w 22 (b) w 23 (b) C 1 C 2 C 3 Ò 8-29 Serialisierbarkeitstheorem Ein Schedule S ist genau dann konflikt-serialisierbar (S œ CPSR), wenn sein Serialisierungsgraph SG(S) zyklenfrei ist. Man erhält einen zum Schedule äquivalenten seriellen Schedule (eine Serialisierung) durch topologische Sortierung des Abhängigkeitsgraphen: Man wähle eine beliebige Quelle des Graphen (d.h. einen Knoten ohne eingehende Kanten) und entferne diese sowie alle davon ausgehenden Kanten. Falls der Graph noch Knoten hat, wiederholt man diese Prozedur für den verbleibenden Graphen

16 Topologische Sortierung von SG(S) Vorüberlegung: Wenn SG(S) zyklenfrei ist, dann gibt es mindestens eine Quelle/Senke Quelle sonst Topologische Sortierung: Eine topologische Sortierung von SG(S) ist die Folge aller Knoten i 1 i 2 i n Ú wobei gilt: i r < i s fl es gibt keinen Pfad von i s nach i r in SG(S). Beispiel: T 2 T T 4 T T 1 T 6 5 T 2 Ø T 3 Ø T 4 T 5 T 6 T 1 T 1 T 4 T 6 T 5 T 4 T 5 T 1 T 6 mit T 4 Ø T Beispiele: CPSR S 1 = r 11 (a) r 12 (a) w 21 (a) r 13 (a) w 22 (b) w 23 (b) C 1 C 2 C 3 Ò S 2 = r 11 (a) r 12 (a) w 22 (a) r 13 (a) w 21 (a) w 23 (a) C 1 C 2 C 3 Ò

17 Ordnungserhaltende Serialisierbarkeit CPSR ist ein sehr intuitives Korrektheitskriterium. Allerdings gibt es auch hier noch unerwartete (?) Effekte. Beispiel: S = r 1 (x) r 2 (y) w 2 (y) r 1 (y) C 1 r 3 (z) C 3 r 2 (z) w 2 (z) C 2 Ò 8-33 OPSR Ordnungserhaltende Serialisierbarkeit: Ein Schedule S ist (transaktions-) ordnungserhaltend serialisierbar, wenn S œ CPSR und wenn es mindestens einen seriellen äquivalenten Schedule S gibt, in dem die in S vollständig geordneten Transaktionen auch in S die gleiche Reihenfolge haben. Die Klasse der ordnungserhaltend serialisierbaren Schedules wird OPSR (Order Preserving Serializable) genannt. Satz: OPSR Õ CPSR Beweis: OPSR Teilmenge von CPSR: Klar, nach obiger Definition (jeder OPSR-Schedule ist auch CPSR) OPSR ist echte Teilmenge von CPSR: Beispiel hierfür (Schedule aus CPSR, aber nicht aus OPSR): siehe vorige Folie

18 Commit-Ordnungserhaltung OPSR betrachtet nur die Erhaltung der Reihenfolge von Transaktionen, die in einem Schedule vollständig geordnet sind, aber nicht die Reihenfolge, in der die Commits erfolgen. Die Commit-Ordnungserhaltung ist ein weiteres Korrektheitskriterium, das genau diese Ordnung zusätzlich betrachtet. Grundlegende Idee: Man will nicht nur sicherstellen, dass parallele Transaktionen garantiert korrekt ausgeführt werden, sondern möchte auch noch die (interne) Serialisierungsreihenfolge kennen (bzw. vorgeben). Dies ist über die Commit-Reihenfolge, die nach aussen hin bekannt ist, möglich. Commit-ordnungserhaltende Serialisierbarkeit: Ein Schedule S ist commit-ordnungserhaltend serialisierbar wenn für jedes Paar mit Commit abgeschlossener Transaktionen T i, T k aus S gilt: falls (a i, a k ) in dep(s), dann ist C i < C k. Die Klasse der commit-ordnungserhaltend serialisierbaren Schedules wird COPSR (Commit Order Preserving Serializable) genannt. Es gilt: COPSR Õ OPSR 8-35 Vergleich von Korrektheitskriterien Alle Schedules CPSR OPSR COPSR Serielle Schedules

19 t 8.3 Concurrency Control-Protokolle T 1 a 3 1 a 2 1 a 1 1 T 2 a 2 2 a 1 2 a n 1 a 2 1 Eingabeschedule t a 1 1 a n 2 T n a 2 n a 1 n Scheduler (Sch) Serialisierbarer Schedule Die Aufgabe eines Schedulers ist die Transformation eines wohlgeformten Eingabeschedules in einen serialisierbaren Schedule. Ein Scheduler kann also als Abbildung Sch: ES # AS angesehen werden, wobei ES die Menge aller Eingabeschedules und AS die Menge aller serialisierbaren Ausgabeschedules ist, d.h. AS Œ CPSR Die Güte eines Schedulers bestimmt sich aus der Grösse der Ausgabeschedule-Menge AS, d.h. je mehr korrekte Schedules ein Scheduler zulässt, umso besser ist er. Ein weiteres Gütekriterium eines Schedulers ist dessen Fixpunktmenge: je grösser diese ist, umso besser ist der Scheduler. (die Fixpunktmenge eines Schedulers ist die Menge der korrekten Eingabeschedules, die nicht verändert werden, also Fixpunkt: S = Sch(S) = S ) 8-37 Concurrency Control-Protokolle Die Spielregeln des Schedulers, d.h. sein Algorithmus, werden als Concurrency Control Protokoll bezeichnet. Für die Praxis relevant sind nur dynamische ( on-line ) Scheduler. Das bedeutet, dass Concurrency Control-Protokolle die Entscheidung, ob Aktion a ik der Transaktion T k ausgeführt werden kann oder verzögert werden muss, oder ob T k zurückgesetzt werden muss ausschliesslich mit dem vor a ik liegenden Präfix des Schedules fällen können. Je nach Art der Protokolle wird dabei diese Entscheidung zumeist entweder nur für die Aktionen auf Datenobjekten (im r/w-modell: r(x) bzw. w(x)), oder nur für die Terminierungsaktionen (Commit bzw. Abort) durchgeführt. (einige wenige Protokolle verlangen eine Entscheidung für beide Arten von Aktionen) Ausgeschlossen ist auf jeden Fall die Analyse aller Aktionen der Transaktionen vor deren Ausführung

20 Einteilung: konservativ vs. optimistisch Konservative Protokolle Ein konservativer Scheduler setzt voraus, dass vor jeder Aktion überprüft wird, ob diese Aktion ausgeführt werden darf oder nicht. Ein Commit einer Transaktion hingegen ist in konservativen Protokollen immer erlaubt. Konservative Scheduler arbeiten häufig mit Sperrprotokollen. Da solche Verfahren mit Konflikten rechnen und vorsorglich Sperren setzen, werden sie auch als pessimistische Verfahren bezeichnet. Eine Besonderheit dieser sperrbasierten Verfahren ist die Möglichkeit, die Ausführung von Aktionen zu verzögern um damit Aktionen umzuordnen. Optimistische Protokolle Ein optimistischer Scheduler erlaubt die Ausführung von Aktionen, ohne dass zuvor überprüft werden muss, ob diese Aktion zulässig ist (solche Verfahren werden teilweise auch als aggressive Verfahren bezeichnet). Allerdings müssen optimistische Scheduler vor dem Commit eine Validierung bzw. Konfliktanalyse durchführen, um Korrektheit zu garantieren. In der Praxis haben sich die konservativen Protokolle durchgesetzt, die wir im Folgenden auch weiter betrachten werden Zwei-Phasen-Sperrprotokoll (2PL) Idee: Vor dem Zugriff (sowohl lesend als auch schreibend) auf ein Datenobjekt muss eine Sperre erworben werden. Dabei werden die Sperren so gewählt, dass keine Konfliktaktionen auf demselben Objekt möglich sind. Diese Sperren müssen transparent für die Transaktionen (und damit für den Benutzer bzw. das Anwendungsprogramm) vom System gesetzt werden. Beispiel: Transaktion T 1 = a 1 1 a 1 2 a 1 k Ò wird automatisch transformiert in T 1* = L(a 1 1) a 1 1 L(a 1 2) a 1 2 L(a 1 k) a 1 k U(a 1 1)U(a 1 2) U(a 1 k) Ò wobei L(a i k) eine Sperre auf das Objekt der Aktion a i k erwirbt (Lock) U(a i k) die gehaltene Sperre wieder freigibt (Unlock)

21 Sperrmodi und -verträglichkeit Das Ziel des 2PL-Verfahrens ist, keine Konfliktaktionen auf demselben Objekt zuzulassen, aber zugleich Aktionen, die nicht in Konflikt stehen, zu erlauben. Zwei parallele Transaktionen dürfen also dasselbe Objekt lesen, wenn aber auch auf das Objekt geschrieben wird, darf dies nur eine Transaktion (und keine andere darf das Objekt lesen). Um dies zu realisieren, benötigen wir unterschiedliche Sperrmodi: S-lock (= Shared Lock) für lesenden Zugriff, also für r(x) X-lock (= Exclusive Lock) für schreibenden Zugriff, also für w(x) Sperren sind im Prinzip Semaphore, die durch das DBS implementiert werden. Der Sperrmodus für einen Zugriff wird jeweils vom DBS automatisch gewählt. Für die Sperrmodi gilt folgende Verträglichkeit (die aus der Konfliktrelation abgeleitet ist): Objekt belegt mit Transaktion fordert Shared exclusive Shared + exclusive + angeforderte Sperre kann vergeben werden (Reihenfolge von Lesern vertauschbar. Kein Konflikt im r/r-fall) angeforderte Sperre kann NICHT vergeben werden (da sonst w/r, r/w, w/w-konflikt), die anfordernde Transaktion muss warten (dazu verwaltet das DBS verschiedene Queues) Zwei-Phasen-Sperrprotokoll Zwei-Phasen-Sperrprotokoll (2PL) Ein Scheduler hält das Zwei-Phasen-Sperrprotokoll (2PL) ein, wenn: (1) Vor der Ausführung jeder Aktion a i k Sperren L(a i k) erworben werden (S-Sperre für Leseaktionen, X-Sperre für Schreibaktionen) (2) Eine Sperre L(a i k) mindestens solange gehalten wird, bis die Aktion a i k ausgeführt wurde (3) Nach dem Freigeben einer Sperre keine weitere für dieselbe Transaktion angefordert wird. Erklärungen Zu (1): Hiermit werden Konfliktaktionen in die Reihenfolge der Sperranforderung gebracht. Falls eine Sperranforderung für Aktion a i k von T i nicht gewährt werden kann, muss T i warten! Zu (2): Die Aktionen müssen auch wirklich in der vom Scheduler vorgeschriebenen Reihenfolge ausgeführt werden. Ein 2PL-Scheduler erzeugt nur konflikt-serialisierbare (CPSR) Schedules; die entstehenden Schedules sind sogar ordnungserhaltend (OPSR)

22 Zweiphasigkeit Zu (3): Sperranforderungen und freigaben sind also in zwei Phasen aufgeteilt. Zunächst erwirbt eine Transaktion in der Wachstumsphase Sperren für alle Aktionen. Mit der ersten Sperrfreigabe tritt die Schrumpfungsphase ein, es dürfen dann keine neuen Sperren mehr angefordert werden. Anzahl Sperren BOT EOT t Wachstumsphase Schrumpfungsphase PL in der Praxis Das strikte 2PL ist als Concurrency-Control-Protokoll in den meisten kommerziellen DBS implementiert. Das 2PL kann auf verschiedenen Sperrgranulaten implementiert werden: Seitensperren (einfach zu realisieren, aber nicht sehr performant) Relationssperren oder Tablespace-Sperren (sehr grob und damit restriktiv) Tupelsperren und Sperren auf Indexeinträgen (sehr feines Granulat und daher bezüglich der Mehrbenutzerleistung am besten, aber auch komplexer zu realisieren; wird in den meisten kommerziellen DBS verwendet)

23 Beispiel für einen 2PL-Ablauf Ausführung des Eingabeschedules r 1 (a) w 2 (a) w 1 (b) C 1 w 2 (b) C 2 Ò Locktabelle des 2PL-Schedulers zu folgenden Zeitpunkten: Zeit Objekt a b t 0 t 1 t 2 t 3 t 4 t 5 t 6 t 7 Sperranforderungen/ -freigaben des Schedulers t 0 t 1 t 2 t 3 t 4 t 5 t 6 t 7 t Ausgabeschedule 8-45 Striktes Zwei-Phasen-Sperrprotokoll Das 2PL-Protokoll erlaubt das frühe Freigeben von Sperren (vor dem Commit). Da aber ein (on-line) Scheduler in der Regel nur den Präfix eines Schedules zur Verfügung hat, ist dieses frühzeitige Freigeben risikoreich! Abhilfe: Sperren müssen immer bis zum Ende der jeweiligen Transaktion gehalten werden. Striktes Zwei-Phasen-Sperrprotokoll (S2PL) Ein Scheduler hält das strikte Zwei-Phasen-Sperrprotokoll (S2PL) ein, wenn: (1) Vor der Ausführung jeder Aktion a i k Sperren L(a i k) erworben werden (S-Sperre für Leseaktionen, X-Sperre für Schreibaktionen) (2) Alle Sperren L(a i k) bis zum Ende der jeweiligen Transaktion gehalten werden (werden also beim Commit wieder freigegeben)

24 Korrektheit von S2PL Offensichtlich ist das S2PL-Protokoll strenger als das 2PL-Protokoll. Also garantiert auch S2PL, dass jeder erzeugte Schedule OPSR und damit auch CPSR ist. Zusätzlich gilt: Ein S2PL-Scheduler erzeugt nur commit-ordnungserhaltende (COPSR) Schedules Anzahl Sperren Die Schrumpfungsphase fällt also im S2PL mit dem Commit bzw. dem Abort zusammen. BOT EOT t 8-47 Deadlocks Ein entscheidender Nachteil des 2PL-Protokolls (und des S2PL-Protokolls) ist die Tatsache, dass zyklische Wartebeziehungen entstehen können. Das bedeutet, Transaktionen warten (prinzipiell unendlich lange) auf Sperren, die von anderen Transaktionen gehalten werden, dort aber nicht freigegeben werden können (weil auch diese Transaktionen auf weitere Sperren warten). Solche zyklischen Wartebeziehungen werden auch als Deadlocks bezeichnet. Beispiel: Gegeben sei folgender Eingabeschedule ES ES = r 1 (x) w 2 (y) w 2 (x) C 2 w 1 (y) C 1 Ò Ein S2PL-Scheduler produziert folgenden Ausgabeschedule S:

25 Deadlock-Erkennung: Wait-For-Graph Eine wesentliche Voraussetzung zur Behebung von Deadlocks ist zunächst ein Mechanismus, um zyklisches Warten überhaupt zu erkennen. Dies geschieht zumeist mit Hilfe eines Wartegraphen (Wait-For-Graph, WFG). Knoten dieses Graphen sind Transaktionen, Kanten T i Ø T k werden genau dann eingefügt, wenn T i auf eine Sperre wartet, die von T k gehalten wird (T i wartet auf Unlock von T k ) Beispiel: Gegeben sei folgender Eingabeschedule ES ES = r 3 (a) w 1 (b) w 1 (c) w 1 (a) r 2 (d) w 2 (e) r 4 (b) w 2 (c) r 3 (e) r 5 (e) C 2 C 3 C 5 C 1 C 4 Ò Die Erzeugung des Ausgabeschedules S zu ES durch einen 2PL-Scheduler führt dann zu folgenden Wartebeziehungen: WFG(S): 8-49 Deadlock-Auflösung Deadlocks entsprechen einem Zyklus im Wartegraphen. Es werden also Graphenalgorithmen zur effizienten Zyklenerkennung in gerichteten Graphen benötigt. Wann sollte diese Zyklenerkennung vorgenommen werden? Mögliche Strategien: Regelmässig, nach bestimmter Zeit (periodisch) Nach jedem Einfügen einer Kante in den WFG, also bei jeder nicht gewährten Sperranforderung (kontinuierlich) Deadlocks können nur aufgelöst werden, indem Transaktionen aus dem WFG-Zyklus zurückgesetzt werden (schliesslich wartet jede dieser Transaktionen und kann nicht fortfahren). Allerdings entstehen dadurch Kosten (Transaktionen, die abgebrochen werden, haben bereits Ressourcen verbraucht). Das Anwendungsprogramm erhält in diesem Fall einen speziellen Fehlercode (SQLCODE) für die SQL-Anweisung, bei der der Deadlock entstand. Das Programm sollte in einem solchen Fall selbst den erneuten Start der Transaktion veranlassen (ggf. nach erneuten Initialisierungen), damit der Deadlock und seine Behandlung gegenüber dem Endbenutzer transparent ist

26 Deadlock-Auflösung Welche Transaktion(en) soll(en) zurückgesetzt werden (Auswahl des Deadlock- Opfers )? Mögliche Strategien sind: Letzte Transaktion, die eine Kante in den WFG eingefügt hat (last blocked) Transaktion, die am wenigsten Sperren hält (minimum locks) Transaktion, die am wenigsten Rücksetzkosten verursacht, z.b. diejenige, die am wenigsten Update-Aktionen durchgeführt hat (minimum work) Transaktion, welche die meisten Zyklen auflöst (most cycles); dies ist vor allem beim periodischen Check des WFG relevant Transaktion, deren Rücksetzen am meisten Kanten aus dem WFG entfernt (most edges) 8-51 Sperrkonversion Deadlocks können auch aufgrund von Sperrkonversionen (Verschärfung einer Shared-Sperre in eine Exclusive-Sperre) auftreten dies tritt in der Praxis potentiell häufig auf. Solche Deadlocks können durch zusätzliche Sperrmodi weitgehend vermieden werden bzw. durch Einflussnahme des Benutzers / Anwendungsprogrammierers auf die Sperrverwaltung. Aus diesem Grund hat SQL spezielle Anweisungszusätze wie z.b. SELECT * FROM WHERE FOR UPDATE (setzt automatisch Schreibsperren für gelesene Daten)

27 Serialisierungsgraph-Test (SGT) Grundlage des Serialisierungsgraph-Test-Verfahrens (SGT) ist die naheliegende Idee, dass der Scheduler einen Serialisierungsgraphen pflegt und sicherstellt, dass dieser azyklisch bleibt. Dadurch ist dann sofort garantiert, dass jeder SGT-Schedule CPSR ist! SGT-Algorithmus: Voraussetzung: zu jedem Zeitpunkt wird benötigt A k : die Menge der Aktionen aller aktiven und korrekt abgeschlossenen Transaktionen T k SG: der bislang aufgebaute Serialisierungsgraph Aktion p i von T i steht zur Ausführung an Falls T i noch nicht in SG Füge T i in SG ein Für alle T k, also für alle aktiven und committeten Transaktionen Füge Kante T k Ø T i in SG ein, wenn ein A k eine Aktion q k enthält, die mit p i in Konflikt ist. Prüfe, ob SG azyklisch ist Falls ja, führe p i aus und füge p i in A i ein, sonst: setze T i zurück 8-53 Grösse des SG bei SGT Ein Problem beim SGT-Verfahren ist, dass der Serialisierungsgraph immer grösser wird Wann können Knoten sicher eliminiert werden? Naive Lösungsvermutung: Eine Transaktion T k kann nach dem Commit entfernt werden Diese Annahme ist allerdings falsch (wie das folgende Beispiel zeigt) Beispiel: S = r k+1 (x) w 1 (x) w 1 (y 1 ) C 1 w 2 (y 1 ) w 2 (y 2 ) C 2 w k (y k-1 ) w k (y k ) C k w k+1 (y k ) C k+1 Ò

28 Entfernen von Transaktionen aus SGT Das Beispiel zeigt, dass im Prinzip beliebig viele abgeschlossene Transaktionen im Serialisierungsgraph behalten werden müssen. Richtiges und korrektes Entfernen von Transaktionen aus SG: T k kann entfernt werden, wenn 1) T k abgeschlossen ist und 2) T k Quelle in SG ist Wenn T k abgeschlossen ist, dann können keine Kanten nach T k gerichtet hinzukommen. Wenn T k zudem noch Quelle ist, dann kann T k nicht mehr in einen Zyklus verwickelt werden, darf also aus SG entfernt werden. SGT wird heute in Datenbanken praktisch nicht verwendet. Das Problem des Verfahrens ist, dass bei kurzen r/w-transaktionen der Aufwand recht gross ist, die A k -Mengen zu verwalten (zudem ist für r/w-transaktionen die Verwendung von Sperren einfacher und auch intuitiver). Allerdings besitzt SGT den Vorteil, sehr generisch zu sein (im Gegensatz zu den Sperrverfahren, da S- bzw. X-Sperren sehr stark auf der Semantik von Lese- und Schreibaktionen basieren). Daher ist das SGT-Verfahren für semantisch reiche Aktionen in komplexeren Umgebungen durchaus sinnvoll Isolationsstufen Striktes 2PL garantiert Serialisierbarkeit. Für bestimmte Transaktionen können jedoch auch geringere Anforderungen an die Korrektheit ausreichen. In SQL-92 kann deshalb mit einer SET TRANSACTION-Anweisung unmittelbar vor der ersten Anweisung einer Transaktion auch eine niedrigere Isolationsstufe als volle Serialisierbarkeit spezifiziert werden. Spezifikation von Transaktionsmodi TransactionSpec = SET TRANSACTION [ READ ONLY READ WRITE ] [ ISOLATION LEVEL Isolation ] Isolation = READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE

29 SQL-92 Isolationsstufen READ UNCOMMITTED ( level 0 ) bedeutet, dass die entsprechende Transaktion Daten, die von einer anderen noch im Gang befindlichen Transaktion geschrieben wurden, lesen kann ( dirty read ). Die Transaktion hält keine Sperren. Diese Isolationsstufe ist nur für READ ONLY Transaktionen gestattet. READ COMMITTED ( level 1 ) bedeutet, dass die entsprechende Transaktion nur definitive Daten lesen kann. Dies kann erreicht werden, wenn die Transaktion keine Sperren für Tupel hält, die von ihr gelesen wurden, wohl aber für solche, die von ihr modifiziert wurden. Da keine Sperren für gelesene Tupel gehalten werden, ist es möglich, dass bei wiederholtem Lesen eines bestimmten Tupels dieses zwischenzeitlich verändert wurde. Auch das Phänomen des inkonsistenten Lesens sowie das Phantom-Problem kann auftreten. REPEATABLE READ ( level 2 ) bedeutet ebenfalls, dass die entsprechende Transaktion nur definitive Daten lesen kann, z.b. indem die Transaktion Sperren für alle Tupel hält, die von ihr gelesen und/oder geschrieben wurden (bzw. wenn sie auf einem privatem Snapshot operiert). Da jedoch keine so genannten Prädikatsperren gehalten werden kann u.u. noch das Phantomproblem auftreten. SERIALIZABLE ( level 3 ) schliesst auch noch das Phantomproblem aus Atomarität und Persistenz in Datenbanken Die Eigenschaften der Atomarität und Persistenz bedeuten, dass Datenbank- Anwendungsprogramme grösstenteils so geschrieben werden können, als gäbe es keine Fehler der Hardware oder Systemsoftware. Die Transaktionsverwaltung eines DBS stellt mit der Recovery-Komponente weit reichende Fehlertoleranzmassnahmen zur Verfügung, und zwar transparent für die Anwendungsentwicklung

30 Übersicht über Fehlerklassen Folgende Fehler können die Atomarität oder die Persistenz von Transaktionen (A bzw. D von ACID) gefährden: 1. Fehler im Anwendungsprogramm 2. Fehler in der Systemsoftware (OS oder DBS), die zum Systemabsturz (engl.: system failure, [soft] crash) führen Bohrbugs : deterministisch und reproduzierbar; sind in gut ausgetesteter Systemsoftware so gut wie eliminiert Heisenbugs : schwer einzugrenzen und praktisch nicht reproduzierbar; treten vor allem in Überlastsituationen im Mehrbenutzerbetrieb auf 3. Stromausfall 4. Transienter Hardwarefehler (CPU, Speicher) 5. Fehlbedienung (Systemadministrator, Operator, Techniker) 6. Plattenfehler (Media-Fehler), der zum Verlust von permanent gespeicherten Daten führt (engl.: disk failure, hard crash) 7. Katastrophe (Feuer, Erdbeben, etc.) 8-59 Fehlerbehandlung 1. Unvollendete Transaktionen von fehlerhaft beendeten Programmen werden zurückgesetzt Das DBMS wird im Warmstart neu gestartet und führt dabei eine Crash-Recovery durch. Dabei werden alle vor dem Absturz unvollendeten Transaktionen zurückgesetzt (Undo von Transaktionen). Änderungen von beendeten Transaktionen werden nötigenfalls DBMS-intern wiederholt (Redo von Transaktionen). Transaktionen, für die die Recovery-Komponente ein Undo durchgeführt hat, müssen vom Anwendungsprogramm oder sogar vom Endbenutzer neu gestartet werden. Die Fehlerkategorie 3 kann durch ununterbrechbare Stromversorgung eliminiert werden. 6. Wiederherstellung der verlorenen Daten durch Aufsetzen auf einer Archivkopie der Datenbank und Wiederholung der Änderungen abgeschlossener Transaktionen (Media-Recovery, Archiv-Recovery). 7. Änderungen abgeschlossener Transaktionen müssen auf einem zweiten, genügend weit entfernten Rechner doppelt erfasst werden; im Katastrophenfall übernimmt der zweite Rechner dann die Verarbeitung

31 8.5 Transaktions-Recovery In der bisherigen Betrachtung der Concurrency Control wurden Fehler nicht berücksichtigt, d.h. der Einfluss abgebrochener Transaktionen auf die Korrektheit eines Schedules wurde ignoriert: bei CPSR wird nur die Committed Projection eines Schedules betrachtet. Bisher sind wir also implizit so verfahren, als ob wir die Aktionen abgebrochener Transaktionen einfach streichen könnten Dies ist jedoch nicht ohne weiteres möglich, da natürlich Schreib-Aktionen abgebrochener Transaktionen sehr wohl den Datenbankzustand ändern können (und dieser geänderte Zustand dann von weiteren Transaktionen gelesen werden kann) Transaktions-Recovery Die Atomarität von Transaktionen eine wichtige Eigenschaft, denn jederzeit während der Ausführung einer Transaktion können Fehler auftreten (Systemfehler oder vom Benutzer bzw. Anwendungsprogramm initiierte Fehler) Es muss garantiert werden, dass die Änderungen abgebrochener Transaktionen ohne Seiteneffekte entfernt werden können Recovery, dt.: Fehlererholung Dies wird mit den folgenden Korrektheitskriterien präzisiert, die angeben, wann Transaktionen in einem Schedule korrekt abgebrochen werden können (also wie Fehler der Kategorie 1 behoben werden können) Diese Kriterien folgen dabei der klassischen Vorgehensweise, in der Concurrency Control und Recovery getrennt voneinander betrachtet werden in der Praxis sind jedoch Protokolle gefragt, die beide Probleme integriert behandeln

32 Transaktionsverwaltung Beispiel: Recovery Ich möchte SFr von meinem Konto abheben Ich möchte meiner Enkelin SFr überweisen SELECT Kontostand INTO :balanceatm FROM Konto WHERE KontoNr = 4711; KontoNr Kontostand SELECT Kontostand INTO :balancetransb FROM Konto WHERE KontoNr = 4711; balancetransb := balancetransb + 200; Update Konto SET Kontostand = :balancetransb WHERE KontoNr = 4711; balanceatm := balanceatm 250; 70.- Update Konto SET Kontostand = :balanceatm WHERE KontoNr = 4711; COMMIT WORK; ROLLBACK WORK; 8-63 Rücksetzbarkeit (Recoverability) Die Atomaritäts-Eigenschaft des Transaktionskonzepts verlangt, dass die Effekte einer abgebrochenen Transaktion vollständig rückgängig gemacht werden. Dies betrifft sowohl eventuell schon durchgeführte Änderungen in der Datenbank als auch Auswirkungen auf andere Transaktionen. Allerdings kann der Abbruch einer Transaktion und das Rückgängigmachen ihrer Änderungen in bestimmten Situationen unmöglich sein, weil andere, bereits abgeschlossene Transaktionen, davon betroffen sind: Beispiel: S 1 = w 1 (x) r 2 (x) w 2 (y) C 2 A 1 Ò

33 Recoverability (RC) Die Minimalanforderung an Schedules, um korrekte Abbrüche von Transaktionen zu ermöglichen ist daher, dass jede Transaktion T i nach allen Transaktionen T k, von denen sie liest, beendet wird. Hierzu benötigen wir zunächst Information über die Frage, welche Transaktion von welcher anderen Transaktion Daten liest. Liest-von-Beziehung: Sei S ein Schedule. r i (x) liest-von w k (x), i k, falls: (a) w k (x) < r i (x) (b) w m (x) mit w k (x) < w m (x) < r i (x) (c) T k ist nicht abgebrochen Reads-From-Relation: RF(S) = { (T k, x, T i ) r i (x) liest-von w k (x) in S} (Liest-von-Relation) Rücksetzbarkeit (Recoverability, RC) Ein Schedule S ist rücksetzbar (recoverable), wenn für alle Transaktionen T i, T k in S gilt: Falls (T k, x, T i ) œ RF(S) und i k und C i in S, dann müssen die Commits wie folgt geordnet sein: C k < C i. Alle Transaktionen T k, von denen T i liest, müssen also vor T i beendet sein. Die Klasse der rücksetzbaren (recoverable) Schedules wird mit RC bezeichnet Transaktionsverwaltung Beispiel: Dominoeffekt Ich möchte SFr von meinem Konto abheben Ich möchte meiner Enkelin SFr überweisen SELECT Kontostand INTO :balanceatm FROM Konto WHERE KontoNr = 4711; KontoNr Kontostand SELECT Kontostand INTO :balancetransb FROM Konto WHERE KontoNr = 4711; balancetransb := balancetransb + 200; Update Konto SET Kontostand = :balancetransb WHERE KontoNr = 4711; balanceatm := balanceatm 250; 70.- Update Konto SET Kontostand = :balanceatm WHERE KontoNr = 4711; ROLLBACK WORK; Transaktion am Geldautomat muss ebenfalls abgebrochen werden!

34 Kaskadenfreiheit (ACA) Selbst bei rücksetzbaren Schedules können, wie im vorigen Beispiel gezeigt, noch unangenehme Effekte auftreten (in abstrakter Formulierung): Beispiel: S 2 = w 1 (x) r 2 (x) w 2 (y) A 1 Ò Es kann also vorkommen, dass das Rücksetzen einzelner Transaktionen in einem RC-Schedule kaskadierend das Rücksetzen weiterer Transaktionen erfordert. Kaskadenfreiheit (Avoiding Cascading Aborts, ACA) Ein Schedule S ist kaskadenfrei, wenn gilt: falls (T k, x, T i ) œ RF(S) und i k, dann muss C k < r i (x) sein. Transaktionen dürfen also nur comittete Werte lesen. Die Klasse der kaskadenfreien Schedules wird auch als ACA (avoiding cascading aborts) bezeichnet. ACA Õ RC: ACA ist eine echte Teilmenge von RC Striktheit Für die praktische Durchführung eines Aborts müssen die einzelnen Aktionen einer abgebrochenen Transaktion rückgängig gemacht werden. In der Regel schreibt man dazu das before image des betroffenen Datenobjektes (den letzten Wert, den es vor Ausführung der Aktion der abzubrechenden Transaktion hatte). Dies kann jedoch inkorrekt sein, wenn nur Kaskadenfreiheit existiert: Beispiel: S 3 = w 1 (x) w 2 (x) C 2 A 1 Ò

35 Striktheit (ST) Striktheit (ST) Ein Schedule S ist strikt, wenn gilt: Falls w k (x) < a i (x) und i k in S, dann müssen die Terminierungs- Aktionen wie folgt geordnet sein: A k < a i (x) oder C k < a i (x) (für a i œ {r i, w i }). Ein Objekt darf weder gelesen noch geschrieben bzw. überschrieben werden, bevor es commited oder aborted ist. Die Klasse der strikten Schedules wird mit ST bezeichnet. ST Õ ACA: ST ist eine echte Teilmenge von ACA Rigorosität (RG) Eine noch weitere Einschränkung der Striktheit eines Schedules führt zur Rigorosität: Rigorosität (RG) Ein Schedule S ist rigoros, wenn zwischen je zwei Konflikt-Aktionen a i < a k stets ein C i oder A i kommt. Die Klasse der rigorosen Schedules wird mit RG bezeichnet. RG Õ ST: RG ist eine echte Teilmenge von ST

36 Einordnung der Rigorosität RG verhindert also r/w, w/r und w/w-konflikte zwischen aktiven Transaktionen, während ST dies nur für w/r und w/w-konflikte tut. Dieser Unterschied hat grosse praktische Konsequenzen: RG Õ CPSR: RG ist eine echte Teilmenge der Klasse CPSR aller konflikt-serialisierbaren Schedules. RG garantiert also als einziges der bisher eingeführten Korrektheitskriterien Concurrency Control und Recovery gleichzeitig (jedoch sehr restriktiv): RG Õ (CPSR RC) Da RG die Platzierung von Commits zwischen Konflikt-Aktionen verlangt, gilt bezüglich COPSR (der Klasse der commit-ordnungserhaltend serialisierbaren Schedules): RG Õ COPSR: RG ist eine echte Teilmenge der Klasse COPSR. Im Gegensatz zu RG sind jedoch jeweils ST, ACA und RC nicht mit CPSR vergleichbar, garantieren also nicht gleichzeitig auch Serialisierbarkeit! 8-71 Zusammenfassung der Klassen von Schedules Es gilt also: RG Õ ST Õ ACA Õ RC und RG Õ COPSR Alle Schedules CPSR RC ACA ST COPSR Serielle Schedules RG

37 8.6 Crash Recovery Im Gegensatz zur Transaktions-Recovery, in der (nur) die Atomarität von Transaktionen garantiert wird, ist das Ziel der Crash-Recovery, Atomarität und Persistenz zu garantieren. Bei einem Systemabsturz muss der Datenbank-Server wieder gestartet und vor der Aufnahme des normalen Betriebes wieder in einen konsistenten Zustand gebracht werden. Dies beinhaltet das... Rückgängigmachen der Änderungen abgebrochener Transaktionen, die bereits auf persistentem Speicher sind Nachfahren der Änderungen von Transaktionen, die bereits vor dem Crash mit Commit beendet wurden, aber noch nicht auf den persistenten Speicher geschrieben wurden... jeweils unter Einhaltung der Serialisierungsordnung der ursprünglichen Ausführung 8-73 Recovery-Komponente: Zielsetzungen Vordringliches Ziel ist eine hohe Verfügbarkeit, also eine möglichst hohe Wahrscheinlichkeit, dass ein Benutzer zu einem beliebigen Zeitpunkt ein laufendes System antrifft. Start des Systems Recovery beendet Systemausfall Systemausfall Recovery beendet MTTR MTTF MTBF Für die Verfügbarkeit v gilt: mit: MTTF = Mean Time To Failure MTTR = Mean Time To Repair MTBF = Mean Time Between Failures (Eine Verfügbarkeit von 99 % impliziert beispielsweise eine Auszeit von ca Minuten pro Jahr, während der das System nicht verfügbar ist; eine Verfügbarkeit von 99.9 % impliziert eine Auszeit von ca. 500 Minuten pro Jahr.) Das führt zu folgenden Anforderungen: Schnelle Recovery beim Warmstart: kurze MTTR Geringer Overhead im laufenden Normalbetrieb Zeit : System nicht verfügbar MTTF MTTF v : MTBF MTTF MTTR

38 Logging für (Crash-)Recovery Arbeitsprinzipien der Recovery-Komponente: Um im Fehlerfall Undo und Redo durchführen zu können, müssen Änderungen auf einem hinreichend stabilen Speichermedium protokolliert werden. Für jede Änderung gibt es eine Undo-Information, um die Änderung rückgängig machen zu können, und eine Redo-Information, um die Änderung wiederholen zu können. Atomaritätsprinzip: Vor einer Veränderung der permanenten Datenbank (durch Zurückschreiben geänderter Seiten aus dem Puffer auf die Platte) muss die entsprechende Undo-Information auf stabilen Speicher geschrieben werden. Persistenzprinzip: Vor dem Commit einer Transaktion muss die entsprechende Redo-Information auf stabilen Speicher geschrieben werden Recovery-Komponente: Arbeitsprinzipien Idempotenzprinzip: Da es während eines Warmstarts zu einem erneuten Ausfall kommen kann, müssen Recovery-Massnahmen beliebig oft wiederholbar sein: zweimaliges Undo derselben Änderung hat gleichen Effekt wie einmaliges Undo zweimaliges Redo derselben Änderung hat gleichen Effekt wie einmaliges Redo Ein Undo einer Änderung, die durch den Systemabsturz bereits verloren gegangen ist, hat keinen Effekt; ein Redo einer Änderung, die durch den Systemabsturz gar nicht verloren gegangen ist, hat keinen Effekt. Änderungen werden in Form von Log-Sätzen in einer Log-Datei protokolliert. Um nicht für alle Änderung einen Plattenzugriff durchführen zu müssen, werden Log-Sätze zunächst in einen Log-Puffer im Hauptspeicher geschrieben und nur bei Bedarf (später mehr hierzu) sequentiell in die Log-Datei auf Platte geschrieben. Um sicherzustellen, dass für die Log-Datei tatsächlich immer sequentielle I/Os stattfinden, sollte die Log-Datei auf einer separaten Platte liegen