TRANSAKTIONEN UND DATENINTEGRITÄT

Transkript

1 Transaktionen und Datenintegrität 1 TRANSAKTIONEN UND DATENINTEGRITÄT Concurrency Control and Recovery in Database Systems P.A. Bernstein, V. Hadzilacos, N. Goodman Addison Wesley, Kapitel 1. und 6.

2 Transaktionen und Datenintegrität 2 Begriffe: Integritätsbedingungen und Konsistenz: Eine Datenbank ist konsistent, wenn sie eine Menge vorgegebener logischer Bedingungen erfüllt, die Integritätsbedingungen genannt werden.

3 Transaktionen und Datenintegrität 3 Transaktionen: Ein Benutzer verwendet eine Datenbank, indem er eine Folge von Zugriffsbefehlen (Lese- und Update- Befehle) auf dieser Datenbank ausführt. Eine derartige Befehlsfolge wird Transaktion genannt und führt die Datenbank von einem konsistenten Zustand in einen anderen konsistenten Zustand über. Führt eine Transaktion nur Lesezugriffe durch, dann wird sie als Lese-Transaktion bezeichnet, sonst als Update-Transaktion.

4 Transaktionen und Datenintegrität 4 Eigenschaften von Transaktionen: 1. Atomizität (atomicity) Ausführung entweder zur Gänze oder gar nicht. 2. Konsistenz (consistency) Eine Transaktion führt von einem konsistenten Zustand in einen anderen konsistenten Zustand. 3. Isolation Teilergebnisse bleiben bis zum Ende einer Transaktion für alle anderen unsichtbar. 4. Dauerhaftigkeit (durability) Die Ergebnisse einer erfolgreich durchgeführten Transaktion bleiben erhalten.

5 Transaktionen und Datenintegrität 5 Beispiel: Bank-Überweisung von Konto auf Sparbuch. Datenstruktur: SPARBUCH (SPNR, EINLAGE, BESITZER) KONTO (KNR, KSTAND) SPAREINLAGEN-GESAMT Integritätsbedingung: KSTAND >= 0 EINLAGE > 0 SPAREINLAGE-GESAMT = Summe EINLAGE

6 Transaktionen und Datenintegrität 6 Transaktion: Umbuchung Buche 500,- DM von Konto 123 auf Sparbuch 321 begin transaction update KONTO set KSTAND = KSTAND where KNR = 123; update SPARBUCH set EINLAGE = EINLAGE where SPNR = 321; SPAREINLAGE-GESAMT := SPAREINLAGE-GESAMT end transaction

7 Transaktionen und Datenintegrität 7 Parallelausführung von Transaktionen (concurrent execution of transactions): Vereinfachtes Modell: atomare Objekte: haben Name und Wert atomare Datenbank-Operationen: Wert lesen: Wert ändern: Read(x) Write(x) Write(x, Wert) Transaktions-Operationen: Start, Commit, Abort

8 Transaktionen und Datenintegrität 8 Beispiel: Transaktion 1: Überweisung von Konto auf Sparbuch: Read(Konto) Konto := Konto Write(Konto) Read(Sparbuch) Sparbuch := Sparbuch Write(Sparbuch) Transaktion 2: Überweisung der Telefonrechnung: Read(Konto) Konto := Konto - 174,38 Write(Konto) Read(Tele-Konto) Tele-Konto := Tele-Konto + 174,38 Write(Tele-Konto)

9 Transaktionen und Datenintegrität 9 Transaktions-Operationen: Start Die Operation Start kennzeichnet den Beginn der Ausführung einer neuen Transaktion. Commit Durch das Ausführen einer Commit Operation teilt ein Programm der Datenbank mit, daß die Transaktion normal beendet wurde und alle Änderungen permanent gemacht werden sollen. Abort Durch Ausführen einer Abort Operation teilt ein Programm der Datenbank mit, daß die Transaktion abnormal beendet wurde und alle Änderungen verworfen werden sollen.

10 Transaktionen und Datenintegrität 10 Transaktions Syntax Benutzersicht: Eine Transaktion ist die Ausführung von einem oder mehreren Programmen die Datenbank- und Transaktionsoperationen beinhalten. Beispiel: Banking Datenbank

11 Transaktionen und Datenintegrität 11 Transaktion: Buche Geld von einem Konto auf ein anderes. Procedure Transfer begin Start; input (fromaccount, toaccount, amount); temp := Read(Accounts [fromaccount]); if temp < amount then begin output("kontostand nicht ausreichend"); Abort; end else begin Write(Accounts[fromaccount], temp - amount); temp := Read(Accounts [toaccount]) Write(Accounts[toaccount], temp + amount); Commit; output("buchung vollständig"); end; return; end

12 Transaktionen und Datenintegrität 12 Die dafür verwendete Sprache kann sein: eine Datenbank-Abfragesprache (Query Language) eine Report-Beschreibungssprache (4GL) Eine High-Level Programmiersprache mit eingebetteten Datenbank Operationen.

13 Transaktionen und Datenintegrität 13 Commit und Abort Eine Transaktion die eine Start Operation ausgeführt hat, heißt aktiv. Commit Operation ausgeführt hat, heißt committed. Abort Operation ausgeführt hat, heißt aborted. Eine Transaktion heißt uncommitted wenn sie aktiv oder aborted ist. Eine Abort Operation kann durch die Transaktion ausgeführt werden, oder durch die Datenbank verursacht werden (Systemversagen etc.).

14 Transaktionen und Datenintegrität 14 Transfer Konto #1 Konto #2 belastet Versagen Interner Zustand von Transfer ist verloren. Recover DBS: T bekommt Abort Der Abort wird als Operation der Transaktion betrachtet, auch wenn tatsächlich die Datenbank den Abort ausgelöst hat.

15 Transaktionen und Datenintegrität 15 Wenn eine Transaktion aborted wird, muß die Datenbank alle Auswirkungen der Transaktion verwerfen. Es wird die Fähigkeit benötigt, einen Punkt in der Zeit festzulegen, nach dem die Datenbank garantiert, daß die Transaktion nicht aborted wird und alle ihre Auswirkungen permanent werden.

16 Transaktionen und Datenintegrität 16 Beispiel: Bankautomat Aus Sicht des Benutzers: BA DM Joe T(Einzahlung, Joe skonto, DM) Konto (Joe) Der Benutzer will den Bankautomaten nicht verlassen, bevor er sicher ist, daß die Einzahlung nicht aborted wird.

17 Transaktionen und Datenintegrität 17 Aus Sicht der Bank: BA DM Joe T(Auszahlung, Joe skonto, DM) Konto (Joe) Bei der Verarbeitung einer Auszahlung soll der Bankautomat kein Geld ausgeben, bevor sichergestellt ist, daß die Abbuchungs-Transaktion nicht aborted wird.

18 Transaktionen und Datenintegrität 18 Commit Operation: Die Ausführung einer Commit Operation drückt aus, daß eine Transaktion "normal" beendet wurde und alle Auswirkungen permanent gemacht werden sollten. Die Ausführung eines Commit ist eine Garantie durch das DBS, daß es die Transaktion nicht aborten wird und alle Auswirkungen der Transaktion zukünftige Fehler des Systems überstehen.

19 Transaktionen und Datenintegrität 19 T Start output Commit DBS: Abort T Benutzer: Vertraue der Ausgabe erst, wenn die Datenbank mitteilt, daß T committed hat.

20 Transaktionen und Datenintegrität 20 Recoverability Das Recovery System soll die Datenbank in einen Zustand bringen, in dem die Datenbank sich verhält, als ob sie alle Auswirkungen von committed Transaktionen enthält und keine der Auswirkungen von uncommitted Transaktionen. Abort T Das DBS muß alle Auswirkungen von T zurücksetzen: Auswirkungen auf Daten ( Write(x) ) Auswirkungen auf andere Transaktionen ( T : Read(x) )

21 Transaktionen und Datenintegrität 21 Beispiel: Initiale Wert von x und y sind "1" Zwei Transaktionen T 1 und T 2 Write 1 (x,2); Read 2 (x); Write 2 (y,3) Annahme: T 1 aborted. Das DBS verwirft die Operation Write 1 (x,2) und setzt x damit auf den ursprünglichen Wert 1. Da aber T 2 den Wert von x gelesen hat der durch T 1 geschrieben wurde, muß T 2 ebenfalls zurückgesetzt werden (Cascading Abort), der Wert von y wird deshalb ebenfalls auf 1 zurückgesetzt.

22 Transaktionen und Datenintegrität 22 Recoverability Recoverabilty sichert zu, daß das abbrechen (aborting) einer Transaktion nicht zu einer veränderten Semantik bei committed Transaktionen führt. Beispiel: x = y = 1 T 1 Write(x,2) T 2 Read(x) /* T 2 Reads from T 1 */ T 2 Write(y,3) T 2 Commit Das Commit von T 2 folgt nicht dem Commit von T 1 Non Recoverable Execution!

23 Transaktionen und Datenintegrität 23 Eine Transaktion T j liest von (reads from) einer Transaktion T i, wenn: 1. T j liest x nachdem T i auf x geschrieben hat; 2. T i bricht nicht ab bevor T j x liest; 3. Jede Transaktion (sofern vorhanden) die x schreibt, nachdem T i x geschrieben hat und bevor T j x liest, bricht ab bevor T j x liest. Eine Ausführung ist Recoverable, wenn für jede Transaktion T die ein Commit ausführt, T s Commit dem Commit jeder anderen Transaktion folgt, von der T liest.

24 Transaktionen und Datenintegrität 24 T kann nicht Committen, bevor alle Transaktion, von denen T liest, garantiert nicht abbrechen (also committed sind). recoverble Ausführung T 1 Write(x,2) T 2 Read(x) T 2 Write(y,3) T 2 Commit Das DBS muß das Commit von T 2 verzögern, dann kann T 2 abbrechen, wenn T 1 abbricht. Verzögern eines Commit ist eine Methode, um sicherzustellen, daß Ausführungen recoverable sind.

25 Transaktionen und Datenintegrität 25 Terminal I/O Input und Output Operationen sind eine andere Methode mit der Transaktionen indirekt miteinander kommunizieren können. Beispiel: T 1 output(x) input(x) T 2 commit T 1 :Abort T 2 müßte abbrechen Aber: Das DBS weiß nichts über diesen Zusammenhang!

26 Transaktionen und Datenintegrität 26 Es handelt sich um ein Benutzerproblem! T output Nicht vertrauen! T commit output vertrauen Das DBS kann T s Ausgabe verzögern bis T committed. normalerweise O.K., aber Funktioniert nicht immer. T : : output input : : T commit

27 Transaktionen und Datenintegrität 27 Vermeidung von Cascading Aborts x = y = 1 T1: Write(x,2) T2: Read(x) T2: Write(y,3) T1: Abort T2 muß ebenfalls abgebrochen werden! Kaskadierter Abbruch: (cascaded abort) T1 abort T2 abort Nicht sehr schön, weil: schwerwiegend unkontrolliert! DBS sind designed um kaskadierte Abbrüche zu vermeiden

28 Transaktionen und Datenintegrität 28 Ein DBS vermeidet kaskadierte Abbrüche, indem es sicherstellt, daß jede Transaktion nur Werte liest die von bereits committed Transaktionen geschrieben wurden. Das DBS verzögert jedes Read(x), bis alle Transaktionen die vorher ein Write(x,val) ausgeführt haben aborted oder comitted sind.

29 Transaktionen und Datenintegrität 29 Strikte Ausführung Aus einer praktischen Sicht heraus ist das Vermeiden von kaskadierten Abbrüchen nicht immer Ausreichend. Beispiel: x = y = 1 T1: Write(x,1) T1: Write(y,3) T2: Write(y,1) T1: Commit T2: Read(x) T2: Abort T2 muß zurückgesetzt werden kein kaskadierter Abbruch Alle Operationen von T2 werden gelöscht.

30 Transaktionen und Datenintegrität 30 Ergebnis: T1: Write(x,1) T1: Write(y,3) T1: Commit y = 3!! Before Image von T2: Write(y,1)! Das DBS implementiert Aborts durch Wiederherstellung der Before Images aller Writes einer Transaktion. Dies ist allerdings nicht immer korrekt! :

31 Transaktionen und Datenintegrität 31 Beispiel: x = 1 T1: Write(x,2) T2: Write(x,3) T1: Abort Das Before Image von T1: Write(x,2) ist 1 Der Wert von x sollte aber auf 3 gesetzt werden! x = 1 T1: Write(x,2) T2: Write(x,3) T1: Abort T2: Abort Das Before Image von T2: Write(x,3) ist 2 Der Wert von x sollte aber auf 1 gesetzt werden!

32 Transaktionen und Datenintegrität 32 Diskrepanzen zwischen Den Werten die (zurück-) gesetzt werden sollen, und den Before Images der Writes Die Ausführung eines Write(x,val) sollte solange verzögert werden, bis alle Transaktionen die vorher x geschrieben haben, entweder committed oder aborted sind. Strikte Ausführung (strict execution)

33 Transaktionen und Datenintegrität 33 Serialisierbarkeit (Serializability) Wenn zwei (oder mehr) Transaktionen gleichzeitig (concurrent) ausgeführt werden, bedeutet dies, daß ihre Datenbankoperationen abwechselnd (interleaved) durchgeführt werden. Dieses Mischen von Operationen verschiedener Transaktionen kann dazu führen, daß sich die Transaktionen gegenseitig beeinflussen. Dies kann selbst dann geschehen, wenn die Transaktionen selbst korrekt sind und kein Systemversagen auftritt.

34 Transaktionen und Datenintegrität 34 Beispiel: Procedure Deposit begin Start; input(account#, amount); temp := Read(Accounts[accoount#]); temp := temp + amount; Write(Accounts[account#],temp); Commit end Annahme: Konto 13 hat 1000$ Kunde 1 zahlt 100$ ein. Kunde 2 zahlt $ ein Beide Kunden rufen das Programm Deposit auf.

35 Transaktionen und Datenintegrität 35 Die gleichzeitige Ausführung des Programms Deposit führt zu einer Folge von Reads und Writes auf der Datenbank: Read 1 (Accounts[13]) Read 2 (Accounts[13]) Write 2 (Accounts[13], ) Commit 2 Write 1 (Accounts[13],1100) Commit 1 Als Ergebnis dieser Ausführung enthält Konto 13 den Wert 1.100$! Obwohl Kunde 2 s Einzahlung erfolgreich (!) behandelt wurde, wird sie durch die Transaktion von Kunde 1 überschrieben. Dieses Lost Update Problem tritt immer dann auf, wenn zwei Transaktionen, die ein Objekt verändern wollen, das Objekt lesen, bevor eine von beiden es wieder geschrieben hat.

36 Transaktionen und Datenintegrität 36 Ein weiteres Problem: Gegeben: Procedure PrintSum begin Start; input(account1,accoount2); temp1 := Read(Accounts[account1]); output(temp1); temp2 := Read(Accounts[account2]); output(temp2); temp1 := temp1 + temp2; output(temp1); Commit; end Annahme: Konto 7 und 86 haben einen Stand von 200$. Kunde 3 führt das Programm PrintSum für die Kontos 7 und 86 aus. Kunde 4 transferiert gleichzeitig 100$ von Konto 7 zu Konto 86 (Programm Transfer)

37 Transaktionen und Datenintegrität 37 Die gleichzeitige Ausführung dieser beiden Transaktionen führt zu einer Folge von Reads und Writes auf der Datenbank: Read 4 (Accounts[7]) Write 4 (Accounts[7],100) Read 3 (Accounts[7]) Read 3 (Accounts[86]) Read 4 (Accounts[86]) Write 4 (Accounts[86],300) Commit 4 Commit 3 Das Programm Transfer beeinflußt das Programm PrintSum in diesem Fall so, daß PrintSum 300$ ausgibt, was aber nicht die korrekte Summe der beiden Konten ist. Die Datenbank befindet sich trotz dieses Fehlers in einem konsistenten Zustand. Dieses Problem wird Inconsistent Retrieval genannt.

38 Transaktionen und Datenintegrität 38 Serielle Ausführungen Die besprochenen Fehlersituationen treten durch die abwechselnde Ausführung von Operationen verschiedener Transaktionen auf. Der Benutzer erwartet das seine Transaktion nicht beeinflußt wird und so abläuft, als ob sie alleine ausgeführt wird. Der korrekte Ablauf zweier Transaktionen ist, wenn die beiden Transaktionen unabhängig voneinander und seriell hintereinander ausgeführt werden.

39 Transaktionen und Datenintegrität 39 Serialisierbare Ausführungen Eine Ausführung (Schedule, Execution) wird als serialisierbar bezeichnet, wenn es eine äquivalente serielle Ausführung gibt. Zwei Ausführungen sind äquivalent, wenn die Auswirkungen auf die Datenbank gleich sind. Die im Beispiel für Inconstant Retrieval angegebene Ausführung ist also nicht serialisierbar, da das Ergebnis nicht mit dem einer seriellen Ausführung übereinstimmt.

40 Transaktionen und Datenintegrität 40 Beispiel: (serialisierbare Ausführung) Read 4 (Accounts[7]) Write 4 (Accounts[7],100) Read 3 (Accounts[7]) Read 4 (Accounts[86]) Write 4 (Accounts[86],300) Commit 4 Read 3 (Accounts[86]) Commit 3 Diese Ausführung hat das gleiche Ergebnis, wie die serielle Ausführung von Transfer und PrintSum. Es gibt also serielle, serialisierbare und nichtserialisierbare Ausführungen von Transaktionen.

41 Transaktionen und Datenintegrität 41 Beispiel: T1: READ A; A:=A-10; WRITE A; READ B; B:= B+10; WRITE B; T2: READ B; B:=B-20; WRITE B; READ C; C:=C+20; WRITE C; T1 T2 T1 T2 READ A READ A A:=A-10 READ B WRITE A A:=A-10 READ B B:=B-20 B:= B+10 WRITE A WRITE B WRITE B READ B READ B B:=B-20 READ C WRITE B B:= B+10 READ C C:=C+20 C:=C+20 WRITE B WRITE C WRITE C a) serial b) serializable T1 READ A A:=A-10 WRITE A READ B T2 READ B B:=B-20 WRITE B B:= B+10 READ C WRITE B C:=C+20 WRITE C c) non serializable

42 Transaktionen und Datenintegrität 42 Sperren (Locks) Wir betrachten die Datenbank als eine Menge von Objekten, die Teile der Datenbank darstellen, die gesperrt (locked) werden können. Durch das Sperren eines Objektes kann eine Transaktion verhindern, daß andere Transaktionen auf dieses Objekt zugreifen. Objekte können hierbei Attribute, Tupel, Pages, Mengen von Tupeln, ganze Relationen etc. sein. Welche Granularität für den Lock gewählt werden sollte kann von Anwendung zu Anwendung verschieden sein.

43 Transaktionen und Datenintegrität 43 Wir nehmen an, daß wenn ein Teil eines Objektes verändert wird, das ganze Objekt als verändert gilt und einen Wert bekommt, der von anderen Werten unterscheidbar ist. Generell ist es schwierig, zu testen, ob zwei Ausführungen das gleiche Ergebnis für alle möglichen Startwerte haben, wenn willkürliche Operationen erlaubt sind. Praktische Vereinfachung: Werte können nicht gleich sein, wenn sie nicht durch die selbe Sequenz von Operationen erzeugt wurden.

44 Transaktionen und Datenintegrität 44 Beispiel: (A + 10) - 20 hat nicht den selben Wert wie (A + 20) - 30 Dies hat Auswirkungen auf die Äquivalenz von Ausführungen und damit auf unsere Definition der Serialisierbarkeit: Wir nennen eine Ausführung nicht-serialisierbar, obwohl sie serialisierbar ist, aber Wir nennen niemals eine Ausführung serialisierbar, wenn sie es nicht ist.

45 Transaktionen und Datenintegrität 45 Betrachten wir nochmals folgendes Beispiel: Zwei Transaktionen T1 und T2 führen das Programm P aus: P : READ A; A := A + 1; WRITE A Dies führt zu folgendem Schedule:

46 Transaktionen und Datenintegrität 46 Eine Lösung für dieses Problem ist es, einen Lock auf A zu setzen, dafür gelten folgende Regeln: Bevor eine Transaktion auf ein Objekt zugreift, muß sie das Objekt sperren (lock). Erst wenn eine Transaktion mit der Bearbeitung eines Objektes fertig ist, kann sie es wieder entsperren (unlock). In der Zwischenzeit kann keine andere Transaktion auf dieses Objekt zugreifen. Versucht eine weitere Transaktion, einen Lock auf das selbe Objekt zu setzen, wird dies verzögert, bis die erste Transaktion das Objekt wieder freigibt. Eine Ausführung (Schedule) die obigen Bedingen über Locks genügt heißt legal.

47 Transaktionen und Datenintegrität 47 Schreiben wir nun das Programm P so, daß es das benutzte Objekt A sperrt: P : LOCK A; READ A; A := A + 1; WRITE A; UNLOCK A Seien wieder T1 und T2 Ausführungen von P. Wenn T1 beginnt, versucht sie A zu sperren, sofern keine andere Transaktion A gesperrt hat, wird das System diese Sperrung zulassen. Jetzt kann nur noch T1 auf A zugreifen. Wenn T2 startet, bevor T1 beendet ist, versucht sie die Anweisung LOCK A auszuführen, dies wird dann verzögert, bis T1 A entsperrt. Die Transaktionen laufen in diesem Fall seriell nacheinander ab!

48 Transaktionen und Datenintegrität 48 Protokolle und Scheduler Frage: Wie können nicht-serialisierbare Ausführungen vermieden werden? Scheduler Protokolle (die Serialisierbarkeit garantieren)

49 Transaktionen und Datenintegrität 49 Einfaches Modell für Transaktionen Jede Transaktion T j ist eine Sequenz von LOCK und UNLOCK Operationen auf Objekten der Datenbank. T j LOCK A : : /* T j hält einen Lock auf A */ UNLOCK A

50 Transaktionen und Datenintegrität 50 Annahmen: 1. T j sperrt A nicht, wenn sie bereits einen Lock auf A hält. 2. T j entsperrt A nicht, wenn sie keinen Lock auf A hält. 3. Immer wenn eine Transaktion einen Lock auf ein Objekt A hält, wird sie den Wert von A verändern, und der Wert, den A nach dem Unlock hat, ist eindeutig und unterscheidbar. A = V 1 A = V 2 LOCK A UNLOCK A LOCK A UNLOCK A A = X A = X

51 Transaktionen und Datenintegrität 51 Formelles Modell für das Verhalten von T j Für alle Sequenzen von LOCK und UNLOCK assoziiere eine Funktion f(). Wenn A 0 der Initialwert von A ist, dann ist f 1 f 2 f n ( A 0 ) der Wert, den A annehmen wird. Unterscheidbare Werte sind hierbei nicht identisch. Werte werden als uninterpretierte Formeln gesehen. Beispiel: (A+10)-20 ist nicht identisch zu (A+20)-30 Es wird nicht überprüft ob f 2 f 3 = f 3 f 2

52 Transaktionen und Datenintegrität 52 Beispiel: Drei Transaktionen T1 T2 T3 T1: LOCK A LOCK B UNLOCK A UNLOCK B T2: LOCK B LOCK C UNLOCK B LOCK A UNLOCK C UNLOCK A T3: LOCK A LOCK C UNLOCK C UNLOCK A

53 Transaktionen und Datenintegrität 53

54 Transaktionen und Datenintegrität 54 Diese Ausführung ist nicht-serialisierbar! Beweis: Finden eines äquivalenten seriellen Schedules. Wenn T1 vor T2 ist, dann ist der Wert für B = f 3 ( f 2 ( B 0 ) ) A = f 6 ( f 5 ( f 1 ( A 0 ) ) ) C = f 7 ( f 4 ( C 0 ) ) Wenn T 2 vor T1 ist, dann gilt für A T2 T1 T3: A = f 6 ( f 1 ( f 5 ( A 0 ) ) ) T2 T3 T1: A = f 1 ( f 6 ( f 5 ( A 0 ) ) ) T3 T2 T1: A = f 1 ( f 5 ( f 6 ( A 0 ) ) ) T2 kann in einem seriellen Schedule werde vor noch nach T1 kommen, also gibt es kein serielles Schedule.

55 Transaktionen und Datenintegrität 55 Ein Test für Serialisierbarkeit Der obige Beweis ist der Schlüssel zu einem Test für Serialisierbarkeit. Idee: Untersuche, in welcher Reihenfolge die verschiedenen Transaktionen eines Schedules ein gegebenes Objekt sperren. Diese Reihenfolge muß identisch sein zu der einer hypothetischen seriellen Ausführung. Wenn die, durch zwei verschieden Objekte induzierten Ordnungen zwei Transaktionen in verschiedener Reihenfolge auflisten, ist dies ein Widerspruch! Dann kann es kein äquivalentes serielles Schedule geben.

56 Transaktionen und Datenintegrität 56 Dieser Test kann in einem Algorithmus für gerichtete Graphen formuliert werden: Algorithmus: Test für Serialisierbarkeit eines Schedules. Eingabe: Ein Schedule für eine Menge von Transaktionen T 1... T k. Ausgabe: Aussage über die Serialisierbarkeit, und ein äquivalentes serielles Schedule. Methode: Aufbau eines gerichteten Graphen G (der Präzedenzgraph), dessen Knoten mit den Transaktionen korrespondieren. Die Kanten zwischen den Knoten werden wie folgt aufgebaut:

57 Transaktionen und Datenintegrität 57 Sei S die Folge a 1, a 2,, a n von Operationen der Form T j : LOCK A m oder T j : UNLOCK A m (also das Schedule) Wenn a j von der Form T j : UNLOCK A m ist, dann finde die nächste Operation T s : LOCK A m. Wenn eine solche existiert, füge eine Kante von T j nach T s in den Graphen ein. Die Bedeutung einer solchen Kante ist, daß in einem äquivalenten seriellen Schedule T j vor T s kommen muß. Falls der Präzedenzgraph Zykel hat, ist das Schedule nicht serialisierbar. Falls der Präzedenzgraph keine Zykel hat, ist das Schedule serialisierbar und ein äquivalentes serielles Schedule kann aus dem Graphen durch topologisches Sortieren gewonnen werden.

58 Transaktionen und Datenintegrität 58 Zurück zu unserem Beispiel: Aufbau des Graphen: Schritt(4): T2: UNLOCK B es folgt T1: LOCK B Schritt(6): T1: UNLOCK A es folgt T2: LOCK A Schritt(8): T2: UNLOCK C es folgt T3:LOCK C Der Graph:

59 Transaktionen und Datenintegrität 59 Beispiel: (ein serialisierbares Schedule) LOCK A UNLOCK A time LOCK A UNLOCK A LOCK B UNLOCK B LOCK B UNLOCK B T 1 T 2 T 3 T 1 T 2 T 3

60 Transaktionen und Datenintegrität 60 Ein Protokoll, daß Serialisierbarkeit garantiert Ein Test aus Serialisierbarkeit ist in der Praxis nicht sehr nützlich, besser ist ein Verfahren, das gerantiert, daß alle Schedules serialisierbar sind: Zwei-Phasen-Sperrprotokoll (Two phase locking): Das Protokoll ist so, daß verlangt wird, daß in einer Transaktion alle Locks vor allen Unlocks stattfinden. Eine Transaktion die diesem Protokoll folgt, wird zwei-phasig genannt. Die erste Phase ist die Lock- Phase und erst wenn diese beendet ist, kann die zweite Phase, die Unlock-Phase beginnen. Wenn in einem Schedule alle Transaktionen zweiphasig sind, ist es serialisierbar.

61 Transaktionen und Datenintegrität 61 Es gilt also: Eine Transaktion T=(a i ) i=1,,n ist eine 2-Phasen- Transaktion, wenn für ein j < n gilt: 1. i < j a i <> UNLOCK 2. i = j a i = UNLOCK 3. i > j a i <> LOCK Die Schritte 1,, j-1 sind die Lock-Phase und die Schritte j,, n sind die Unlock-Phase der Transaktion. Der Zeitpunkt des Belegens der letzten Sperre wird als locked point bezeichnet.

62 Transaktionen und Datenintegrität 62 Diagramm: 2-Phasen-Sperrprotokoll Sperren locked point Lock-Phase Unlock- Phase Zeit

63 Transaktionen und Datenintegrität 63 Hinreichende Bedingung für Serialisierbarkeit: Wenn alle Transaktionen einer Transaktionsmenge T wohlgeformt und 2-Phasen-Transaktionen sind, dann ist jede gültige Ausführung von T serialisierbar. Die Serialisierungsreihenfolge einer solchen Ausführung entspricht der Reihenfolge der locked points der einzelnen Transaktionen aus T.

64 Transaktionen und Datenintegrität 64 Beispiel: 2-Phasen-Sperprotokoll (A) LOCK a LOCK b LOCK c UNLOCK c UNLOCK a UNLOCK b locked point (B) LOCK a LOCK b UNLOCK a LOCK c UNLOCK c UNLOCK b nicht 2-Phasen

65 Transaktionen und Datenintegrität 65 Beispiel: T 1 : 1 LOCK A T 2 : 1 LOCK A 2 UPDATE A 2 UPDATE A 3 LOCK B 3 LOCK B 4 UNLOCK A 4 UPDATE B 5 UPDATE B 5 UPDATE A 6 UNLOCK B 6 UNLOCK A 7 UPDATE B 8 UNLOCK B The following is a legal execution I 1 of the transactions T 1 and T 2. I 1 T 1 : T 2 : 1. LOCK A 2. UPDATE A 3. LOCK B 4. UNLOCK A 5. LOCK A 6. UPDATE A 7. UPDATE B 8. UNLOCK B 9. LOCK B 10 UPDATE B 11 UPDATE A 12 UNLOCK A 13 UPDATE B 14 UNLOCK B

66 Transaktionen und Datenintegrität 66 Beispiel: (Fortsetzung) Consider also another example of a legal execution I 2 of the given transactions T 1 and T 2 : I 1 T 1 : T 2 : 1. LOCK A 2. UPDATE A 3. LOCK B 4. UPDATE B 5. UPDATE A 6. UNLOCK A 7. LOCK A 8. UPDATE A 9. UPDATE B 10 UNLOCK B 11 LOCK B 12 UNLOCK A 13 UPDATE B 14 UNLOCK B

67 Transaktionen und Datenintegrität 67 Theorem: Wenn S eine Ausführung von 2-Phasen- Transaktionen ist, dann ist S serialisierbar. Beweis: Angenommen S ist nicht serialisierbar, dann hat der Präzedenzgraph einen Zykel: T 1 T 2... T k UNLOCK LOCK UNLOCK LOCK LOCK UNLOCK Dann wäre aber: T1: UNLOCK LOCK Widerspruch!

68 Transaktionen und Datenintegrität 68 Ein anderer Weg um zu sehen, daß 2-Phasen- Transaktionen serialisierbar sein müssen: Man stelle sich vor, eine 2-Phasen-Transaktion geschieht genau zu dem Zeitpunkt an dem sie ihren letzten Lock ausführt (also am locked point). Dann ist die Ordnung, in der die Transaktionen den locked point erreichen, eine serielle Ausführung, die äquivalent zu dem gegebenen Schedule ist.

69 Transaktionen und Datenintegrität 69 T i T j T k LOCK : LOCK : : : LOCK : LOCK : : : LOCK LOCK Dann ist ein serielles Schedule gegeben: T i T k gebenem Schedule T j

70 Transaktionen und Datenintegrität 70 Wenn in einem gegebenem Schedule eine Transaktion T2 ein Objekt nach einer anderen Transaktion T1 lockt: : : T1 : LOCK A : : T2 : LOCK A : : Dann erreicht T1 den locked point mit Sicherheit vor T2.

71 Transaktionen und Datenintegrität 71 LOCK A UNLOCK A T1 Zeit LOCK A T1 T2 T2 Zeit

72 Transaktionen und Datenintegrität 72 Wenn T1 eine Transaktion ist, die nicht 2-phasig ist, dann gibt es eine andere Transaktion T2 mit der T1 in einem nicht serialisierbaren Schedule ausgeführt werden kann. Beweis: Eine solche Transaktion T1 ist generell von der Form: T1 (nicht 2-Phasen): : : UNLOCK A : : LOCK B : :

73 Transaktionen und Datenintegrität 73 Sei T2 : LOCK A LOCK B UNLOCK A UNLOCK B Dann gibt es die folgende nicht serialisierbare Ausführung: LOCK A : : UNLOCK A LOCK B UNLOCK B LOCK A LOCK B UNLOCK A UNLOCK B T 1 T 2

74 Transaktionen und Datenintegrität 74 Deadlock Dynamische Sperren von Objekten und 2-Phasen Sperrprotokolle führen zu dem Problem des Deadlocks. Deadlocks müssen entweder von vornherein vermieden oder erkannt und aufgelöst werden. Beispiel: Deadlock T1: T2: LOCK A LOCK B (LOCK B) T1 wartet auf B (LOCK A) T2 wartet auf A

75 Transaktionen und Datenintegrität 75 Ein Modell mit Read- und Write-Locks Bisheriges Modell: LOCK A CHANGE A UNLOCK A Mögliche Unterscheidung zwischen: READ und WRITE

76 Transaktionen und Datenintegrität 76 Sperrtypen Es gibt zwei elementare Typen von Sperren: Read-Locks (Shared Locks): nur zum Lesen. Write-Locks (Exclusive Locks): zum Updaten. Kompatibilität zwischen Sperren verschiedener Transaktionen. Bestehende Sperre R-LOCK W-LOCK Sperr- R-LOCK anforderung W-LOCK Verträglich, Konflikt

77 Transaktionen und Datenintegrität 77 Beide Sperren, Read-Lock und Write-Lock werden durch ein UNLOCK wieder aufgehoben. Bemerkung: Es werden weiterhin keine Write-Only-Locks behandelt. Also Transaktionen bei denen der Wert eines Objektes geschrieben wird, ohne das dieses vorher gelesen wurde. Ein Write-Lock impliziert also ein Lesen, Verändern und Schreiben eines Objektes.

78 Transaktionen und Datenintegrität 78 Annahmen: Für jede Transaktion gilt: kein Unlock, falls sie keinen R/W-Lock hält kein R-Lock, falls sie bereits einen Lock hält. kein W-Lock, falls sie bereits einen W-Lock hält. Ein Write-Lock kann auf ein Objekt gesetzt werden, aus das die Transaktion bereits einen Read-Lock hält. Äquivalenz zweier Schedules Zwei Schedules S und S sind äquivalent, wenn: S und S den selben Wert für jedes Objekt produzieren. Jeder Read-Lock der durch eine Transaktion Ti durchgeführt wird, in S und S an Zeitpunkten ausgeführt wird an denen das gesperrte Objekt den selben Wert hat.

79 Transaktionen und Datenintegrität 79 Das 2-Phasen Sperrprotokoll: Genau wie bei dem vorherigen Modell mit nur einem Sperrtypen, ist das 2-Phasen Sperrprotokoll, bei dem alle Locks allen Unlocks vorausgehen, ausreichend um Serialisierbarkeit zu garantieren. Ebenso gilt die Umkehrung, daß jede Transaktion, die nicht dem 2-Phasen Protokoll folgt, mit einer anderen Transaktion in einem nicht-serialisierbaren Schedule ausgeführt werden kann.

80 Transaktionen und Datenintegrität 80 Read-Only, Write-Only Modell Dieses Modell hat eine andere Semantik als das bisherige Read-Write-Modell. Wenn eine Transaktion ein Objekt Write-Lockt, liest sie seinen Wert nicht! Zum Lesen des Objektes muß die Transaktion explizit einen Read-Lock auf dem Objekt halten. Bei dem bisherigen Modell bezog ein Write-Lock immer die Lese-Berechtigung mit ein. Der Wert des Objektes mußte gelesen und benutzt werden.

81 Transaktionen und Datenintegrität 81 Dies führt zu einer neuen Definition der Äquivalenz zweier Schedules: Annahme: Schedule S: Wenn T2 das Objekt A liest, welches durch T1 geschrieben wurde, dann 1. ist T1 vor T2 in jedem zu S äquivalenten seriellen Schedule. 2. Wenn T3 das Objekt A schreibt, dann ist T3 entweder vor T1 oder nach T2 in einem äquivalenten seriellen Schedule. T3 T1 ; T2 nicht dazwischen

82 Transaktionen und Datenintegrität 82 Äquivalenz von Schedules (Fortsetzung) Es gibt einen Unterschied zur bisherigen Definition: Angenommen T1 hat A geschrieben und T2 hat A zu einem späteren Zeitpunkt geschrieben, dann: gilt für das Read-Write-Modell T1: UNLOCK A T2: LOCK A T2 hat den Wert von A benutzt, der durch T1 geschrieben wurde T1 ist in einem äquivalenten seriellen Schedule vor T2 und

83 Transaktionen und Datenintegrität 83 keine andere Transaktion T die A Write-Lockt kann zwischen T1 und T2 sein. Aber: Wenn T2 A geschrieben hat ohne A vorher zu lesen, dann ist der neue Wert von A unabhängig vom bisherigen Wert. Er ist nur von den Werten der Objekte abhängig, die T2 gelesen hat.

84 Transaktionen und Datenintegrität 84 Es gilt also: Wenn zwischen den Zeitpunkten an denen die Transaktionen T1 und T2 das Objekt A schreiben, keine andere Transaktion das Objekt A liest, dann: hat wird der Wert, den T1 geschrieben hat, überschrieben und hat daher keinen Effekt auf die Datenbank. (Der Wert "geht verloren"). T1 muß also in einem seriellen Schedule nicht vor T2 kommen!! T1 muß aber A zu einem Zeitpunkt schreiben, an dem sichergestellt ist, daß eine andere Transaktion T3 später ebenfalls A schreibt und dazwischen keine Transaktion den Wert von A liest.

85 Transaktionen und Datenintegrität 85 Neues Konzept für Serialisierbarkeit: Die Werte die von Transaktionen geschrieben werden sind Funktionen der Werte die gelesen wurden und verschiedene Werte die gelesen werden produzieren verschiedene Ergebnisse die geschrieben werden.

86 Transaktionen und Datenintegrität 86 Wenn, in einem Schedule S, die Transaktion T2 einen Wert von A liest, der durch T1 geschrieben wurde, dann: 1. Muss T1 vor T2 in einem zu S äquivalenten Schedule kommen. 2. Wenn T3 eine Transaktion ist, die A schreibt, dann muß sie, in jedem äquivalenten Schedule, entweder vor T1 oder nach T2 kommen.

87 Transaktionen und Datenintegrität 87 "Edge Effects" Um die Unklarheiten zu beseitigen, die auftreten, wenn Werte gelesen werden, die zuvor nicht geschrieben wurden oder Werte geschrieben werden, die nicht wieder gelesen werden, wird die Existenz von zwei Transaktionen postuliert: Eine initiale Transaktion T 0, die jedes Objekt schreibt aber keines liest, und eine finale Transaktion T f, die jedes Objekt liest, aber keines schreibt.

88 Transaktionen und Datenintegrität 88 Nutzlose (useless) Transaktionen Eine Transaktion ist dann nutzlos, wenn ihre Ausführung keine Auswirkungen auf die Ausführung der finalen Transaktion T f hat. T1 und T2 in der Definition für Serialisierbarkeit dürfen keine nutzlosen Transaktionen sein.

89 Transaktionen und Datenintegrität 89 Testen auf nutzlose Transaktionen: Gegeben sei ein Schedule S, welche Transaktionen T i sind nutzlos? Lösung: Bilde einen Graph G, bei dem die Knoten die Transaktionen sind, einschliesslich der finalen Transaktion T f. Wenn T i eine Wert schreibt, der von T j gelesen wird, dann gibt es eine Kante von T i nach T j. T i T j T k T f Eine Transaktion ist dann nutzlos, wenn es keinen Pfad von ihr zu T f gibt.

90 Transaktionen und Datenintegrität 90 Formales Modell RLOCK, WLOCK, UNLOCK Serialisierbarkeits-Test: Ein einfacher Präzedenzgraph ist nicht mehr ausreichend. Benutzen eines Polygraph: eine Menge aus Knoten, Kanten und Paaren alternativer Kanten. Azyklischer Polygraph: Wenn es eine Folge von "Entscheidungen" zwischen alternativen Kanten gibt, die zu einem azyklischen Graphen führt. Testen eines Polygraphen auf azyklische Graphen ist ein NP-vollständiges Problem.

91 Transaktionen und Datenintegrität 91 2-Phasen Sperrprotokoll Genau wie beim Read-Write-Modell gilt, wenn Transaktionen 2-phasig sind, ist die Serialisierbarkeit garantiert.

92 Transaktionen und Datenintegrität 92 Nebenläufigkeit bei hierarchisch strukturierten Objekten Es gibt viele Gelegenheiten, bei denen eine Menge von Objekten natürlicherweise als ein Baum oder Wald angesehen werden können. z.b. 1. Die Objekte sind logische Records in einer Datenbank die nach dem hierarchischen Prinzip Modell organisiert ist: Filiale Person Konto 2. Die Objekte sind die Knoten eines B*-Baumes.

93 Transaktionen und Datenintegrität Die Objekte von verschiedener Größe sind definiert als kleinere Objekte in größeren: I. Gesamte Datenbank. II. Jede Relation. III. Jeder Block einer Datei, die mit einer Relation korreliert. IV. Jedes Tupel.

94 Transaktionen und Datenintegrität 94 Zwei Lock-Prinzipien: 1. Ein Lock auf einem Objekt impliziert einen Lock auf allen nachfolgenden Objekten. A B C d D E F LOCK A LOCK d 2. Locke ein Objekt, ohne irgendeine Auswirkung auf die nachfolgenden Objekte.

95 Transaktionen und Datenintegrität 95 Baumprotokoll Eine Transaktion erfüllt das Baumprotokoll, wenn gilt: 1. Ein Objekt A wird nur dann von T gesperrt, wenn T bereits einen Lock auf den Vater von T hält. Dies gilt nicht für das erste Objekt im Baum, das von T gesperrt wird. 2. Kein Objekt wird von einer Transaktion mehr als einmal gesperrt.

96 Transaktionen und Datenintegrität 96 Beispiel: A A B C D A E F G T 1 : T 2 : T 3 : 1. LOCK A 2. LOCK B 3. LOCK D 4. UNLOCK B 5. LOCK B 6. LOCK C 7. LOCK E 8. UNLOCK D 9. LOCK F 10 UNLOCK A 11 LOCK G 12 UNLOCK C 13 UNLOCK E 14 LOCK E 15 UNLOCK F 16 UNLOCK B 17 UNLOCK G 18 UNLOCK E

97 Transaktionen und Datenintegrität 97 Hinreichende Bedingung für Serialisierbarkeit Wenn alle Transaktionen eines legalen Schedules S dem Baumprotokoll folgen, dann ist S serialisierbar.

98 Transaktionen und Datenintegrität 98 Sperren auf Subtrees Einfaches Modell: Sperre alle Nachfolger des Objektes, das gesperrt werden soll. A B C LOCK A LOCK A, LOCK B, LOCK C Wahlloses Sperren von Objekten kann zu illegalen Schedules führen. A T1: LOCK E T2: LOCK B D B F E C G zur selben Zeit! Konflikt Notwendigkeit für ein Protokoll!

99 Transaktionen und Datenintegrität 99 Das hierarchische Sperr-Protokoll Informell: Eine Transaktion kann ein Objekt A nicht sperren, solange sie nicht eine Warnung (Warning) auf alle Vorfahren des Objektes setzt. Eine Warnung auf A verhindert, das eine andere Transaktion das Objekt A sperrt. verhindert keine weitere Warnung auf das Objekt A. verhindert nicht das Sperren von Nachfahren des Objektes A, auf denen keine Warnung liegt.

100 Transaktionen und Datenintegrität 100 Modell für Transaktionen (System R, IBM, San Jose) Ti: LOCK (Exclusive, E-Sperre) Sperrt ein Objekt und alle seine Nachfahren. Zwei Transaktionen können nicht gleichzeitig ein Lock auf ein Objekt halten. WARN (Intention, I-Sperre) Keine Transaktion kann ein Objekt sperren, auf dem eine Warnung liegt. UNLOCK Entfernt ein WARN oder ein LOCK.

101 Transaktionen und Datenintegrität 101 Eine Transaktion gehorcht dem Warnungs- oder hierarchischen Sperrprotokoll auf einer Objekt- Hierarchie, wenn sie 1. damit beginnt, eine Warnung oder Lock auf die Wurzel zu setzen. 2. keine Sperre oder Warnung auf ein Objekt setzt, solange sie keine Warnung auf den Vorfahren (Parent) hält. 3. keine Warnung oder Sperrung von einem Objekt entfernt, solange sie Warnungen oder Sperren auf Nachfahren (Children) des Objektes hält. 4. sie dem 2-Phasen Protokoll folgt.

102 Transaktionen und Datenintegrität 102 Beispiel: A B C D E F G Annahme: Drei Transaktionen die verschiedene Objekte der Hierarchie ändern: T1: ändert Objekt D T2: ändert Objekt C T3: ändert Objekt B und Objekt F Ein legales Schedule für die Ausführung dieser drei Transaktionen wäre z.b. das Folgende:

103 Transaktionen und Datenintegrität 103 A B C D E F G T1 T2 T3 1 WARN A 2 WARN A 3 WARN A 4 WARN B 5 LOCK C 6 LOCK D 7 UNLOCK C 8 UNLOCK D 9 UNLOCK A 10 UNLOCK B 11 LOCK B 12 WARN C 13 LOCK F 14 UNLOCK A 15 UNLOCK B 16 UNLOCK F 17 UNLOCK C 18 UNLOCK A

104 Transaktionen und Datenintegrität 104 Beispiel: (Fortsetzung) In Schritt 4 setzt T1 eine Warnung auf B, T3 kann also B nicht sperren, bis T1 in Schritt 10 B entsperrt. In den Schritten 1,2,3 wird A von allen Transaktionen mit einer Warnung belegt, dies ist legal. Die Sperrung von C durch T2 in Schritt 5 sperrt implizit die Objekte C,F und G. Die Annahme ist, das diese Objekte all von T2 geändert werden, bevor die Sperre in Schritt 7 wieder entfernt wird.

105 Transaktionen und Datenintegrität 105 Theorem: Ausführungen von Transaktionen die dem hierarchischen Sperrprotokoll gehorchen sind serialisierbar.

106 Transaktionen und Datenintegrität 106 OPTIMISTIC CONCURRENCY CONTROL Synchronisierung von Transaktionen ohne Sperren. Annahme: Es gibt eine Methode, zu erkennen, wann eine Transaktion die serielle Ordnung verletzt. Abbruch einer Transaktion und Neustart. Dieser Ansatz ist sehr effizient, wenn die Wahrscheinlichkeit von Konflikten zwischen Transaktionen gering ist. Granularität der Objekte (Je kleiner die Objekte sind, auf die zugegriffen wird, desto geringer ist die Wahrscheinlichkeit eines Konfliktes)

107 Transaktionen und Datenintegrität 107 Trade-Off zwischen Zeit, die auf Sperren gewartet wird und Zeit, die benötigt wird, eine Transaktion erneut zu starten. Wie kann man erkennen, daß eine Transaktion T die serielle Ordnung verletzt? Wie kann man vermeiden, daß in der Datenbank Werte stehenbleiben, die von einer Transaktion T geschrieben wurden, die danach aborted wurde? Wie kann ein Live-Lock vermieden werden (Wenn beispielsweise T immer wieder abbricht)?

108 Transaktionen und Datenintegrität 108 Lösungen Serielle Ordnung Zeitstempel (Timestamps) beschädigte Werte Commitment Live-Lock Restart

109 Transaktionen und Datenintegrität 109 Betrachten wir das erste Beispiel nicht serialisierbaren Verhaltens: T1: READ A T2: READ A T1: A := A + 1 T2: A := A + 1 T1: WRITE A T2: WRITE A Wir benötigen eine Methode, zu erkennen wann eine Transaktion die serielle Ordnung verletzt, um dann die Transaktion neu zu starten. A T 1 READ A A:=A+1 WRITE A T 2 READ A A:=A+1 WRITE A A(T 1 ) A(T 2 )

110 Transaktionen und Datenintegrität 110 Zeitstempelverfahren (Timestamping) Um die serielle Ordnung aufrecht zu erhalten und Verletzungen der seriellen Ordnung erkennen zu können, generiert das System Zeitstempel. Eine Zahl, die bei jedem "Tick" der Systemuhr generiert wird (z.b. jede Mikrosekunde). Ein 32-bit Wort reicht, um die Anzahl von "Ticks" eines ganzen Jahrhunderts aufzunehmen. Eine solche Zahl wird jeder Transaktion so zugeordnet, daß keine zwei Transaktionen den selben Zeitstempel haben. (Beginn der Transaktion)

111 Transaktionen und Datenintegrität 111 Mit jedem Objekt der Datenbank werden zwei Zeitstempel gespeichert: t r = read-time (Lese-Zeitstempel) Der Zeitstempel der Transaktion mit dem höchsten (d.h. spätesten) Zeitstempel von allen Transaktionen, die das Objekt gelesen haben. t w = write-time (Schreib-Zeitstempel) Der Zeitstempel der Transaktion mit dem höchsten (d.h. spätesten) Zeitstempel von allen Transaktionen, die das Objekt geschrieben haben. Wie kann man Transaktionen nun dazu bringen, sich so zu verhalten, als ob sie seriell abgelaufen wären?

112 Transaktionen und Datenintegrität 112 Korrektheit: Transaktionen sollten sich so verhalten, als ob die Ordnung ihrer Zeitstempel die serielle Ordnung gewesen wäre.

113 Transaktionen und Datenintegrität 113 Durch folgende Bedingungen wird die Konsistenz der Datenbank sichergestellt: 1. Eine Transaktion T darf ein Objekt nicht lesen, wenn der Wert des Objektes von einer Transaktion geschrieben wurde, die (in der seriellen Ordnung) nach ihr stattfindet: Eine Transaktion T mit Zeitstempel t 1 darf ein Objekt mit Schreib-Zeitstempel t w nicht lesen, wenn t w > t 1 gilt. T muß dann abgebrochen (roll-back) und neu gestartet (restart) werden.

114 Transaktionen und Datenintegrität Eine Transaktion T darf ein Objekt nicht schreiben, wenn der alte Wert des Objektes bereits von einer Transaktion gelesen wurde, die (in der seriellen Ordnung) nach ihr stattfindet: Eine Transaktion T mit Zeitstempel t 1 darf ein Objekt mit Lese-Zeitstempel t r nicht schreiben, wenn t r > t 1 gilt. T muß dann abgebrochen und neu gestartet werden

115 Transaktionen und Datenintegrität 115 Zwei Transaktionen können das gleiche Objekt zu verschiedenen Zeiten lesen. T mit Zeitstempel t 1 kann ein Objekt mit Zeitstempel t r lesen, selbst wenn t r > t 1 ist. Eine Transaktion T mit Zeitstempel t 1 muss nicht abbrechen, wenn sie versucht ein Objekt mit Zeitstempel t w zu schreiben, selbst wenn t w > t 1 ist. Der Wert wird in diesem Fall einfach nicht geschrieben. Begründung: In der Seriellen Reihenfolge basierend auf den Zeitstempeln, hätte erst die Transaktion mit Zeitstempel t 1 und anschließend die Transaktion mit Zeitstempel t w das Objekt geschrieben. Zu beachten ist, dass zwischen t 1 und t w das Objekt nicht gelesen werden darf, ansonsten wäre t r des Objektes größer als t 1 und die Transaktion T müsste nach Regel 2 abgebrochen

116 Transaktionen und Datenintegrität 116 werden. Beispiel: A tr=0 tr=150 tr=150 tr=150 tr=150 tr=150 tw=0 tw=0 tw=0 tw=0 tw=160 tw=160 T 1 READ A A:=A+1 WRITE A t 1 =150 T 2 A:=12 WRITE A t 2 =160 Eine abgebrochene Transaktion erhält beim Restart einen neuen Zeitstempel. Die Serialisierungsreihenfolge der Transaktionen entspricht der Reihenfolge der Zeitstempel, also der Startzeitpunkte.

117 Transaktionen und Datenintegrität 117 Algorithmus Die Transaktion T mit Zeitstempel t will eine Operation X auf dem Objekt A mit den Zeitstempeln t r und t w ausführen. 1. if X = READ and t >= t w then READ A if t > t r then t r := t 2. if X = WRITE and t >= t r and t >= t w then WRITE A t w := t 3. if X = WRITE and t r <= t < t w then { do nothing } 4. if ( X = READ and t < t w ) or (X = WRITE and t < t r ) then abort(t)

118 Transaktionen und Datenintegrität 118 Beispiel: A tr=0 tr=150 tr=160 tr=160 tr=160 tr=160 tr=160 tw=0 tw=0 tw=0 tw=0 tw=0 tw=160 tw=160 T 1 READ A A:=A+1 WRITE A t 1 =150 T 2 READ A A:=A+1 WRITE A t 2 =160 A(T 1 ) A(T 2 ) Schritt 1: t 1 > t r T 1 liest A; t r := 150 Schritt 2: t 2 > t r T 2 liest A; t r := 160 Schritt 3: keine Datenbankoperation Schritt 4: keine Datenbankoperation Schritt 5: t 2 t w und t 2 t r T 2 schreibt A; t w := 160 Schritt 6: t 1 < t r T 1 wird abgebrochen!

119 Transaktionen und Datenintegrität 119 Beispiel: T1 T2 T3 A B C RT = 0 RT = 0 RT = 0 WT = 0 WT = 0 WT = 0 (1 READ B RT = 200 (2 READ A RT = 150 (3 READ C RT = 175 (4 WRITE B WT = (5 WRITE A WT = (6 WRITE C (7 WRITE A Fig Optimistically executing transactions. Schritt 6: Das Objekt C soll von T 2 geschrieben werden; der Zeitstempel von T 2 ist 150, t r von C ist aber 175; T 2 muss also abgebrochen werden. Schritt 7: T 3 versucht, Objekt A zu schreiben; der Zeitstempel von T 3 ist mit 175 kleiner als der Schreib-Zeitstempel von A; T 3 muß nicht abgebrochen werden, aber der Wert den T 3 schreiben wollte, wird nicht in der Datenbank eingetragen.

120 Transaktionen und Datenintegrität 120 Commitment Es muß in Betracht gezogen werden, daß eine Transaktion, die abgebrochen wird, einen Wert in die Datenbank geschrieben haben kann. Lösung: WRITE verändert keine Werte in der Datenbank. Der Wert wird in ein "Journal" geschrieben (das Logfile). t w wird nur vorläufig verändert. der alte und der neue Wert von t w werden in das Journal aufgenommen. Nachdem T alle WRITES beendet hat, führt sie ein COMMIT aus. alle geschriebenen Werte werden jetzt permanent in der Datenbank gespeichert.

121 Transaktionen und Datenintegrität 121 In der Zeit zwischen dem WRITE und dem COMMIT darf keine Transaktion den neuen Wert des Objektes lesen, da er nur vorläufig ist. Eine Transaktion die diesen Wert gelesen hat, müßte sonst ebenfalls abgebrochen werden, wenn T abgebrochen wird. WRITE A COMMIT vorläufig Es ist deshalb gut, wenn der Abstand zwischen dem WRITE und dem COMMIT kurz ist.

122 Transaktionen und Datenintegrität 122 Eine Transaktion mit einem höheren Zeitstempel darf das Objekt schreiben und überschreibt dadurch den vorläufigen Wert des Objektes (mit einen ebenfalls vorläufigen Wert). Wenn der alte Wert und der alte Schreib- Zeitstempel t w in der Datenbank verfügbar gehalten werden, können READ-Anfragen von Transaktionen mit Zeitstempeln zwischen dem alten und dem neuen Schreib-Zeitstempel mit dem alten Wert des Objektes bedient werden.

123 Transaktionen und Datenintegrität 123 Vergleich Optimistic vs. Locking Die Anzahl der Datenbankoperationen ist bei der Optimistic Concurrency Control kleiner als beim Locking. Im Schlimmsten Fall (dem Update) sind für Optimistic Concurrency Control 2 Operationen nötig, für das Locking aber 4: Optimistic WRITE COMMIT Locking LOCK WRITE UNLOCK COMMIT Wenn Konflikte zwischen Transaktionen nicht sehr häufig sind, ist der Ansatz der Optimistic Concurrency Control dem Locking vorzuziehen.

124 Transaktionen und Datenintegrität 124 Restart von Transaktionen Problem: Live-Lock Eine Transaktion wird immer wieder abgebrochen. Beispiel: T1 T2 T1 T2 A B RT = 0 RT = 0 WT = 0 WT = 0 (1 WRITE B WT = 100 (2 WRITE A WT = (3 READ A (4 WRITE B WT = 120 (5 READ B (6 WRITE A WT = (7 READ A Fig Indefinite repetition of two confliction transactions.

125 Transaktionen und Datenintegrität 125 Beispiel: (Fortsetzung) Schritt 3: T 1 will A lesen, A hat aber einen Schreib- Zeitstempel der größer ist als der Zeitstempel von T 1. T 1 wird daher abgebrochen. T 1 wird sofort wieder mit einem Zeitstempel von 120 gestartet. Schritt 4: T 1 schreibt B B(t w ) := 120 Schritt 5: T 2 versucht B zu lesen abort. T 2 wird sofort wieder mit einem Zeitstempel von 130 gestartet. Dies kann sich immer weiter wiederholen.

126 Transaktionen und Datenintegrität 126 Es gibt für dieses Problem keine einfache Lösung. Benutze einen Zufallszahlengenerator, um eine Zeit Δt zu ermitteln, die eine abgebrochene Transaktion warten muss, bis sie wieder gestartet werden kann. Notiz: Auch bei dieser Lösung kann es theoretisch passieren, dass ein Live-Lock eintritt, allerdings mit einer geringeren Wahrscheinlichkeit.