1 Jürgen Broß Übung: Transaktionale Systeme (Zusammenfassung der Vorlesungsinhalte) 08.07.2010.

Präsentation zum Thema: "1 Jürgen Broß Übung: Transaktionale Systeme (Zusammenfassung der Vorlesungsinhalte) 08.07.2010."—  Präsentation transkript:

1 1 Jürgen Broß Übung: Transaktionale Systeme (Zusammenfassung der Vorlesungsinhalte) 08.07.2010

2 2 Jürgen Broß Überblick Transaktionskonzept Serialisierbarkeitstheorie (zentrale DB) Sperrbasierte Synchronisation Serialisierbarkeit und Synchronisation in verteilten DB Synchronisationsverfahren ohne Sperren Multiversionsverfahren Two-Phase-Commit und Varianten Replikation [Weiterführende Transaktionsmodelle und Webservice Transactions]

3 3 Jürgen Broß Transaktionales Modell Was ist eine Transaktion? VWL: Einigung über die gegenseitige Übertragung von Verfügungsrechten an Gütern oder Dienstleistungen. Informatik: Feste Folge von Operationen, die als logische Einheit betrachtet werden. Den ausgeführten Operationen werden durch den transaktionalen Kontext bestimmte Eigenschaften (siehe unten) garantiert. Was sind die ACID-Eigenschaften einer Transaktion? Atomicity: Alles-oder-Nichts-Eigenschaft, keine partiellen Resultate Consistency: Bewahrung der DB-Konsistenz z.B. durch Forcierung der referentiellen Integrität, Check-Constraints (grundsätzlich aber Aufgabe des transaktionalen Programms) Isolation: Keine Interferenzen zwischen parallel laufenden Transaktionen. Effekt einer Transaktion derselbe, als wenn diese allein laufen würde. Durabality: Nach Transaktionscommit sind die Änderungen selbst über Systemfehler hinweg persistent.

4 4 Jürgen Broß Transaktionales Modell Weitere Charakteristika von Transaktionen Flache vs. verschachtelte (nested) Transaktionen (Transaktionsbaum) Zentralisierte vs. verteilte Transaktionen Kurzlebige vs. langlebige Transaktionen (Beispiel CAD-Design)

5 5 Jürgen Broß Serialisierbarkeitstheorie Erklären Sie die folgenden Phänomene: Read Uncommitted Lesen von Daten, die noch nicht von einer TA per commit festgeschrieben worden sind  Gefahr eines Dirty Reads Dirty Read Eine abgeschossene TA hat Daten gelesen, die von einer abgebrochenen TA geschrieben wurden. Lost Update Transaktion2 liest veraltetes Datum X und überschreibt dieses Ziel der Serialisierbarkeitstheorie Korrektheitskriterien für verschachtelte Ausführung von Transaktionen Serielle Ausführung von Transaktionen ist per se korrekt Definiere Äquivalenzrelationen zwischen Historien Historie ist korrekt, wenn sie äquivalent zu einer beliebigen seriellen Historie ist

6 6 Jürgen Broß Serialisierbarkeitstheorie Was ist eine Historie? Historie H einer endlichen Menge von Transaktionen T = {T1,…, Tn} ist eine partielle Ordnung (H, <) der Operationen aus T1,…,Tn mit den folgenden Eigenschaften: Alle Operationen aus T1,…,Tn sind in H enthalten Restriktion von H auf Ti ergibt Ti  Schritte aus Ti sind in H in derselben Reihenfolge Alle Konfliktoperationen sind geordnet

7 7 Jürgen Broß Konfliktserialisierbarkeit Wann stehen zwei Operationen p, q in Konflikt? Wenn beide Operationen auf dem gleichen Datum arbeiten und mind. eine der Operationen eine Schreiboperation ist! Die Operationen stehen nicht in Konflikt, wenn diese vom gleichen Transaktionsprogramm ausgeführt werden! Bsp.: r1[x] w2[x], w1[x] w2[x], w1[x] r2[x] Wann sind zwei Historien H und H‘ konfliktäquivalent? Alle Konfliktpaare beider Historien sind in derselben Reihenfolge geordnet. Wann ist eine Historie H konfliktserialisierbar? Eine Historie H ist konfliktserialisierbar genau dann, wenn eine serielle Historie H‘ existiert, die konfliktäquivalent zu H ist.

8 8 Jürgen Broß Konfliktserialisierbarkeit Was ist ein Serialisierbarkeitsgraph (SG)? Gerichteter Graph mit Knotenmenge T={T1,…,Tn} Eine Kante (Ti, Tj) zeigt an, dass zwischen Transaktion Ti und Tj eine Konfliktoperation besteht und die Operation von Ti in der Historie vor der Operation von Tj ausgeführt wird. Was besagt das Serialisierbarkeitstheorem? Eine Historie ist genau dann konfliktserialiserbar, wenn der Serialisierbarkeitsgraph SG keinen Zyklus enthält.

9 9 Jürgen Broß Viewserialisierbarkeit Welche Überlegung steckt hinter der Abschwächung der Konfliktserialisierbarkeit hin zur Viewserialisierbarkeit? Wenn keine Transaktion ein Datum X liest, das von anderer Transaktion zuvor geschrieben wurde, besteht keine Gefahr für die Konsistenz von X. Bsp.: r2[y] w2[x] r1[x] r3[x] w1[y] w2[y] w3[y] c1 c2 c3 (nicht serialisierbar) r2[y] w2[x] w2[y] c2 r1[x] w1[y] c1 r3[x] w3[y] c3 (hat selben Effekt) Wie ist die Read-From Relation (RF) definiert? Ein Triple (Ti, x, Tj) ist in RF enthalten, genau dann, wenn Transaktion Tj das Datum x liest und Ti die letzte Transaktion ist, die x geschrieben hat. D.h. Tj liest x von Ti. Zusätzliche Hilftransaktionen To und Tf Wann sind zwei Historien H, H‘ viewäquivalent? Genau dann, wenn RF(H) = RF(H‘)

10 10 Jürgen Broß Korrektheit bzgl. Recovery Definiere Rücksetzbarkeit (RC) eines Schedules Ein Schedule S ist rücksetzbar wenn gilt: (Ti, x, Tj) in RF(S), i > 0, j < f  c i < c j D.h. wenn eine Transaktion j von Transaktion i liest, dann darf j erst committen, wenn sichergestellt ist, dass i mit commit abgeschlossen wurde. Definiere Vermeidung von kaskadierendem Abort (ACA) Ein Schedule S ist in der Klasse ACA, wenn Transaktionen nur Daten lesen, die bereits committed sind. (Ti, x, Tj) in RF(S)  c i < r j [x] Definiere die Klasse von strikten Schedules (ST) Ein Schedule ist strikt, wenn alle Transaktionen ausschließlich „committete“ Daten lesen und überschreiben. Warum macht es Sinn die Striktheit von Historien zu fordern? Vermeidung von Problemen bei Wiederherstellung von Before-Images. Bsp.: x = 1; w1[x,2] w2[x,3] a1 c2 (erst undo und dann redo notwendig)

11 11 Jürgen Broß Korrektheit bzgl. Recovery Definiere die Klasse rigoroser Schedules (RG) Schedule ist rigoros, wenn er strikt ist und zusätzlich gilt, dass eine Transaktion ein Datum x nicht überschreibt, bevor nicht alle Transaktionen, die x gelesen haben, committet sind. Bsp.: (nicht rigoros) w1[x] w1[y] r2[u] c1 w2[x] r2[y] w2[y] w3[u] c3 c2 In welchem Zusammenhang ist die Forderung nach Rigorosität eines Schedules sinnvoll? In heterogenen verteilten Systemen ist ein globaler Schedule serialisierbar, wenn alle lokalen Scheduler rigorose Schedules erzeugen. (+ Forderung nach Commit-Verzögerung)

12 12 Jürgen Broß Übersicht: Serialisierbarkeit

13 13 Jürgen Broß Sperrbasierte Synchronisation Beschreibe das 2PL-Protokoll. Welche Regeln müssen beim Sperren eines Datums eingehalten werden? Sperren müssen gewährt sein, bevor auf Datum gearbeitet werden kann! Sperre solange halten, bis Bearbeitung abgeschlossen! Niemals eine Sperre erneut anfordern, nachdem sie bereits aufgegeben worden ist!  „No Lock After Unlock“ Was ist eine Kompatibilitätsmatrix? Tabelle, die angibt welche Sperren miteinander verträglich sind. Sperre S2 kompatibel zu Sperre S1 := Wenn bereits Sperre S1 auf Datum vorhanden ist, dann kann S2 gewährt werden. Bsp.: Lesesperren sind kompatibel Beweisskizze, dass 2PL konfliktserialisierbare Schedules garantiert

14 14 Jürgen Broß Sperrbasierte Synchronisation Garantiert 2PL Rücksetzbarkeit von Schedules? Nein! Striktes 2PL (Schreibsperren erst nach Commit aufgeben) garantiert Schedules aus Klasse ST  Schedules sind rücksetzbar und vermeiden kaskadierende Abbrüche Welcher Zusammenhang besteht zwischen dem Auftreten eines Deadlocks und der Serialisierbarkeit eines 2PL-Schedules? Das Auftreten eines Deadlocks signalisiert, dass ein Zyklus im Serialisierbarkeitsgraphen (SG) auftreten würde. Deadlock verhindert also das Auftreten eines Zyklus im SG. Was ist ein Wartegraph (WG)? Knotenmenge := aktive Transaktionen Kante (Ti, Tj) in WG existiert, wenn Tj Sperre auf Datum hält für welches Ti eine imkompatible Sperre anfordert. Zyklus in WG  Deadlock  Abbruch einer beteiligten Transaktion

15 15 Jürgen Broß Sperrbasierte Synchronisation Welche zwei Verfahren zur verteilten Deadlockerkennung wurden in der Vorlesung vorgestellt? Idee/Funktionsweise! Edge-Chasing: Probe-Message über „Wartepfad“ schicken. Wenn Nachricht wieder am Ursprung ankommt besteht Zyklus, also Deadlock. Path-Pushing: Baue globalen Wartegraphen aus lokalen Wartegraphen auf. Was sind Intention-Locks? In welchem Zusammenhang werden diese verwendet? Intention-Locks spielen eine Rolle im Zusammenhang mit multigranularem Sperren (MGL). Ein Intention-Lock auf einer Sperrebene (z.B. Table, Page oder Record) sagt aus, dass auf einer der darunterliegenden Ebenen eine Sperre existiert. Vorteil: Beim Sperren eines Unterbaums, braucht dieser nicht komplett nach evtl. vorhandenen inkompatiblen Sperren durchsucht werden.

16 16 Jürgen Broß Sperrbasierte Synchronisation Erkläre das Tree-Lock-Protokoll! Welche Regeln sind einzuhalten? Regel1: Sperre auf Knoten x kann nur gewährt werden, wenn Prozess Sperre auf dem Elternknoten hält. Regel2: Wenn Sperre auf Knoten x aufgegeben wird, kann diese nicht wieder gewährt werden. Welches Problem entsteht im Tree-Lock-Protokoll, wenn eine zusätzliche Sperre eingeführt wird (Shared), die kompatibel zu sich selbst ist? Aufgrund der Kompatibilität der Sperre können sich Prozesse im Baum gegenseitig überholen. Die Serialisierbarkeit der Operationen ist nicht mehr gewährleistet. Funktioniert das einfache Tree-Lock-Protokoll in einem B-Baum? Nein! Es kann passieren, dass nach einem Split eine Sperre angefordert werden muss, die schon aufgegeben wurde. Knoten nur entsperren, wenn Nachfolger „split-safe“ ist.

17 17 Jürgen Broß Synchronisation in verteilten Datenbanken

18 18 Jürgen Broß Synchronisation in verteilten Datenbanken Was ist ein indirekter Konflikt? Zwei Transaktionen T, T‘ stehen in einem indirekten Konflikt, wenn sie nicht in einem direkten Konflikt stehen, aber ein Pfad zwischen T und T‘ im Konflikt- /Serialisierbarkeitsgraphen existiert. Beispiel für zwei globale, nur lesende Transaktionen, die in Konflikt stehen:

19 19 Jürgen Broß Synchronisation in verteilten Datenbanken Welche Anforderungen an lokale Scheduler sind ausreichend, dass globale Serialisierbarkeit in heterogener Umgebung garantiert werden kann? Rigorosität (siehe oben) Commit-Verzögerung (commit deferred) bei globalen Transaktionen: GTM schickt erst dann commit an lokale Scheduler, wenn alle Operationen bestätigt worden sind Nenne weiteres Verfahren um globale Serialisierbarkeit in heterogener verteilter DB zu garantieren. Ticketverfahren Idee: Jede globale Transaktion liest spezielles Ticketdatum auf lokalem Server und inkrementiert dieses GTM bildet globalen Ticketgraphen. Kante Ti  Tj, wenn Ti kleineres Ticket als Tj an einem Server gelesen hat Ticketgraph azyklisch  globale Serialisierbarkeit

20 20 Jürgen Broß Synchronisation in Data-Sharing-Systemen Skizziere das Callback-Locking-Verfahren

21 21 Jürgen Broß Synchronisationsprotokolle ohne Sperren Nenne das Grundprinzip des Timestamp-Ordering-Verfahrens (TO)! Brich eine Transaktion ab, wenn sie eine Operation „zu spät“ ausführt. „Zu spät“: physikalisch nicht mehr realisierbar (Zeitmaschine nicht existent) Was bedeuten die Werte maxW[x] und maxR[x] eines Datums x? Die Variable maxW[x] hat als Wert den Zeitstempel der Transaktion, die zuletzt x geschrieben hat. Gleiches gilt analog für maxR[x]. Transaktion Ti mit Zeitstempel ts(Ti) will Datum x lesen. Wann muss die Transaktion abgebrochen werden? Wenn bereits ein jüngerer Schreiber x modifiziert hat: maxW[x] > ts(Ti) Transaktion Ti mit Zeitstempel ts(Ti) will Datum x schreiben. Wann muss die Transaktion abgebrochen werden? Wenn bereits jüngerer Leser x gelesen hat: maxR[x] > ts(Ti)

22 22 Jürgen Broß Synchronisationsprotokolle ohne Sperren Wann kann die Thomas-Write-Rule angewendet werden? maxR[x] < ts(Ti) < maxW[x] Ignoriere das Schreiben auf x durch Transaktion Ti! Wie wird im TO-Verfahren ein Dirty Read verhindert? Einführung eines commit-Bits Ist commit-Bit nicht gesetzt, so muss ein Leser/Schreiber solange warten, bis das Bit wieder gesetzt ist, d.h. die modifizierende TA committet oder aborted ist.

23 23 Jürgen Broß Synchronisationsprotokolle ohne Sperren Welche drei Phasen unterscheidet man bei optimistischen Synchronisationsverfahren? Lesephase: Updates nur auf privaten Kopien Validierungsphase „Forward Oriented Optimistic CC“ (FOCC): Schnitt der Lesemenge (Readset) aller laufenden Transaktionen mit Schreibmenge (Writeset) der zu validierenden TA ist leer?  leer: OK  nicht leer: geeignete Transaktion (laufende oder zu validierende) abbrechen Schreibphase: Einbringen der Daten in die Datenbasis

24 24 Jürgen Broß Multiversions Synchronisationsverfahren (MVCC) Erkläre grob das MVTO-Verfahren! Jede Transaktion Ti bekommt Zeitstempel ts(Ti) Leseoperation r i (x) wird umgewandelt in r(x k ), wobei x k die Version von x ist, die den größten Zeitstempel <= ts(ti) besitzt.  Transaktion liest stets den Wert, der vom jüngsten Schreiber, der älter ist als lesende Transaktion, geschrieben wurde. Schreiboperation w i (x) wird umgewandelt in w(x i ), wenn kein Leser existiert, der eigentlich w(x i ) hätte lesen sollen, aber schon eine ältere Version gelesen hat:  Abbruch, wenn ein r j (x k ) existiert mit ts(t k ) < ts(t i ) < ts(t j ) Vermeidung kaskadierender Abbrüche:  Verzögerung von c i bis alle Transaktionen, von denen Ti Versionen gelesen hat, committet sind. Können Read-Only-Transaktionen in MVTO abgebrochen werden? Nein, es existiert immer eine Version, so dass konsistentes Lesen gewährleistet ist.

25 25 Jürgen Broß Multiversions Synchronisationsverfahren (MVCC) Wieviele „committete“ Versionen existieren im 2V2PL-Verfahren? Genau eine Version. Wieviele „uncommitted“ Versionen existieren im 2V2PL-Verfahren? Auch genau eine Version. Schreibsperren sind nicht kompatibel. Was ist die Konvertierungsphase? Warum ist sie besonders kritisch? In der Konvertierungsphase werden neu erzeugte Versionen (private Kopien) in gültige Versionen konvertiert, so dass Leser die neue Version lesen können. Während der Konvertierung darf kein Leser das Datum lesen  Könnte zweimal lesen und dann verschiedene Werte vorfinden Wenn ein aktiver Leser bereits „alte“ (gültige) Version gelesen hat, dann darf nicht konvertiert werden Erst konvertieren, wenn alle Transaktionen committed sind, von denen konvertierende TA gelesen hat. (  ACA)

26 26 Jürgen Broß Multiversions Synchronisationsverfahren (MVCC) Wie sieht die Kompatibilitätsmatrix für 2V2PL aus?

27 27 Jürgen Broß Fehlertolerante verteilte Transaktionen Was ist ein Fehlermodell? Beschreibt welche Fehler auftreten können. Beschreibt mit welchen Fehlern ein System umgehen kann bzw. welche Fehler vernachlässigt werden. Frequenz von Fehlern (z.B. MTTF). Welche Fehler müssen typischerweise von einem DBMS toleriert werden? Transaktionsabbrüche (durch Nutzer oder System  Deadlock) Systemfehler (Prozessor-, Speicherfehler, etc.) Kommunikationsfehler Fehler von Hintergrundspeichermedien (Headcrash einer Festplatte)

28 28 Jürgen Broß Fehlertolerante verteilte Transaktionen Beschreibe das 2PC-Protokoll!

29 29 Jürgen Broß Fehlertolerante verteilte Transaktionen

30 30 Jürgen Broß Fehlertolerante verteilte Transaktionen

31 31 Jürgen Broß 2PC Optimierungen Welche Nachrichten und forcierten Log-Einträge können bei der Optimierung „presumed abort“ gespart werden? Begründen Sie! Nachrichten: ack-abort Logs: begin (C), abort (C, P) Welche Nachrichten und forcierten Log-Einträge können bei der Optimierung „presumed commit“ gespart werden? Begründen Sie! Nachrichten: ack-commit Logs: commit (P) Erklären Sie kurz die Optimierung von hierarchischem 2PC, wenn Read-Only-Unterbäume existieren. Zusätzliche Antwortmöglichkeit auf prepare des Koordinators (read-only) Sperren werden sofort aufgegeben, keine weitere Teilnahme im Protokoll

32 32 Jürgen Broß 3PC Erläutern Sie den Ablauf des 3PC-Protokolls. Wie verhalten sich die Teilnehmer im Fehlerfall (Timeout / Restart)?

33 33 Jürgen Broß 3PC Unter welchem Fehlermodell ist 3PC nicht blockierend? Kommunikationsfehler ausgeschlossen. (insbesondere keine Netzpartitionierung!) Beliebig viele Ausfälle. Begründen Sie grob unter Verweis auf die Unterschiede zum 2PC- Protokoll, warum 3PC unter obigem Fehlermodell nicht blockierend ist. Grundlegend geht es darum eine „unabhängige Wiederherstellbarkeit (Recovery)“ gewährleisten zu können. Es muss vermieden werden, dass globale Zustände existieren, die als Folgezustand sowohl commit, als auch abort haben können. Bei 2PC wäre der prepared-Zustand so ein zu vermeidender Zustand, bei 3PC existiert ein solcher Zustand nicht. Welches Problem kann bei Netzpartitionierung auftreten?

34 34 Jürgen Broß 3PC

35 35 Jürgen Broß 3PC