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

1Jürgen Broß <[email protected]>

Ü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



•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



•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.



•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



•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:



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



•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.



•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.



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



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



•Beschreibe das 2PC-Protokoll!





Documents

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