Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

SS 2004B. König-Ries: Datenbanksysteme5-1 Kapitel 5: Transaktionsverwaltung Transaktionsmodell Isolation Atomizität Dauerhaftigkeit Folien: © Prof. Lockemann,

Ähnliche Präsentationen


Präsentation zum Thema: "SS 2004B. König-Ries: Datenbanksysteme5-1 Kapitel 5: Transaktionsverwaltung Transaktionsmodell Isolation Atomizität Dauerhaftigkeit Folien: © Prof. Lockemann,"—  Präsentation transkript:

1 SS 2004B. König-Ries: Datenbanksysteme5-1 Kapitel 5: Transaktionsverwaltung Transaktionsmodell Isolation Atomizität Dauerhaftigkeit Folien: © Prof. Lockemann, IPD, Uni Karlsruhe

2 SS 2004B. König-Ries: Datenbanksysteme5-2 Kapitel 5: Transaktionsverwaltung Transaktionsmodell Isolation Atomizität Dauerhaftigkeit

3 SS 2004B. König-Ries: Datenbanksysteme5-3 Zur Erinnerung Transaktionsprozedur: Folge primitiver Operationen als Einheit der Konsistenz und der Robustheit. Transaktion (TA): Ausführung einer Transaktionsprozedur mit gewissen Garantien für Konsistenz und Robustheit. Transaktionsverwaltung (TAV): Steuerung einer Menge auch überlappender Transaktionen unter Wahrung von Konsistenz und Robustheit unter Berücksichtigung weiterer Merkmale wie Performanz.

4 SS 2004B. König-Ries: Datenbanksysteme5-4 Verantwortlichkeiten (1) Ausgangspunkt: Transaktion ist Konsistenzeinheit: Konsistenz (engl. consistency): Eine Transaktion bewirkt einen konsistenten Zustandsübergang, d.h. sie führt auf einen konsistenten Datenbasiszustand, sofern sie zu Beginn auf einem konsistenten Datenbasiszustand aufsetzte. Dies ist eine Forderung der Transaktionsverwaltung (TAV) an die Transaktion. Nur wenn sie erfüllt ist, kann die TAV die Konsistenz und Robustheit des Gesamtsystems zusichern. Wegen der Veranwortlichkeit der Transaktion spricht man daher von der lokalen Konsistenz (der Transaktion).

5 SS 2004B. König-Ries: Datenbanksysteme5-5 Verantwortlichkeiten (2) Recovery: Durchsetzen von Persistenz und Fehler-Resistenz in der folgenden Form: Atomizität (engl. atomicity): Die Transaktion hat nur als Einheit eine Wirkung nach außen. Bis zu ihrem erfolgreichen Abschluss hinterlässt sie überhaupt keine Wirkung nach außen (Transienz), nach ihrem erfolgreichen Abschluss ist ihre Wirkung allgemein sichtbar (Persistenz). Transienz (als Teil der Resistenz) und Persistenz sind also rein lokal auf die von der Transaktion betroffenen Zustände bezogen. Transienz bezieht sich auf den Zustand unmittelbar vor, Persistenz auf den unmittelbar nach der Transaktion. Die Verantwortung liegt (vorrangig) beim Recovery-Verwalter als Teil der Segmentverwaltung.

6 SS 2004B. König-Ries: Datenbanksysteme5-6 Verantwortlichkeiten (3) Dauerhaftigkeit (engl. durability): Ergänzung der Persistenz auf lange Dauer: Die Wirkung einer erfolgreich ausgeführten Transaktion geht nicht mehr verloren, es sei denn, sie wird durch eine weitere Transaktion ausdrücklich widerrufen. Da die Transaktion nicht mehr existiert, kann die Verantwortung nur einer eigenen Komponente (Archiv-Verwaltung) übertragen werden. Mit der Atomizität schafft sie aber die Voraussetzungen!

7 SS 2004B. König-Ries: Datenbanksysteme5-7 Verantwortlichkeiten (4) Durchsetzen der Konsistenz einer Datenbasis für eine Menge in Konflikt stehender Transaktionen (globale Konsistenz) durch eine strenge Form der Konflikt-Resistenz: Isolation (engl. isolation): Nebenläufige Transaktionen laufen jede für sich so ab, als ob sie alleine ausgeführt würden (keine Vermischung von Zustandsübergängen). Gleichlaufende Transaktionen sind also nicht sichtbar, jede Transaktion läuft außer Konkurrenz. Jegliche Wechselwirkung ist unerwünscht. Die Verantwortung liegt beim Scheduler als Teil der Segmentverwaltung.

8 SS 2004B. König-Ries: Datenbanksysteme5-8 ACID-Eigenschaften (1) Gut geeignet für kommerzielle Anwendungen mit: kurzlaufenden, unabhängigen Transaktionen (z.B. Buchungen), hohen Korrektheitsanforderungen. Aatomicity Cconsistency Iisolation Ddurability

9 SS 2004B. König-Ries: Datenbanksysteme5-9 ACID-Eigenschaften (2) Weniger gut geeignet für: kooperative Anwendungen (z.B. CAD): Kooperatives Arbeiten (z.B. gemeinsamer Entwurf eines Automotors) ist bei strikter Isolation nicht möglich, da Zwischenergebnisse einer Transaktion für andere nicht sichtbar sind. langlaufende Vorgänge (z.B. interaktive Bestellung über das WWW): Bei langlaufenden, ressourcenintensiven Transaktionen ist komplettes Zurücksetzen im Fehlerfall gemäß Atomizität oft nicht akzeptabel. statistische Analyseverfahren mit geringen Korrektheitsanforderungen, aber hohem Datendurchsatz: Vollständige Konsistenz der gelesenen Daten ist nicht erforderlich, daher ist Zusatzaufwand für ACID-Garantien nicht gerechtfertigt.

10 SS 2004B. König-Ries: Datenbanksysteme5-10 Modellierung von Transaktionen Zur Formalisierung der ACID-Garantien muss Verhalten von Transaktionen modelliert werden. Folge aus der Forderung nach lokaler Konsistenz: Die Transaktionsverwaltung soll nichts über die Semantik der TA wissen müssen. Annahme: Die TA teilt der TAV auch nichts darüber mit. Folge: Die TAV ist auf das beobachtbare Verhalten der TA angewiesen: Dies sind die Bekanntgabe der Transaktionsgrenzen sowie die Transportvorgänge zwischen Arbeitsspeicher der TA und dem Hintergrundspeicher, also die individuellen Lese- und Schreibzugriffe.

11 SS 2004B. König-Ries: Datenbanksysteme5-11 Lese-Schreib-Modell Transaktionsverwaltung eines DBMS arbeitet daher mit einfachem Lese-Schreib-Modell von Transaktionen: Bearbeitung der Daten erfolgt in einem privaten Arbeitsspeicherbereich der Transaktion. Transaktionen können durch Operationen read(x) und write(x) Transfer eines Datenelements x (z.B. Block, Tupel oder Relation) vom Hintergrund- in den Arbeitsspeicher und umgekehrt anfordern. Transaktionen können durch Operationen commit und abort erfolgreichen bzw. nicht erfolgreichen Abschluss mitteilen. Im ersten Fall müssen alle durchgeführten write-Operationen dauerhaft, im zweiten rückgängig gemacht werden. Interaktion von Transaktionen mit der Datenbasis beschränkt sich auf die Operationen read, write, commit und abort. Nur diese werden von der Transaktionsverwaltung bearbeitet.

12 SS 2004B. König-Ries: Datenbanksysteme5-12 Formale Beschreibung von Transaktionen (1) Eine Operation o hat eine der folgenden vier Formen: r i (x)Lesen von Datenelement x durch Transaktion i w i (x)Schreiben von Datenelement x durch Transaktion i c i Abschluss von Transaktion i a i Abbruch von Transaktion i (Wenn es auf Details nicht ankommt, werden Operationen kurz als o i bzw. o i (x) notiert.)

13 SS 2004B. König-Ries: Datenbanksysteme5-13 Formale Beschreibung von Transaktionen (2) Eine Transaktion ist eine total geordnete Menge T i von Operationen mit: T i {r i (x), w i (x) | x Datenelement} {a i, c i }. T i kann höchstens eine der Operationen a i oder c i enthalten. Falls T i a i oder c i enthält, so ist dies die letzte Operation in T i. Falls es o,o' T i gibt mit o = r i (x), o' = w i (x), so folgt o < o'. Konsequenzen aus Definition: Transaktion kann, muss aber nicht abgeschlossen sein. Mehrfaches Lesen oder Schreiben desselben Datums nicht zulässig. Schreiben und anschließendes Lesen eines Datums nicht zulässig.

14 SS 2004B. König-Ries: Datenbanksysteme5-14 Lese-Schreib-Modell: Beispiele Relationen TICKET (ticketNr, name)T BUCHUNG (flugNr, ticketNr, platzCode, datum)B Transaktionen: T 1 : Prüfen der Konsistenz von Passagierlisten und Buchungen, T 2 : Umbuchung einer Gruppe von Passagieren, T 3 : Stornieren einer Buchung. Vereinfachende Annahmen: Bei Lese- und Schreib-Operationen werden stets die gesamten Relationen zwischen Hintergrund- und Arbeitsspeicher übertragen.

15 SS 2004B. König-Ries: Datenbanksysteme5-15 Beispiel-Transaktion T 1 Transaktion T 1 druckt Anzahl der für den 12. August 2000 verkauften Tickets sowie Liste der Inhaber aus: selectcount (distinct ticketNr) fromBUCHUNG wheredatum = 12-AUG-00; drucke Anzahl der verkauften Tickets; selectname fromTICKET whereticketNr in (selectticketNr fromBUCHUNG wheredatum = 12-AUG-00); drucke Passagierliste; commit; Lesen von BUCHUNG Lesen von TICKET BUCHUNG schon gelesen Transaktionsbeschreibung von T 1 : r 1 (B) r 1 (T) c 1.

16 SS 2004B. König-Ries: Datenbanksysteme5-16 Beispiel-Transaktion T 2 Transaktion T 2 bucht Passagiere in Reihe 19 (Bender, Kuhn und Weinand) auf LH500 vom 12. August 2000 auf 11. August 2000 um und versieht Ticketnummer mit Änderungsvermerk : updateTICKET setticketNr = ticketNr whereticketNr in (selectticketNr fromBUCHUNG wheredatum = 12-AUG-00 and flugNr = "LH500" and(platzCode = "19D" or platzCode = "19E" or platzCode = "19G" )); updateBUCHUNG setdatum = 11-AUG-00, ticketNr = ticketNr wheredatum = 12-AUG-00 and flugNr = "LH500" and(platzCode = "19D" or platzCode = "19E" or platzCode = "19G"); commit; Lesen von BUCHUNG Lesen von TICKET BUCHUNG schon gelesen Schreiben von TICKET Schreiben von BUCHUNG

17 SS 2004B. König-Ries: Datenbanksysteme5-17 Beispiel-Transaktion T 2 Transaktion T 2 bucht Passagiere in Reihe 19 (Bender, Kuhn und Weinand) auf LH500 vom 12. August 2000 auf 11. August 2000 um und versieht Ticketnummer mit Änderungsvermerk : updateTICKET setticketNr = ticketNr whereticketNr in (selectticketNr fromBUCHUNG wheredatum = 12-AUG-00 and flugNr = "LH500" and(platzCode = "19D" or platzCode = "19E" or platzCode = "19G" )); updateBUCHUNG setdatum = 11-AUG-00, ticketNr = ticketNr wheredatum = 12-AUG-00 and flugNr = "LH500" and(platzCode = "19D" or platzCode = "19E" or platzCode = "19G"); commit; Lesen von BUCHUNG Lesen von TICKET BUCHUNG schon gelesen Transaktionsbeschreibung von T 2 : r 2 (B) r 2 (T) w 2 (T) w 2 (B) c 2. Schreiben von TICKET Schreiben von BUCHUNG Nicht anzusehen, dass die geschriebenen Werte von beiden gelesenen Werten abhängen

18 SS 2004B. König-Ries: Datenbanksysteme5-18 Beispiel-Transaktion T 3 Transaktion T 3 storniert Ticket Nr : delete from TICKET where ticketNr = ; delete from BUCHUNG where ticketNr = ; commit; Transaktionsbeschreibung von T 3 : r 3 (T) w 3 (T) r 3 (B) w 3 (B) c 3. Lesen von BUCHUNG Lesen von TICKET Schreiben von TICKET Schreiben von BUCHUNG

19 SS 2004B. König-Ries: Datenbanksysteme5-19 Schedules Bei nebenläufiger Bearbeitung von Transaktionen müssen die Operationen der einzelnen Transaktionen (sog. lokale Schedules) in eine globale Reihenfolge gebracht werden. Dadurch entsteht ein globaler Schedule. Aufgabe des Schedulers: Herbeiführung eines globalen Schedules, der den ACID-Anforderungen genügt. Transaktion 1Transaktion 2... Transaktion n Scheduler Datenbasis-Manager Schedule 1Schedule n Globaler robuster Schedule

20 SS 2004B. König-Ries: Datenbanksysteme5-20 Schedules: Beispiele Betrachte: T 1 : r 1 (B) r 1 (T) c 1 T 2 : r 2 (B) r 2 (T) w 2 (T) w 2 (B) c 2 Ein globaler Schedule: S1: r 1 (B) r 2 (B) r 2 (T) w 2 (T) w 2 (B) c 2 r 1 (T) c 1 Ein weiterer globaler Schedule: S2: r 2 (B) r 2 (T) r 1 (B) r 1 (T) w 2 (T) w 2 (B) c 2 c 1 Sind sie robust, genügen sie also den ACID-Anforderungen?

21 SS 2004B. König-Ries: Datenbanksysteme5-21 Kapitel 5: Transaktionsverwaltung Transaktionsmodell Isolation Atomizität Dauerhaftigkeit

22 SS 2004B. König-Ries: Datenbanksysteme5-22 Aufgabe 1. Teilaufgabe des Schedulers: Verzahnung der einzelnen Operationsfolgen muss so erfolgen, dass unerwünschte Wechselwirkungen vermieden werden. Im Folgenden Illustration der Probleme, die bei inkorrekter Verzahnung nebenläufiger Transaktionen entstehen können.

23 SS 2004B. König-Ries: Datenbanksysteme5-23 Beispiel Wir betrachten die Relationen Weißweine und Verkäufe aus der Datenbasis eines Weinhändlers: Auf diese Datenbasis werde gleichzeitig von verschiedenen Verkäufern zugegriffen

24 SS 2004B. König-Ries: Datenbanksysteme5-24 R/W-Modell (Beispiel) Verkaufs-Transaktion (R: Riesling) wird vereinfacht zu: r[R] w[R] (Berechnung innerhalb der Transaktion wird nicht berücksichtigt!)

25 SS 2004B. König-Ries: Datenbanksysteme5-25 Beispiel 1 für Lost Update Die Verkäufer Müller und Schmidt sind beide gerade dabei Riesling zu verkaufen. Dazu lesen sie zunächst die aktuellen Bestände aus der Relation Weißweine aus, ändern diese dann und schreiben sie schließlich zurück. Herr Müller habe eine Kiste Riesling (R) verkauft, Herr Schmidt zwei. Es werde jeweils auf ein Tupel zugegriffen. Angenommen die Prozesse laufen zeitlich wie folgt verzahnt ab:

26 SS 2004B. König-Ries: Datenbanksysteme5-26 Beispiel 1 für Lost Update Analyse: Der in der Datenbasis erfasste Endbestand an Riesling ist nicht, wie es korrekt wäre, 31 Kisten, sondern 32. Die durch Hr. Müller eingebrachte Änderung ist verloren gegangen (lost update). Also Verstoß gegen lokale Konsistenz von Prozess Müller. Schema: r 1 [R] r 2 [R] w 1 [R] w 2 [R] w 1 [R] geht verloren.

27 SS 2004B. König-Ries: Datenbanksysteme5-27 Beispiel 2 für Dirty Read Dirty read: Lesen eines durch eine andere Transaktion geänderten Wertes, dessen Gültigkeit zum Zeitpunkt des Lesens noch nicht feststeht.

28 SS 2004B. König-Ries: Datenbanksysteme5-28 Beispiel 2 für Dirty Read Gegeben sei wieder die obige Situation. Wieder verkaufen die Herren Müller und Schmidt Riesling. Diesmal überlegt es sich allerdings der Käufer von Hr. Müller im letzten Moment anders und Hr. Müller ist gezwungen, die Verkaufstransaktion abzubrechen:

29 SS 2004B. König-Ries: Datenbanksysteme5-29 Beispiel 2 für Dirty Read Analyse: Hr. Schmidt hat einen im Nachhinein gesehen falschen Wert gelesen. Schema: r 1 [R] w 1 [R] r 2 [R] a 1 r 2 [R] liest illegitimen Wert R. Anmerkungen: Dirty read kann immer dann vorkommen, wenn eine Transaktion einen Wert einer anderen Transaktion vor deren commit liest.

30 SS 2004B. König-Ries: Datenbanksysteme5-30 Beispiel 3 für inconsistent read inconsistent read: Lesen von Zuständen, die aus Sicht der Transaktion zu unterschiedlichen Zeitpunkten gültig sind. Im einfachsten Fall möglich, wenn eine Transaktion von einer zweiten nebenläufigen Transaktion liest. Jetzt sieht nämlich die betrachtete Transaktion keinen konsistenten Zustand. Bei einer rein lesenden Transaktion mag dies gelegentlich tolerierbar sein.

31 SS 2004B. König-Ries: Datenbanksysteme5-31 Beispiel 3 für inconsistent read Die Herren Müller und Schmidt führen zum Jahresabschluss eine Inventur ihrer Bestände durch. Hr. Müller fragt die Bestände der einzelnen Sorten bei der Relation Weißweine ab und errechnet den Gesamtbestand. Hr. Schmidt stellt unterdessen fest, dass 10 Kisten Gutedel irrtümlich als Müller-Thurgau erfasst wurden. Er korrigiert die entsprechenden Bestände in der Relation.

32 SS 2004B. König-Ries: Datenbanksysteme5-32 Beispiel 3 für inconsistent read Gutedel: gültig zu Beginn von T 1 Müller-Thurgau: gültig mitten in T 1

33 SS 2004B. König-Ries: Datenbanksysteme5-33 Beispiel 3 für inconsistent read Analyse: Hr. Müller hat einen um 10 Flaschen zu geringen Bestand ermittelt. Schema: r 1 [G]r 1 [R]r 2 [M]r 1 [S]w 2 [M]r 2 [G]r 1 [W]w 2 [G]c 2 r 1 [M]c 1 r 1 [G] vor w 2 [G], aber r 1 [M] nach w 2 [M].

34 SS 2004B. König-Ries: Datenbanksysteme5-34 Serialisierbarkeitsprinzip Isolationsprinzip scheint zunächst streng serielle Abwicklung der Transaktionen zu fordern: r 1 (x) r 1 (y)... w 1 (z) c 1 r 2 (u) r 2 (v)... w 2 (w) c 2 r 3 (r) r 3 (s)... w 3 (t) c 3... (sogenannter serieller Schedule). Serielle Schedules sind aber viel zu ineffizient, da keinerlei Nebenläufigkeit möglich. Da Isolation nur besagt: Jede Transaktion muss ablaufen, als ob sie alleine abliefe, muss von korrekten Schedules nur Äquivalenz zu seriellen Schedules verlangt werden. Daher Betrachtung von serialisierbaren Schedules, wobei je nach Äquivalenzbegriff unterschiedliche Definitionen möglich sind.

35 SS 2004B. König-Ries: Datenbanksysteme5-35 Veranschaulichung von Schedules (1) Beispiel: Schedule r 1 (h) r 2 (a) r 1 (f) r 2 (e) w 2 (h) r 3 (a) r 1 (i) r 1 (d) w 1 (d) w 1 (f) r 1 (b) r 2 (g) w 1 (h) r 2 (d) w 1 (c) w 2 (c) r 1 (e) w 1 (i) c 1 w 3 (h) c 2 c 3. Schreibzugriff durch T2 Schreibzugriff durch T3 Lesezugriff durch T2 Lesezugriff durch T3 Legende: Schreibzugriff durch T1 Lesezugriff durch T1 Zeit Daten- elemente a b c d e f g h i

36 SS 2004B. König-Ries: Datenbanksysteme5-36 Veranschaulichung von Schedules (2) Beispiel: serieller Schedule r 1 (h) r 1 (f) r 1 (i) r 1 (d) w 1 (d) w 1 (f) r 1 (b) w 1 (h) w 1 (c) r 1 (e) w 1 (i) c 1 r 2 (a) r 2 (e) w 2 (h) r 2 (g) r 2 (d) w 2 (c) c 2 r 3 (a) w 3 (h) c 3. Zeit Daten- elemente a b c d e f g h i Schreibzugriff durch T2 Schreibzugriff durch T3 Lesezugriff durch T2 Lesezugriff durch T3 Legende: Schreibzugriff durch T1 Lesezugriff durch T1

37 SS 2004B. König-Ries: Datenbanksysteme5-37 Veranschaulichung von Schedules (3) Vereinfachte Darstellung desselben seriellen Schedules durch Annahme unendlich kurzer Ausführungszeiten für Operationen möglich. Jede Transaktion läuft damit konzeptuell zu einem bestimmten Zeitpunkt, dem Äquivalenzzeitpunkt. Schreibzugriff durch T2 Schreibzugriff durch T3 Lesezugriff durch T2 Lesezugriff durch T3 Legende: Schreibzugriff durch T1 Lesezugriff durch T1 Zeit Daten- elemente a b c d e f g h i Zeit Daten- elemente a b c d e f g h i T1T2T3

38 SS 2004B. König-Ries: Datenbanksysteme5-38 Serialisierbarkeit: Hilfsdefinitionen (1) Sei S globaler Schedule, der durch Verzahnung von Transaktionen T 1, T 2,..., T k entstanden ist. Eine Umordnung von S ist ein Schedule S', der dieselben Operationen wie S enthält und die Ordnung der Operationen innerhalb einer Transaktion erhält (d.h., beim Übergang von S zu S' wurden nur Operationen verschiedener Transaktionen vertauscht). Eine serielle Umordnung von S ist eine Umordnung von S, die zugleich ein serieller Schedule ist.

39 SS 2004B. König-Ries: Datenbanksysteme5-39 Serialisierbarkeit: Hilfsdefinitionen (2) T j liest x von T i in S, falls es Operationen w i (x) und r j (x) in S gibt mit: w i (x) erfolgt vor r j (x). a i und a j nicht in S. Es gibt keine Operation w k (x) zwischen w i (x) und r j (x), es sei denn a k ist in S. T i finalisiert x in S, wenn T i den Endzustand von x in S schreibt, d.h.: S enthält eine Schreiboperation w i (x). Nach w i (x) erfolgt kein Aufruf von a i. Es gibt keine Operation w k (x) nach w i (x), es sei denn, nach w k (x) erfolgt Aufruf von a k.

40 SS 2004B. König-Ries: Datenbanksysteme5-40 Serialisierbarkeit: Hilfsdefinitionen (3) Zwei Operationen o und o' in S sind unverträglich, wenn gilt: o und o' sind Lese- oder Schreiboperationen auf demselben Datenelement. o und o' werden von verschiedenen Transaktionen ausgeführt. Mindestens eine der beiden Operationen ist eine Schreiboperation.

41 SS 2004B. König-Ries: Datenbanksysteme5-41 Konfliktserialisierbarkeit Definition: Schedule S ist konfliktserialisierbar, wenn es serielle Umordnung S' von S gibt, sodass für alle unverträglichen Operationen o und o' gilt: o liegt vor o' in S o liegt vor o' in S'. S' heißt konfliktäquivalenter serieller Schedule zu S. Intuition: Alle Operationen, die potenziell Wechselwirkungen verursachen könnten, haben im realen Schedule und im äquivalenten seriellen Schedule dieselbe Reihenfolge.

42 SS 2004B. König-Ries: Datenbanksysteme5-42 Konfliktserialisierbarkeit: Veranschaulichung Existenz eines konfliktäquivalenten seriellen Schedules bedeutet: Operationen einer jeden Transaktion lassen sich auf Äquivalenzzeitpunkt zusammenziehen, ohne unverträgliche Operationen zu vertauschen. Durchführung für Schedule von vorhin zeigt: (für beliebige Wahl der Äquivalenzzeitpunkte) Zeit Daten- elemente a b c d e f g h i T1T2T3 unmöglich Schreibzugriff durch T2 Schreibzugriff durch T3 Lesezugriff durch T2 Lesezugriff durch T3 Legende: Schreibzugriff durch T1 Lesezugriff durch T1

43 SS 2004B. König-Ries: Datenbanksysteme5-43 Prüfung auf Serialisierbarkeit (1) Serialisierbarkeit bezieht sich grundsätzlich auf (erfolgreich) abgeschlossene Transaktionen, da abgebrochene Transaktionen aufgrund von Atomizität keine sichtbaren Auswirkungen haben dürfen und der Ausgang noch laufender Transaktionen offen ist. Bei Prüfung eines Schedule S auf Serialisierbarkeit daher zunächst Bildung der abgeschlossenen Projektion CP(S) durch Eliminieren der Operationen aller (noch) nicht mit commit abgeschlossenen Transaktionen.

44 SS 2004B. König-Ries: Datenbanksysteme5-44 Prüfung auf Serialisierbarkeit (2) Konfliktserialisierbarkeit ist relativ effizient zu entscheiden. Einfaches Kriterium: Zyklusfreiheit des Serialisierbarkeitsgraphen SG(S), der wie folgt konstruiert wird: SG(S) enthält einen Knoten K i für jede in CP(S) vorkommende Transaktion T i. Für jedes in CP(S) vorkommender Paar unverträglicher Operationen o i (x), o j (x) mit o i (x) vor o j (x) füge in SG(S) Kante von K i nach K j ein. (Bedeutung: In jedem zu CP(S) konfliktäquivalenten seriellen Schedule muss T i vor T j stattfinden.) Wenn SG(S) einen Zyklus enthält, ist CP(S) nicht konfliktserialisierbar, ansonsten liefert jede topologische Sortierung von SG(S) einen konfliktäquivalenten seriellen Schedule.

45 SS 2004B. König-Ries: Datenbanksysteme5-45 Prüfung auf Serialisierbarkeit (3) Aufbau des Serialisierbarkeitsgraphen für Beispiel-Schedule: T1 T2 T3 Schreibzugriff durch T2 Schreibzugriff durch T3 Lesezugriff durch T2 Lesezugriff durch T3 Legende: Schreibzugriff durch T1 Lesezugriff durch T1 Zeit Daten- elemente a b c d e f g h i

46 SS 2004B. König-Ries: Datenbanksysteme5-46 Prüfung auf Serialisierbarkeit (4) Frühere Schedules: S1: r 1 (B) r 2 (B) r 2 (T) w 2 (T) w 2 (B) c 2 r 1 (T) c 1 S2: r 2 (B) r 2 (T) r 1 (B) r 1 (T) c 1 w 2 (T) w 2 (B) c 2 S3: r 2 (B) r 2 (T) w 2 (T) r 1 (B) r 1 (T) c 1 w 2 (B) c 2 S4: r 2 (B) r 2 (T) w 2 (T) w 2 (B) r 1 (B) r 1 (T) a 2 c 1 nur T1 in CP! S5: r 3 (T) w 3 (T) r 2 (B) r 2 (T) w 2 (T) w 2 (B) c 2 r 3 (B) w 3 (B) c 3 S6: r 2 (B) r 2 (T) r 3 (T) w 3 (T) r 3 (B) w 3 (B) c 3 w 2 (T) w 2 (B) c 2 T1T2S1:T1T2S3:T1T2S2:T2T3S5:T2T3S6:

47 SS 2004B. König-Ries: Datenbanksysteme5-47 Prüfung auf Serialisierbarkeit (5) Neuer Schedule: S7: r 1 (B) r 2 (B) r 2 (T) r 1 (T) w 2 (T) r 3 (T) w 3 (T) w 2 (B) r 3 (B) w 3 (B) c 1 c 2 c 3 T1T2S7:T3 Äquivalenter serieller Schedule: T1 T2 T3 Betrachte: S8: r 2 (B) r 3 (T) w 2 (B) r 1 (B) w 3 (T) r 1 (T) c 1 c 2 c 3 T1 T2 S8: T3 Äquivalenter serieller Schedule: T2 T3 T1 und T3 T2 T1

48 SS 2004B. König-Ries: Datenbanksysteme5-48 Transaktion 1Transaktion 2... Transaktion n Synchronisation durch Scheduler Datenbasis-Verwalter lokaler Schedule 1lokaler Schedule n konfliktserialisierbarer globaler Schedule Synchronisation (1)

49 SS 2004B. König-Ries: Datenbanksysteme5-49 Scheduler muss spätestens bei Ausführung von c i entscheiden, wann T i im äquivalenten seriellen Schedule stattgefunden haben soll (Festlegung des Äquivalenzzeitpunkts von T i ). Ferner muss real durchgeführter Schedule zum gedachten seriellen Schedule sichten- bzw.konfliktäquivalent sein. Für noch laufende Transaktionen kann Scheduler sich Entscheidung offen halten, da für Serialisierbarkeit nur abgeschlossene Projektion des Schedules relevant ist. Transaktion 1Transaktion 2... Transaktion n Synchronisation durch Scheduler Datenbasis-Verwalter lokaler Schedule 1lokaler Schedule n konfliktserialisierbarer globaler Schedule Synchronisation (2) c1c1 Spielräume!

50 SS 2004B. König-Ries: Datenbanksysteme5-50 Transaktion 1Transaktion 2... Transaktion n Synchronisation durch Scheduler Datenbasis-Verwalter lokaler Schedule 1lokaler Schedule n konfliktserialisierbarer globaler Schedule Synchronisation (3) o1(x)o1(x) Mögliche Scheduler-Entscheidungen: Sofortige Ausführung der Operation durch Übermittlung an Datenbasis-Verwalter. Zurückstellung (durch Blockierung der zugehörigen Transaktion). Abbruch der zugehörigen Transaktion (und Rücksetzen aller bisher von ihr ausgeführten Operationen durch den Datenbasis-Verwalter). Ausführung einer bisher zurückgestellten Operation.

51 SS 2004B. König-Ries: Datenbanksysteme5-51 Synchronisation (4) Synchronisationsverfahren wird somit spezifiziert durch: Algorithmus zur Zuordnung von Äquivalenzzeitpunkten zu Transaktionen. Zeitpunkt, zu dem diese Zuordnung festgelegt, d.h. Transaktion in gedachten seriellen Schedule eingeordnet wird. Verfahren, mit dem Äquivalenz des realen zum gedachten seriellen Schedule garantiert wird. begin TA vs. commit vor vs. während vs. bei commit der TA Pessimistische Verfahren Optimistische Verfahren

52 SS 2004B. König-Ries: Datenbanksysteme5-52 Synchronisation (4) Synchronisationsverfahren wird somit spezifiziert durch: Algorithmus zur Zuordnung von Äquivalenzzeitpunkten zu Transaktionen. Zeitpunkt, zu dem diese Zuordnung festgelegt, d.h. Transaktion in gedachten seriellen Schedule eingeordnet wird. Verfahren, mit dem Äquivalenz des realen zum gedachten seriellen Schedule garantiert wird. begin TA vs. commit vor vs. während vs. bei commit der TA Pessimistische Verfahren Synchronisation mit Sperren Synchronisation mit Zeitstempeln

53 SS 2004B. König-Ries: Datenbanksysteme5-53 Synchronisation mit Sperren Sperrenbasierte Synchronisation = Gewinnung konfliktserialisierbarer Schedules ohne explizite Verwaltung des Serialisierbarkeitsgraphen (wäre viel zu aufwändig). Intuition: Für jede Transaktion wird als Äquivalenzzeitpunkt Zeitpunkt des commits gewählt. Äquivalenz des realen und seriellen Schedules wird gesichert, indem jede Operation o i (x), o {r,w}, das Datenelement x im Zeitintervall zwischen o i (x) und c i für unverträgliche Operationen anderer Transaktionen sperrt. Falls benötigte Sperre nicht sofort verfügbar ist, muss Transaktion bis zur Freigabe warten.

54 SS 2004B. König-Ries: Datenbanksysteme5-54 Sperren Transaktionen stehen drei Sperr-Operationen zur Verfügung: s(x) setzt share-Sperre auf Datenelement x, die fremde Schreib- Operationen ausschließt; x(x) setzt exclusive-Sperre auf Datenelement x, die fremde Schreib- und Lese-Operationen ausschließt; u(x) löst Sperre auf Datenelement x. Entwurfsspielräume für Sperren: Sperrgranulat: Feinheit der Unterteilung der Datenbasis für Sperrzwecke: Relation, Tupel, Tupelkomponente. Sperrart: Art der Festlegung der zu sperrenden Elemente. Objektsperre: Datenelemente werden explizit angegeben. Prädikatsperre: Datenelemente werden implizit durch logisches Prädikat spezifiziert.

55 SS 2004B. König-Ries: Datenbanksysteme5-55 Sperrverträglichkeit Sperren derselben Transaktion sind stets miteinander verträglich. Für Sperren verschiedener Transaktionen gilt folgende Verträglichkeitstabelle: –SX S – X –– Belegung Anforderung

56 SS 2004B. König-Ries: Datenbanksysteme5-56 Strenges Zwei-Phasen-Sperrprotokoll Umsetzung: Strenges Zwei-Phasen-Sperrprotokoll (S2PL). Regeln: Jede Transaktion muss vor Ausführung einer Operation r i (x) oder w i (x) eine s-Sperre bzw. eine x-Sperre auf x anfordern, dabei darf eine s-Sperre zu einer x-Sperre verschärft werden. Alle Sperren müssen bis zum commit oder abort gehalten werden. Datenelemente dürfen nicht mit unverträglichen Sperren belegt werden; ggf. muss eine Transaktion, die eine Sperre benötigt, warten. Resultat: Realer Schedule S ist konfliktäquivalent zu seriellem Schedule, der entsteht, wenn alle Transaktionen komplett zum Zeitpunkt ihres commits in S ausgeführt werden.

57 SS 2004B. König-Ries: Datenbanksysteme5-57 S2PL: Graphische Darstellung Platzierung der Sperren: Anzahl der gehaltenen Sperren: Zeit Anzahl Sperren AnforderungsphaseFreigabephase Zeit Daten- elemente a b c d e f g h i Commit T1 Legende: Schreibzugriff durch T1 Lesezugriff durch T1 shared-Sperre von T1 exclusive-Sperre von T1

58 SS 2004B. König-Ries: Datenbanksysteme5-58 S2PL: Beispiel Beispiel-Transaktionen: T 1 : s 1 (B) r 1 (B) s 1 (T) r 1 (T) u 1 (B) u 1 (T) c 1 T 2 : s 2 (B) r 2 (B) s 2 (T) r 2 (T) x 2 (T) w 2 (T) x 2 (B) w 2 (B) u 2 (T) u 2 (B) c 2 Sperrenverschärfung Vereinfachung - keine Sperrenverschärfung: T 1 : s 1 (B) r 1 (B) s 1 (T) r 1 (T) u 1 (B) u 1 (T) c 1 T 2 : x 2 (B) r 2 (B) x 2 (T) r 2 (T) w 2 (T) w 2 (B) u 2 (T) u 2 (B) c 2 Schedule S1: r 1 (B) r 2 (B) r 2 (T) w 2 (T) w 2 (B) c 2 r 1 (T) c 1 lässt sich nicht mehr konstruieren: s 1 (B) r 1 (B) x 2 (B) Fehlschlag, T2 blockiert, T1 fortgesetzt, z.B. s 1 (T) r 1 (T) u 1 (B) u 1 (T) c 1 x 2 (B) r 2 (B) r 2 (T) x 2 (T) w 2 (T) w 2 (B) u 2 (T) u 2 (B) c 2. Sperranweisungen herausprojiziert: r 1 (B) r 1 (T) c 1 r 2 (B) r 2 (T) w 2 (T) w 2 (B) c 2.rein seriell

59 SS 2004B. König-Ries: Datenbanksysteme5-59 Verklemmung: Beispiel Beispiel-Transaktionen: T 1 : s 1 (B) r 1 (B) s 1 (T) r 1 (T) u 1 (B) u 1 (T) c 1 T 2 : s 2 (B) r 2 (B) s 2 (T) r 2 (T) x 2 (T) w 2 (T) x 2 (B) w 2 (B) u 2 (T) u 2 (B) c 2 Schedule S1: r 1 (B) r 2 (B) r 2 (T) w 2 (T) w 2 (B) c 2 r 1 (T) c 1 lässt sich nicht mehr konstruieren: s 1 (B) r 1 (B) s 2 (B) r 2 (B) s 2 (T) r 2 (T) x 2 (T) w 2 (T) x 2 (B) Fehlschlag, T2 blockiert T1 fortgesetzt, s 1 (T) Fehlschlag, T1 blockiert --- keine Fortsetzung möglich ---

60 SS 2004B. König-Ries: Datenbanksysteme5-60 Verklemmungen Bei sperrenbasierter Synchronisation können sogenannte Verklemmungen (engl. deadlocks) auftreten, in denen Transaktionen sich gegenseitig durch ihre Sperren blockieren. Folgerung: Sperrenbasiertes Scheduling ist zwar pessimistisch, kann aber trotzdem in Situationen geraten, in denen keine serialisierbare Fortsetzung mehr möglich und Transaktionsabbruch erforderlich ist.

61 SS 2004B. König-Ries: Datenbanksysteme5-61 Erkennen von Verklemmungen Durch Timeout: Jede Sperrenanforderung wird mit maximaler Wartezeit versehen. Nach Ablauf wird Verklemmung angenommen. Einfach zu implementieren, kann aber zu irrtümlichen Abbrüchen oder verspäteter Entdeckung von Verklemmungen führen. Durch Wartegraph: Wartegraph enthält Knoten K i für jede aktive Transaktion T i sowie Kante von K i nach K j, falls Transaktion T i auf Transaktion T j wartet. Verklemmung wird durch Existenz eines Zyklus angezeigt. Verwaltung aufwendiger als Timeouts, liefert aber präzise Ergebnisse.

62 SS 2004B. König-Ries: Datenbanksysteme5-62 Behandlung von Verklemmungen (1) Auflösung (durch Transaktionsabbruch): Erfordert Erkennung der Verklemmung und Auswahl der abzubrechenden Transaktion. Bei mehreren Kandidaten Auswahl der abzubrechenden Transaktion über Kostenfunktion (z.B. bereits investierter Aufwand, Priorität, verbleibender Aufwand bis Abschluss). Ausgewählte Transaktion wird rückgesetzt und Sperren werden freigegeben.

63 SS 2004B. König-Ries: Datenbanksysteme5-63 Behandlung von Verklemmungen (2) T2T4 T3T1 T2T4 T1

64 SS 2004B. König-Ries: Datenbanksysteme5-64 Kapitel 5: Transaktionsverwaltung Transaktionsmodell Isolation Atomizität Dauerhaftigkeit

65 SS 2004B. König-Ries: Datenbanksysteme5-65 Rücksetzen Bisher betrachtetes Scheduling gewährleistet Isolation, d.h. Serialisierbarkeit, setzt jedoch voraus, dass Transaktionen abgebrochen und rückgesetzt werden können. Jetzt zu betrachten: Rücksetzmechanismen, die gewährleisten, dass nicht erfolgreiche Transaktionen keinerlei Effekte bewirken (Atomizität). Mögliche Gründe für Transaktionsabbruch: Selbstaufgabe (Ausführung von abort-Operation), Systembedingter Abbruch (z.B. wegen Verklemmung, Ressourcenmangel, I/O-Fehler), Systemzusammenbruch mit Verlust des Hauptspeicherinhalts.

66 SS 2004B. König-Ries: Datenbanksysteme5-66 Rücksetzbarkeit von Schedules (1) Rücksetzen einer Transaktion T i kann andere Transaktion T j beeinflussen, die bereits von T i gelesen hat und deshalb nun ebenfalls rückgesetzt werden muss. Zur Erinnerung: Konfliktserialisierbarer (fast serieller) Schedule S4: r 2 (B) r 2 (T) w 2 (T) w 2 (B) r 1 (B) r 1 (T) a 2 c 1. CP(S4): Nur T 1 ! Da aber T 1 Wert B (und T) von T 2 gelesen hat (dirty read), kann Atomizität von T 1 nur durch Rücksetzen von T 1 erreicht werden. Vorgang ist als kaskadierendes Rücksetzen bekannt unerwünscht, da Arbeit von T 1 verloren geht.

67 SS 2004B. König-Ries: Datenbanksysteme5-67 Rücksetzbarkeit von Schedules (2) Betrachte konfliktserialisierbaren (fast seriellen) ScheduleS10: r 3 (T) w 3 (T) r 3 (B) w 3 (B) r 2 (B) r 2 (T) w 2 (T) w 2 (B) c 2 c 3. Rücksetzen von T 3 fatal, da wegen dirty read auch T 2 rückzusetzen wäre, dies aber die Persistenz von T 2 verletzen würde. Folgerung: Für Zwecke der Rücksetzbarkeit muss Menge der zulässigen Schedules über Serialisierbarkeit hinaus eingeschränkt werden. a3a3 Zum Vergleich: Kaskadierendes RücksetzenS10: r 3 (T) w 3 (T) r 3 (B) w 3 (B) r 2 (B) r 2 (T) w 2 (T) w 2 (B) c 3 c 2. a3a3

68 SS 2004B. König-Ries: Datenbanksysteme5-68 Rücksetzbarkeit von Schedules (3) Definition: Sei S Schedule. S heißt rücksetzbar (wiederanlaufbar), wenn für alle Transaktionen T i, T j mit i j gilt: wenn T j irgendein Datenelement x von T i liest und S den Aufruf c j enthält, dann enthält S auch c i, und c i erfolgt vor c j. S vermeidet kaskadierendes Rücksetzen, wenn für alle Transaktionen T i, T j mit i j gilt: wenn T j irgendein Datenelement x von T i liest, dann erfolgt zwischen w i (x) und r j (x) ein Aufruf von c i. S heißt rigoros, wenn für alle Transaktionen T i, T j in CP(S) mit i j gilt: wenn o i (x) vor o j (x) in S und o i (x) unverträglich mit o j (x), dann erfolgt c i vor o j (x). Rigorose Schedules vermeiden kaskadierendes Rücksetzen und sind konfliktserialisierbar. S2PL erzeugt rigorose Schedules S2PL löst Isolation und Atomizität.

69 SS 2004B. König-Ries: Datenbanksysteme5-69 Transaktion 1Transaktion 2... Transaktion n Synchronisation durch Scheduler Segment-Verwalter Atomizität, Dauerhaftigkeit lokaler Schedule 1lokaler Schedule n konfliktserialisierbarer, wiederanlaufbarer globaler Schedule Zusammenspiel mit Segment-Verwalter (1) Abstimmung bei commit und rollback Konflikt-Resistenz Fehler-Resistenz

70 SS 2004B. König-Ries: Datenbanksysteme5-70 Zusammenspiel mit Segment-Verwalter (2) Lokales Zwei-Phasen-Festschreibe-Protokoll: 1.Sichern der Persistenz oder Fehler-Resistenz: Der Segment-Verwalter schreibt den Anfangszustand (bei rollback aufgrund von abort) oder den Endzustand (bei commit) der Transaktion fest. Nach Abschluss dieser Phase wird die erfolgreiche Transaktion als wiederholbar bezeichnet, die abgebrochene Transaktion als wiederanlaufbar, sofern sie ihren Abbruch nicht selbst verschuldet hat. 2.Freigabe der Betriebsmittel: Anschließend können alle von der Transaktion benutzten Betriebsmittel freigegeben werden. Insbesondere löst der Scheduler alle von der Transaktion gehaltenen Sperren.

71 SS 2004B. König-Ries: Datenbanksysteme5-71 Transaktionszustände potenziellaktivblockiert geschei- tert abge- schlossen wieder- holbar auf- gegeben wieder- anlaufbar inkarnieren neustarten undo abbrechen einbringen verdrängen beenden festschreiben

72 SS 2004B. König-Ries: Datenbanksysteme5-72 Kapitel 5: Transaktionsverwaltung Transaktionsmodell Isolation Atomizität Dauerhaftigkeit

73 SS 2004B. König-Ries: Datenbanksysteme5-73 Robustheitsgarantien Dauerhaftigkeit kann nur in die Zuständigkeit des Segment-Verwalters fallen. Gefährdungen: Kurzer Zeithorizont: Systemabsturz. Längerer Zeithorizont: Plattenspeicherfehler, Feuer, Wasser, Sabotage, alle resultierend im Medienverlust. Garantien: Nach restart Abbrechen (undo) aller zum Katastrophenzeitpunkt noch aktiven Transaktionen. Wiederholen (redo) aller zum Katastrophenzeitpunkt erfolgreich abgeschlossenen Transaktionen. Wegen unterschiedlicher Zeithorizonte unterschiedliche technische Lösungen!

74 SS 2004B. König-Ries: Datenbanksysteme5-74 Undo/Redo-Prinzip Zeit dauerhaft gesichert T1T1 T4T4 T5T5 Katastrophe T2T2 ignoriert redo T3T3 undo


Herunterladen ppt "SS 2004B. König-Ries: Datenbanksysteme5-1 Kapitel 5: Transaktionsverwaltung Transaktionsmodell Isolation Atomizität Dauerhaftigkeit Folien: © Prof. Lockemann,"

Ähnliche Präsentationen


Google-Anzeigen