Software-Engineering und Datenbanken Transaktionskonzepte 1
Der Transaktionsbegriff Eine Transaktion ist eine Folge von Operationen, die die Datenbank von einem konsistenten Zustand in einen neuen überführen. Dabei müssen für jede Transaktion die folgenden 4 Eigenschaften gelten: Atomizität Konsistenz Isolation Dauerhaftigkeit Transaktionskonzepte-2
Beispiele Szenario 1 : Flugbuchung Prüfen ob gewünschter Platz vorhanden und anschließendes reservieren. Szenario 2: Geldtransfer Eine bestimmte Summe soll von einem Konto auf ein anderes gebucht werden. Szenario 3: Controlling Abgleich der Ausgaben mit den Einnahmen. Transaktionskonzepte-3
Das ACID-Prinzip (AC) Atomicity Eine Transaktion wird immer als Einheit betrachtet. Sie wird also entweder ganz oder gar nicht ausgeführt. Consistency Der von einer Transaktion hinterlassene Zustand muss den Integritätsbedingungen genügen. Transaktionskonzepte-4
Das ACID-Prinzip (ID) Isolation Eine Transaktion muss immer so ablaufen, als ob sie allein auf der Datenbank arbeitet. Transaktionen müssen serialisierbar sein. Durability Nach Beendigung einer Transaktion muss sich der Anwender darauf verlassen können, dass die Ergebnisse dauerhaft in der Datenbank stehen. Transaktionskonzepte-5
Transaktionshandling Einleitung einer neuen Transaktion BEGIN TRANSACTION Abbruch der laufenden Transaktion ROLLBACK [ WORK ] Beendigung einer erfolgreichen Transaktion COMMIT [ WORK ] Transaktionskonzepte-6
Recovery Unter dem Begriff Recovery versteht man: Entfernen aller Spuren erfolglos abgebrochener Transaktionen. Sicherstellen, dass alle erfolgreich abgeschlossenen Transaktionen vorhanden sind. Wann erforderlich? System Crash Anwendungsfehler (Division durch 0, o.ä.) Anwendungsabbruch (programmiertes ABORT) Deadlock,... Transaktionskonzepte-7
Das "Lost Update"-Problem Beispiel: TA1: READ (Konto1); Konto1 = Konto1 - Y; WRITE (Konto1); TA2: READ (Konto1); Konto1 = Konto1 + X; WRITE (Konto1); In Abhängigkeit von der Reihenfolge geht eine Änderung verloren! Transaktionskonzepte-8
Das "Dirty Read"-Problem Beispiel: TA1: READ (Konto1); Konto1 = Konto1 - Y; WRITE (Konto1); ROLLBACK; TA2: READ (Konto1); Konto1 = Konto1 + X; WRITE (Konto1); COMMIT; Ein geänderter Wert wurde verwendet, obwohl die Transaktion nicht zu Ende kam. Transaktionskonzepte-9
Das "Unrepeatable Read"-Problem Beispiel: TA1: READ (Konto1); Konto1 = Konto1 - Y; WRITE (Konto1); COMMIT TA2: READ (Konto1); READ (Konto1); Ein Datum wird mehrfach mit verschiedenen Werten eingelesen. Transaktionskonzepte-10
Das "Incorrect Summary"-Problem Beispiel: TA1: TA2: READ (Konto1); SUM = SUM + Konto1; READ (Konto1); READ (Konto3); READ (Konto2); SUM = SUM + Konto2; Konto1 = Konto1 - X; Konto3 = Konto3 + X; WRITE (Konto1); WRITE (Konto3); READ (Konto3); SUM = SUM + Konto3; Während Aggregatberechnung: Änderung der Ausgangsdaten. Transaktionskonzepte-11
Das "Phantom"-Problem Beispiel: TA1: SELECT * FROM Angestellte WHERE wohnort = 'ZW'; SELECT * FROM Angestellte WHERE wohnort = 'ZW'; TA2: UPDATE Angestellte SET wohnort = 'ZW' WHERE name = 'Rudi Meier'; COMMIT; Plötzlich tauchen neue Sätze auf. Transaktionskonzepte-12
Ursache Mehrere Transaktionen arbeiten gleichzeitig. Parallele Änderungsoperationen werden ausgeführt. Forderung: Das Ergebnis einer Transaktion soll so aussehen, als sei sie nach dem ACID-Prinzip abgelaufen. Transaktionskonzepte-13
Ist Isolation immer erforderlich? Welche Probleme treten bei den folgenden Überweisungstransaktionen auf? T1 read (A) A -= 10 write (A) read (B) B += 10 write (B) T2 read (B) B -= 20 write (B) read (A) A += 20 write (A) Transaktionskonzepte-14
Definition von Isolation Level Der Benutzer muss sich normalerweise nicht um die einzelnen Sperren kümmern. Beeinflussung des Transaktionsverhaltens: SET TRANSACTION [ <access-mode> ] [ <isolation-level> ] [ <diagnostic-area-size> ] <access-mode> := READ ONLY READ WRITE <isolation-level> := ISOLATION LEVEL <isolation> <isolation> := READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE Transaktionskonzepte-15
Bedeutung der Isolation Level SERIALIZABLE Es wird Serialisierbarkeit garantiert. REPEATABLE READ Phantome sind möglich. READ COMMITTED Nonrepeatable Read ist möglich. READ UNCOMMITTED Dirty Read ist möglich. Transaktionskonzepte-16
Transaktionskonzepte Realisierung 17
Schedules Ein Schedule (Ausführungsplan) S ist eine geordnete Folge von DB-Operationen. Plan zur verschränkten Ausführung von Transaktionen. Die Reihenfolge der Operationen einer Transaktion bleibt in dem Schedule erhalten. Die relevanten Operationen sind: READ, WRITE, COMMIT, ABORT Die Menge der Operationen in S wird im folgenden als: Ops(S) bezeichnet. Transaktionskonzepte-18
Serialisierbare Schedules Ein Schedule heisst seriell, wenn die Schritte je einer Transaktion unmittelbar aufeinander folgen. T1 read (A) write (A) T2 read (B) write (B) Ein Schedule heisst serialisierbar, wenn sein Ergebnis äquivalent zu einem seriellen Ergebnis ist. T1 read (A) write (A) T2 read (B) write (B) Transaktionskonzepte-19
Anmerkung zur Serialisierbarkeit Das Ergebnis der Ausführung von 2 Transaktionen kann durchaus von der Reihenfolge abhängen auch wenn diese serialisierbar sind. Beispiel: TA1: TA2: UPDATE Angestellte UPDATE Angestellte SET abteilung = 'GeFü' SET gehalt = gehalt - 1000 WHERE name = 'Meier' WHERE abteilung = 'GeFü' Transaktionskonzepte-20
Übung Serialisierbarkeit Gegeben seien folgende Schedules: T1 read (A) write (A) read (B) write (B) T2 read (A) write (A) read (B) write (B) T1 read (A) write (A) read (B) write (B) T2 read (A) write (A) read (B) write (B) T1 read (A) write (A) read (B) write (B) T2 read (A) write (A) read (B) write (B) Transaktionskonzepte-21
Konflikte in Schedules Zwei Operationen stehen in einem Konflikt, wenn: sie zu verschiedenen Transaktionen gehören und das gleiche Datenelement zugreifen und eine der Operation eine Schreiboperation (write) ist. Konfliktrelation eines Schedules S C(S) = { (p,q) p und q sind Operationen p und q stehen in einem Konflikt p und q gehören nicht zu abgebr. TAs p steht vor q in S } Die Interpretation der Tupel als gerichtete Kanten wird als Konfliktgraph bezeichnet. Transaktionskonzepte-22
Konfliktserialisierbarkeit 2 Schedules S und S' heißen "konfliktäquivalent", wenn gilt, dass alle Paare von Schritten von nichtabgebrochenen Transaktionen in der gleichen Reihenfolge in Konflikt stehen: C (S) = C(S') Ops(S) = Ops(S') Ein Schedule heißt "konfliktserialisierbar", wenn ein serieller, konfliktäquivalenter Schedule existiert. Transaktionskonzepte-23
Schedule: Überprüfung der Konfliktserialisierbarkeit 1 T1 T2 T3 read (A) read (C) write (A) read (A) write (A) write (C) read (C) read (B) write (B) read (B) write (C) write (B) Transaktionskonzepte-24
Schedule: Konfliktrelation: Überprüfung der Konfliktserialisierbarkeit 2 T1 T2 T3 read (A) read (C) write (A) read (A) write (A) write (C) read (C) read (B) write (B) read (B) write (C) write (B) C(S) = { (T1.read(A), T2.write(A)), (T1.write(A), T2.read(A)), (T1.write(A), T2.write(A)), (T3.read(C), T1.write(C)), (T3.write(C), T1.read(C)), (T2.read(B), T3.write(B)),... } Transaktionskonzepte-25 T2 T1 T3
CSR VSR Schedule: T1 T2 T3 read (A) read (B) read (A) write (A) write (C) write (C) write (D) write (C) Transaktionskonzepte-26
CSR VSR Schedule: T1 T2 T3 read (A) read (B) read (A) write (A) write (C) write (C) write (D) write (C) Konfliktrelation: C(S) = { (T2.read(A), T1.write(A)), (T1.write(C), T2.write(C)), (T1.write(C), T3.write(C)), (T2.write(C), T3.write(C)) } T2 T1 T3 Transaktionskonzepte-27
Aufwand für Test auf Serialisierbarkeit Test auf allgemeine (View-)Serialisierbarkeit NP-vollständiges Problem! Test auf Konfliktserialisierbarkeit Zyklenerkennung in Abhängigkeitsgraphen ist erforderlich. Polynomialer Aufwand! Praxisproblem: Führt zur Laufzeit zu häufigem Rücksetzen. Dialogtransaktionen sind nicht vollständig bekannt. Transaktionskonzepte-28
Concurrency-Control-Mechanismen Sperrverfahren Zeitstempelverfahren optimistische Verfahren Transaktionskonzepte-29
Sperren Keine Transaktion darf auf ein von einer anderen Transaktion gesperrtes Datenelement zugreifen. Sperren vor Bearbeitung Freigabe danach Sperrgranularität Datenbank Tabelle Seite Satz Feld Transaktionskonzepte-30
Sperrarten Die meisten DBS unterstützen 2 Sperrarten. Shared Locks (S-Locks, Lesesperren) Ermöglichen paralleles Lesen. Verhindern Änderungen. Exclusive Locks (X-Locks, Schreibsperren) Erlauben nur dem Sperrinhaber zu lesen und zu ändern. Viele weitere Sperrmodi sind möglich: z.b.: Intention Locks Transaktionskonzepte-31
Das 2-Phasen-Sperr-Protokoll (2PL) Garantierte Serialisierbarkeit durch geordnete Anforderung und Freigabe von Sperren. Keine Freigabe von Sperren solange nicht alle benötigten Sperren angefordert wurden. 1. Phase: Anforderung von Sperren 2. Phase: Freigabe von Sperren Transaktionskonzepte-32
Problem: kaskadierende Abbrüche T1 T2 T3... x-lock (A) x-lock (A) read (A) write (A) unlock (A)... read (A)... write (A)... unlock (A)... x-lock (B) s-lock (B)... read (B)... write (B)... unlock (B)...... read (B)...... unlock (B)!rollback! Transaktionskonzepte-33
Das strenge 2-Phasen-Sperr-Protokoll (S2PL) Wie bei 2 PL 1. Phase: Anforderung von Sperren 2. Phase: Freigabe von Sperren Zusätzlich Alle Sperren werden gemeinsam beim COMMIT freigegeben. Vermeidet dadurch kaskadierende Abbrüche. Löst das nun alle Sperrprobleme? Transaktionskonzepte-34
Das Deadlock-Problem Beispiel: TA1: X-LOCK (Konto1); X-LOCK (Konto2); TA2: X-LOCK (Konto2); TA1 ist nun blockiert! X-LOCK (Konto1); Nun ist auch TA2 blockiert! Transaktionskonzepte-35
Wann treten Deadlocks auf? Jede Transaktion wartet auf Sperren, die eine andere Transaktion hält! In eine solche Wartesituationen können beliebig viele Transaktionen involviert sein. Sperrgraph: x->y bedeutet: "x wartet auf y" TA1 TA5 TA2 TA6 TA7 TA4 TA3 Transaktionskonzepte-36
Auflösung von Deadlocks Eine der beteiligten Transaktionen muss zurückgerollt werden. Kriterien? Entdeckung von Deadlocks Analyse von Sperrgraphen erforderlich Wann soll Analyse durchgeführt werden? Sperrgraphen sind sehr dynamisch Pragmatische Lösung Timeout-Mechanismus Transaktionskonzepte-37
Zeitstempel Alternativer Ansatz zur Erreichung von Serialisierbarkeit: Jede Transaktion T erhält beim Start einen eindeutigen, aufsteigenden Zeitstempel zugeordnet: TS (T) Ziel: Serialisierung der Transaktionen in Zeitstempelreihenfolge - falls erforderlich. Für jedes Datenobjekt X: Read_TS(X) - der höchste Zeitstempel einer Transaktion, die das Datum erfolgreich gelesen hat. Write_TS(X) - der höchste Zeitstempel einer Transaktion, die das Datum erfolgreich geändert hat. Transaktionskonzepte-38
Ablauf der Zeitstempel-Serialisierung Bei Zugriff auf Datum X durch Transaktion T: WRITE(X) Falls Write _TS(X) > TS(T) oder Read_TS(X) > TS(T): Abbruch von T! Ansonsten: Write _TS(X) = TS(T). READ(X) Falls Write_TS(X) > TS(T): Abbruch von T! Ansonsten: Read _TS(X) = MAX ( TS(T), Read _TS(X) ) Transaktionskonzepte-39
Eigenschaften Zeitstempel- Serialisierung Deadlocks sind nun unmöglich! Es ist jedoch nur ein Teil der serialisierbaren Schedules möglich. Zurückrollen von T hat Konsequenzen für alle Transaktionen, die Daten von T gelesen haben. Kaskadierendes Rollback! Kaskadierende Abbrüche sorgen für hohen Aufwand. Transaktionskonzepte-40
Verbesserungen/Optimierungen "Thomas's write rule" falls Read_TS(X) <= TS(T) und Write_TS(X) > TS(T) kein Abbruch, sondern ignorieren der WRITE-Anweisung. Ermöglicht zusätzlich Schedules, die VSR aber nicht CSR sind! "strict Timestamp Ordering" bei TS (T) > Write _TS(X) wird das Schreiben/Lesen verzögert, bis die Transaktion, die zu Write _TS(X) gehört beendet ist. Vermeidet kaskadierende Abbrüche. Transaktionskonzepte-41