Übung: Transaktionale Systeme (Zusammenfassung der Vorlesungsinhalte) 12.07.2007

Ü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]

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.

Transaktionales Modell Weitere Charakteristika von Transaktionen Flache vs. verschachtelte (nested) Transaktionen (Transaktionsbaum) Zentralisierte vs. verteilte Transaktionen Kurzlebige vs. langlebige Transaktionen (Beispiel CAD-Design) Typische Architekturen für Transaktionverarbeitungssysteme TP-Monitor 3-Schichten-Architektur Föderative Mehrschicht-Architektur

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

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 Weitere Begriffe: Schedule Serielle Historie

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.

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.

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‘)

Behandlung von Transaktionabbrüchen Definiere Rücksetzbarkeit (RC) eines Schedules Ein Schedule S ist rücksetzbar wenn gilt: (Ti, x, Tj) in RF(S), i > 0, j < f  ci < cj 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)  ci < rj [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.: w1[x]3 w2[x]2 a1 a2

Behandlung von Transaktionabbrüchen 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)

Übersicht: Serialisierbarkeit

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

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)? Kontenmenge := 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

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.

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.

Synchronisation in verteilten Datenbanken

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:

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

Synchronisation in Data-Sharing-Systemen Skizziere das Callback-Locking-Verfahren

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)

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.

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

Multiversions Synchronisationsverfahren (MVCC) Erkläre grob das MVTO-Verfahren! Jede Transaktion Ti bekommt Zeitstempel ts(Ti) Leseoperation ri(x) wird umgewandelt in r(xk), wobei xk 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 wi(x) wird umgewandelt in w(xi), wenn kein Leser existiert, der eigentlich w(xi) hätte lesen sollen, aber schon eine ältere Version gelesen hat:  Abbruch, wenn ein rj(xk) existiert mit ts(tk) < ts(ti) < ts(tj) Vermeidung kaskadierender Abbrüche:  Verzögerung von ci 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.

Multiversions Synchronisationsverfahren (MVCC) Wieviele „committete“ Versionen existieren im MV2PL-Verfahren? Genau eine Version. Wieviele „uncommitted“ Versionen existieren im MV2PL-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)

Multiversions Synchronisationsverfahren (MVCC) Wie sieht die Kompatibilitätsmatrix für MV2PL aus?

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)

Fehlertolerante verteilte Transaktionen Beschreibe das 2PC-Protokoll!

Fehlertolerante verteilte Transaktionen

Fehlertolerante verteilte Transaktionen