8. Grundlagen des Transak0onskonzepts Vorlesung "Informa0onssysteme" Sommersemester 2015
Überblick Wie erzielt man Atomarität von DB- Opera0onen und Transak0onen? Atomare Ak0onen im Schichtenmodell Schlüsselrolle von Synchronisa0on sowie Logging und Recovery Erhaltung der DB- Konsistenz Anomalien im Mehrbenutzerbetrieb Verlorengegangene Änderungen Inkonsistente Analyse, Phantom- Problem usw. Synchronisa0on von Transak0onen Ablaufpläne, Modellannahmen Korrektheitskriterium, Konsistenzerhaltende Ablaufpläne Theorie der Serialisierbarkeit Äquivalenz von Historien, Serialisierbarkeitstheorem Klassen von Historien Zwei- Phasen- Sperrprotokolle (2PL) Logging und Recovery Zwei- Phasen- Commit- Protokoll (2PC) Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 2
What can go wrong, will go wrong Transak0onskonzept führt ein neues Verarbeitungsparadigma ein ist Voraussetzung für die Abwicklung betrieblicher Anwendungen (mission- cri)cal applica)ons) erlaubt Vertragsrecht in rechnergestützten IS zu implemen0eren ACID- Transak0onen zur Gewährleistung weit reichender Zusicherungen zur Qualität der Daten, die gefährdet sind durch fehlerhace Programme und Daten im Normalbetrieb inkorrekte Synchronisa0on von Opera0onen im Mehrbenutzerbetrieb vielfäl0ge Fehler im DBS und seiner Umgebung Logging und Recovery bietet Schutz vor erwarteten Fehlern! Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 3
What can go wrong, will go wrong Entwicklungsziele Build a system used by millions of people that is always available out less than 1 second per 100 years = 8 9 s of availability! (J. Gray: 1998 Turing Award Lecture) Verfügbarkeit heute (op0mis0sch): 3 - für Web- Sites: 99% - in der Cloud (Amazon): 99,95% - für gut administrierte Systeme: 99,99% - höchstens: 99,999% Küncige Verfügbarkeit - da fehlen noch 5 9- er - bis wann zu erreichen??? Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 4
Mögliche Ausgänge einer Transak0on BOT DML1 DML2 DML3 DMLn BOT DML1 DML2 DML3 DMLn BOT DML1 DML2 DML3 Systemausfall, Programmfehler, usw. COMMIT ROLLBACK erzwungenes ROLLBACK normales Ende abnormales Ende erzwungenes abnormales Ende Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 5
Transak0onen als dynamische Kontrollstruktur Atomicity Atomarität ist keine natürliche Eigenschac von Rechnern Consistency Konsistenz und seman0sche Integrität der DB ist durch fehlerhace Daten und Opera0onen eines Programms gefährdet. Isola0on Isolierte Ausführung bedeutet logischen Einbenutzerbetrieb Durability Dauerhacigkeit heißt, dass die Daten und Änderungen erfolgreicher Transak0onen jeden Fehlerfall überleben müssen ACID- Transak0onen befreien den Anwendungsprogrammierer von den Aspekten der Ablaufumgebung des Programms und von möglichen Fehlern! Wie setzt man diese Forderungen systemtechnisch um? hier nur Einführung von Begriffen ver0efende Betrachtung und Diskussion von Realisierungskonzepten in nachfolgenden Vorlesungen (DBS) Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 6
Bausteine für Transak0onen Atomare Ak0onen Schichtenspezifische Operationen Select From Where Insert Into Füge Satz ein Modifiziere Zugriffspfad Stelle Seite bereit Gib Seite frei Lies/Schreibe Seite Atomare Aktionen und Benutzerhierarchie Datensystem Zugriffssystem Speichersystem DB Gedankenversuch Abwicklung einer SQL-Op Zeitpunkt 1 Auch atomare Aktionen sind Abstraktionen! Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 7
Bausteine für Transak0onen Atomare Ak0onen (2) Schichtenspezifische Operationen Gedankenversuch Abwicklung einer SQL-Op Select From Where Insert Into Füge Satz ein Modifiziere Zugriffspfad Stelle Seite bereit Gib Seite frei Lies/Schreibe Seite Zeitpunkt 2 Zeitpunkt 3 Zeitpunkt 4 Selbst wenn AA atomar implementiert wäre, Hierarchie von AA wäre es nicht! Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 8
Schutzbedürfnis einer flachen Transak0on und Zusicherungen an den Programmierer Schichtenspezifische Operationen Schutzmaßnahmen im Ausführungspfad des DBS funktionieren nicht! Select From Where Insert Into SQL-Op1... SQL-Opn Füge Satz ein Modifiziere Zugriffspfad Stelle Seite bereit Gib Seite frei Lies/Schreibe Seite SQL garantiert Anweisungsatomarität und natürlich Transaktionsatomarität! Realisierung verlangt vor allem - Synchronisation im Mehrbenutzerbetrieb (concurrency transparency) - Logging und Recovery (failure transparency) Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 9
Erhaltung der DB- Konsistenz Erhaltung der seman0schen Datenintegrität Beschreibung der Rich0gkeit von Daten durch Prädikate und Regeln, bereits bekannt: - modellinhärente Bedingungen (rela0onale Invarianten) - anwendungsspezifische Bedingungen (Check, Unique, Not Null,...) ak0ve Maßnahmen des DBS erwünscht (Trigger, ECA- Regeln) Qualitätskontrollen bei Änderungsopera0onen Ziel Nur DB- Änderungen zulassen, die allen definierten Constraints entsprechen (offensichtlich falsche Änderungen zurückweisen!) Möglichst hohe Übereins0mmung von DB- Inhalt und Miniwelt (Datenqualität) Integritätsbedingungen der Miniwelt sind explizit bekannt zu machen, um automa0sche Überwachung zu ermöglichen. Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 10
Erhaltung der DB- Konsistenz (2) Konsistenz der Transak0onsverarbeitung Bei COMMIT müssen alle Constraints erfüllt sein Zentrale Spezifika0on/Überwachung im DBS: system enforced integrity C von ACID sichert dem Programmierer zu, dass vor BOT und nach EOT der DB- Zustand alle Constraints des DB- Schemas erfüllt! T 1 BOT O 11 O 12 O 13 EOT DML-Operationskonsistenz TA-Konsistenz T 2 BOT O 21 O 22 O 23 EOT BOT: Begin of Transaction EOT (Commit): End of Transaction O ij : DB-Operation; Lese- und Schreiboperationen auf DB-Daten Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 11
Erhaltung der DB- Konsistenz (3) Verfeinerung des Konsistenzbegriffes Transak0onsatomarität impliziert Transak0onskonsistenz: nur Änderungen erfolgreicher Transak0onen sind in der DB enthalten Anweisungsatomarität impliziert DML- Opera0onskonsistenz: DML- Opera0on hält schichtenspezifische Konsistenz des Datensystems ein DML- Opera0onen setzen sich aus Ak0onen zusammen: Ak0onskonsistenz und Geräte- /Dateikonsistenz sind wiederum Voraussetzung, dass DML- Opera0onen und Ak0onen überhaupt auf den Daten abgewickelt werden können Systemhierarchie + DB-Konsistenz Transaktionskonsistenz DML-Operationskonsistenz Aktionskonsistenz Geräte-/Dateikonsistenz Atomare Aktionen und Benutzerhierarchie Tabellen, Sichten, Sätze, Felder, Seiten, TAP Gehaltserhöhung Update Pers Set Where Q Update Index Pers (Pnr) Using 4711 Read Page / Write Page Spuren, Zylinder, Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 12
Erhaltung der DB- Konsistenz (4) Welche Konsistenzart garan0ert jede Schicht nach erfolgreichem Abschluss einer schichtenspezifischen Opera0on? Speichersystem Geräte- /Dateikonsistenz (einzelne Seite) Jede Seite muss physisch unversehrt, d. h. lesbar oder schreibbar sein Zugriffssystem Ak0onskonsistenz (mehrere Seiten) Sätze und Zugriffspfade müssen für Ak0onen in sich konsistent sein, d. h. beispielsweise: Alle Zeiger müssen s0mmen! Datensystem DML- Opera0onskonsistenz (oc viele Seiten) Datenbank Transak0onskonsistenz Alle Constraints des DB- Schemas müssen erfüllt sein! Konsistenz einer Schicht setzt schichtenspezifische Konsistenz aller darunter liegenden Schichten voraus! Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 13
Warum Mehrbenutzerbetrieb? Ausführung von Transak0onen CPU- Nutzung während TA- Unterbrechungen - E/A - Denkzeiten bei Mehrschriz- TA - Kommunika0onsvorgänge in verteilten Systemen bei langen TA zu große Wartezeiten für andere TA (Scheduling- Fairness) Einbenutzerbetrieb T1...... T2...... T3...... Mehrbenutzerbetrieb T1 T2 T3 Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 14
Anomalien im unkontrollierten Mehrbenutzerbetrieb 1. Abhängigkeit von nicht freigegebenen Änderungen (dirty read, dirty overwrite) 2. Verlorengegangene Änderung (lost update) 3. Inkonsistente Analyse (non- repeatable read) 4. Phantom- Problem nur durch Änderungs- TA verursacht Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 15
Abhängigkeit von nicht freigegebenen Änderungen Geänderte, aber noch nicht freigegebene Daten werden als schmutzig bezeichnet (dirty data), da die TA ihre Änderungen bis Commit (einsei0g) zurücknehmen kann T1 read (A); A := A + 100 write (A); abort; T2 read (A); read (B); B := B + A; write (B); commit; Schmutzige Daten dürfen von anderen TAs nicht in kri0schen Opera0onen benutzt werden Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 16
Verlorengegangene Änderung (Lost Update) T1 T2 A in DB read (A); 10 10 read (A); 10 10 A := A 2; write (A) 8 10 8 A := A 1; write (A); 9 8 9! Verlorengegangene Änderungen sind auszuschließen! Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 17
Inkonsistente Analyse (Non- repeatable Read) Das wiederholte Lesen einer gegebenen Folge von Daten führt auf verschiedene Ergebnisse: Lesetransak0on (Gehaltssumme berechnen) SELECT Gehalt INTO :gehalt FROM Pers WHERE Pnr = 2345 summe := summe + gehalt SELECT Gehalt INTO :gehalt FROM Pers WHERE Pnr = 3456 summe := summe + gehalt = 89.000! Änderungstransak0on UPDATE Pers SET Gehalt = Gehalt + 1000 WHERE Pnr = 2345 UPDATE Pers SET Gehalt = Gehalt + 2000 WHERE Pnr = 3456 Zeit DB- Inhalt (Pnr, Gehalt) 2345 39.000 3456 48.000 = 87.000 2345 40.000 3456 50.000 = 90.000 Inkonsistenz auch möglich, wenn nicht wiederholt auf das gleiche Datum zugegriffen wird! Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 18
Phantom- Problem Einfügungen können Leser zu falschen Schlussfolgerungen verleiten: Lesetransak0on (Gehaltssumme überprüfen) SELECT SUM (Gehalt) INTO :summe FROM Pers WHERE Anr = 17 SELECT Gehaltssumme INTO :gsumme FROM Abt WHERE Anr = 17 Änderungstransak0on (Einfügen eines neuen Angestellten) INSERT INTO Pers (Pnr, Anr, Gehalt) VALUES (4567, 17, 55.000) UPDATE Abt SET Gehaltssumme = Gehaltssumme + 55.000 WHERE Anr = 17 IF gsumme <> summe THEN <Fehlerbehandlung> Zeit Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 19
Synchronisa0on von Transak0onen TRANSAKTION: Ein Programm T mit DML- Anweisungen, das folgende Eigenschac erfüllt: Wenn T allein auf einer konsistenten DB ausgeführt wird, dann terminiert T (irgendwann) und hinterlässt die DB in einem konsistenten Zustand. (Während der TA- Verarbeitung gibt es keine Konsistenzgaran0en!) Ablaufpläne für 3 Transak0onen T1 T2 T3 verzahnter Ablaufplan serieller Ablaufplan Wenn Transak0onen seriell ausgeführt werden, dann bleibt die Konsistenz der DB erhalten. Ziel der Synchronisa0on: logischer Einbenutzerbetrieb, d.h. Vermeidung aller Mehrbenutzeranomalien Fundamentale Fragestellung: Wann ist die parallele Ausführung von n Transak0onen auf gemeinsamen Daten korrekt? Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 20
Synchronisa0on von Transak0onen (2) Beispiel für einige Ausführungsvarianten (ini0al: A=B=C=10) Ausführung 1 Ausführung 2 Ausführung 3 T1 T2 T1 T2 T1 T2 read (A) A 1 write (A) read (B) B + 1 write (B) read (A) A 1 write (A) read (B) B 2 write (B) read (A) A 1 write (A) read (B) read (B) B 2 read (B) read (B) write (B) B 2 write (B) read (C) C + 2 write (C) B + 1 write (B) read (C) C + 2 write (C) B + 1 write (B) read (C) C + 2 write (C) A=9, B=9, C=12 A+B+C=30 dasselbe Ergebnis nach T2; T1 A=9, B=9, C=12 A+B+C=30 A=9, B=11, C=12 A+B+C=32 Bei serieller Ausführung bleibt der Wert von A + B + C unverändert! Ziel: Äquivalenz der Ergebnisse von verzahnten Ausführungen zu einer der möglichen seriellen Ausführungen Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 21
Modellbildung für die Synchronisa0on Wie kann die Korrektheit der Ausführung im Mehrbenutzerbetrieb überprüc werden? Korrektheitskriterium: Konfliktserialisierbarkeit Geschichtsschreiber zeichnet Historie H auf - Umformung der aufgezeichneten Opera0onsfolge H in eine äquivalente serielle Opera0onsfolge - post mortem - Analyse Tatsächliche Umsetzung Scheduler überprüc jede Opera0on Op i und erzwingt einen serialisierbaren Ablaufplan S (Schedule) - wenn Op i in S konflik rei ist, wird sie ausgeführt und an S angehängt - sonst wird Op i blockiert oder gar die zugehörige Transak0on zurückgesetzt Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 22
Modellbildung für die Synchronisa0on (2) Einsatzmöglichkeiten für Geschichtsschreiber oder Scheduler Select * From Pers Where P Delete From Pers Where Q S S D Datensystem Datensystem Datensystem Update t 1 From Pers Insert 4711 into I Pers (Pnr) U I R Zugriffssystem Zugriffssystem Zugriffssystem Read Page Write Page r 1 (x) w 2 (y) w 1 (y) Speichersystem Speichersystem Speichersystem Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 23
Synchronisa0on - Modellannahmen Read/Write- Modell (Page Model) DB ist Menge von unteilbaren, uninterpre0erten Datenobjekten (z. B. Seiten) DB- Anweisungen lassen sich nachbilden durch atomare Lese- und Schreibopera0onen auf Objekten: - r i [A], w i [A] zum Lesen bzw. Schreiben des Datenobjekts A - c i, a i zur Durchführung eines commit bzw. abort Transak0on wird modelliert als eine endliche Folge von Opera0onen p i : - T = p 1 p 2 p 3... p n mit p i {r[x i ], w[xi]} Eine vollständige TA hat als letzte Opera0on entweder einen Abbruch a oder ein Commit c - T = p 1... p n a oder T = p 1... p n c Für eine TA T i werden diese Opera0onen mit r i, w i, c i oder a i bezeichnet, um sie zuordnen zu können Die Ablauffolge von TA mit ihren Opera0onen lässt sich wie folgt beschreiben: r 1 [A] r 2 [A] r 3 [B] w 1 [A] w 3 [B] r 1 [B] c 1 r 3 [A] w 2 [A] a 2 w 3 [C] c 3... Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 24
Korrektheitskriterium der Synchronisa0on Serieller Ablauf von Transak0onen TA = {T1, T2, T3} DB = {A, B, C} T1 A C w 1 (A) w 1 (C) T2 B C w 2 (B) r 2 (C) T3 Ausführungsreihenfolge: T1 T2 T3 A B w 3 (A) w 3 (B) t T1 T2 bedeutet: - T1 sieht keine Änderungen von T2 und - T2 sieht alle Änderungen von T1 Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 25
Korrektheitskriterium der Synchronisa0on (2) Formales Korrektheitskriterium Serialisierbarkeit: Die parallele Ausführung einer Menge von TA ist serialisierbar, wenn es eine serielle Ausführung derselben TA- Menge gibt, die den gleichen DB- Zustand und die gleichen Ausgabewerte wie die ursprüngliche Ausführung erzielt. Hintergrund: Serielle Ablaufpläne sind korrekt! Jeder Ablaufplan, der denselben Effekt wie ein serieller erzielt, ist akzep0erbar Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 26
Konsistenzerhaltende Ablaufpläne Die TA T1- T3 müssen so synchronisiert werden, dass der resul0erende Zustand der DB gleich dem ist, der bei der seriellen Ausführung in einer der folgenden Sequenzen zustande gekommen wäre: T1, T2, T3 T2, T1, T3 T3, T1, T2 T1, T3, T2 T2, T3, T1 T3, T2, T1 Bei n TA gibt es n! (hier 3! = 6) mögliche serielle Ablaufpläne Serielle Ablaufpläne können aber verschiedene Ergebnisse haben! Beispiel: Einzahlung TA1: +2000; Zinsberechnung TA2: 1.03 Konto Stand (= 2000) TA1 TA2 TA2 TA1 4120 4060 TA1 à 4000; TA2 à 4120 TA2 à 2060; TA1 à 4060 Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 27
Konsistenzerhaltende Ablaufpläne (2) Deshalb: nicht alle seriellen Ablaufpläne sind möglich! T1 r[x] w[y] w[z] T2 r[y] T3 w[x] T4 r[x] Durch Konfliktopera0onen ergeben sich Reihenfolgeabhängigkeiten, die eingehalten werden müssen Mögliche Reihenfolgen: - T2 T1 T4 T3 - T4 T2 T1 T3 - T2 T4 T1 T3 Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 28
Theorie der Serialisierbarkeit Ablauf einer Transak0on Häufigste Annahme: streng sequen0elle Reihenfolge der Opera0onen Serialisierbarkeitstheorie lässt sich auch auf Basis einer par0ellen Ordnung (< i ) entwickeln TA- Abschluss: abort oder commit aber nicht beides! Konsistenzanforderungen an eine TA Falls T i ein abort durchführt, müssen alle anderen Opera0onen p i [A] vor a i ausgeführt werden: p i [A] < i a i Analoges gilt für das commit: p i [A] < i c i Wenn T i ein Datum A liest und auch schreibt, ist die Reihenfolge festzulegen: r i [A] < i w i [A] oder w i [A] < i r i [A] Beispiel: Überweisungs- TA T1 (von K1 nach K2) Totale Ordnung: r 1 [K1] w 1 [K1] r 1 [K2] w 1 [K2] c 1 Par0elle Ordnung r 1 [K1] w 1 [K1] r 1 [K2] w 1 [K2] Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 29 c 1
Theorie der Serialisierbarkeit (2) Historie* Unter einer Historie versteht man den Ablauf einer (verzahnten) Ausführung mehrerer TA Sie spezifiziert die Reihenfolge, in der die Elementaropera0onen verschiedener TA ausgeführt werden - Einprozessorsystem: totale Ordnung - Mehrprozessorsystem: parallele Ausführung einiger Opera0onen möglich par0elle Ordnung (*) Der Begriff Historie bezeichnet eine retrospektive Sichtweise, also einen abgeschlossenen Vorgang. Ein Scheduling-Algorithmus (Scheduler) produziert Schedules, wodurch noch nicht abgeschlossene Vorgänge bezeichnet werden. Manche Autoren machen jedoch keinen Unterschied zwischen Historie und Schedule. Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 30
Theorie der Serialisierbarkeit (3) Konfliktopera0onen: Kri0sch sind Opera0onen verschiedener Transak0onen auf denselben DB- Daten, wenn dieser Opera0onen nicht reihenfolgeunabhängig sind! Was sind Konfliktopera0onen? r i [A] und r j [A]: Reihenfolge ist irrelevant kein Konflikt! r i [A] und w j [A]: Reihenfolge ist relevant und festzulegen. Entweder r i [A] w j [A] R/W- Konflikt! oder w j [A] r i [A] W/R- Konflikt! w i [A] und r j [A]: analog w i [A] und w j [A] Reihenfolge ist relevant und festzulegen W/W- Konflikt! Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 31
Theorie der Serialisierbarkeit (4) Beschränkung auf Konflikt- Serialisierbarkeit Historie H für eine Menge von TA {T1,..., Tn} ist eine Menge von Elementaropera0onen mit par0eller Ordnung < H, so dass gilt: 1. H = T i (für 1 i n) - jede TA is vollständig in H enthalten, ist also abgeschlossen 2. < H < i (für 1 i n) - < H ist verträglich mit allen < i - Ordnungen - lokale Ordnung von ops in TA i bleibt erhalten 3. Für zwei Konfliktopera0onen p, q H gilt entweder p < H q oder q < H p - Reihenfolge von Konfliktop. ist immer definiert Ein Schedule ist ein Präfix einer Historie r 1 [D] r 1 [C] w 1 [B] c 1 r 2 [A] w 2 [B] w 2 [B] c 2 Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 32
Theorie der Serialisierbarkeit (5) Defini0on: Äquivalenz zweier Historien Zwei Historien H und H' sind äquivalent, wenn sie die Konfliktopera0onen der nicht abgebrochenen TA in derselben Reihenfolge ausführen: H H', wenn p i < H q j, dann auch p i < H' q j Bemerkungen Anordnung der konflik reien Opera0onen ist irrelevant Reihenfolge der Opera0onen innerhalb einer TA bleibt invariant Auswirkungen von TA- Abbruch werden später betrachtet Eine Historie H ist serialisierbar, wenn sie äquivalent zu einer seriellen Historie H s ist Mögliche (aber ineffiziente) Prüfung auf Serialisierbarkeit: Kann durch wiederholtes Vertauschen von Opera0onen, die nicht in Konflikt stehen, eine serielle Historie erreicht werden? Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 33
Beispiel zur Äquivalenz von Historien Historie H r 2 [A] w 2 [B] c 2 H = r 1 [A] w 1 [A] w 1 [B] c 1 Totale Ordnung H 1 = r 1 [A] w 1 [A] r 2 [A] w 1 [B] c 1 w 2 [B] c 2 H 2 = r 1 [A] w 1 [A] w 1 [B] c 1 r 2 [A] w 2 [B] c 2 H H 1 H 2 (ist seriell) Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 34
Serialisierbarkeit Ziel: effiziente Entscheidung der Serialisierbarkeit Einführung eines Konfliktgraph G(H) (auch Serialisierbarkeitsgraph SG(H) genannt) Konstruk0on des G(H) über den erfolgreich abgeschlossenen TA Konfliktopera0onen p i, q j aus H mit p i < H q j fügen eine Kante T i T j in G(H) ein, falls nicht schon vorhanden Serialisierbarkeitstheorem Eine Historie H ist genau dann serialisierbar, wenn der zugehörige Konfliktgraph G(H) azyklisch ist Topologische Sor0erung! CSR bezeichne die Klasse aller konfliktserialisierbaren Historien. Die Mitgliedschac in CSR lässt sich in Polynomialzeit in der Menge der teilnehmenden TA testen Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 35
Serialisierbare Historie - Beispiel Beispiel- Historie r 1 [A] w 1 [A] w 1 [B] c 1 H = r 2 [A] w 2 [B] c 2 r 3 [A] w 3 [A] c 3 Zugehöriger Konfliktgraph G(H): T 1 T 2 T 3 topologische Ordnung: T 2 T 1 T 3 Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 36
Serialisierbare Historie - Beispiel (2) Historie H = w 1 [A] w 1 [B] c 1 r 2 [A] r 3 [B] w 2 [A] c 2 w 3 [B] c 3 Konfliktgraph T 1 T 2 T 3 Topologische Ordnungen Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 37
Nicht serialisierbare Historien - Beispiele Lost Update H = r 1 (A) r 2 (A) w 1 (A) w 2 (A) c 1 c 2 T 1 T 2 Inkonsistente Analyse H = r 2 (A) w 2 (A) r 1 (A) r 1 (B) r 2 (B) w 2 (B) c 1 c 2 T 1 T 2 Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 38
Eigenschacen von Historien bzgl. Recovery Serialisierbarkeit ist (nur) eine Minimalanforderung Beispiel: Dirty Read w 1 (A) r 2 (A) c 2 a 1 serialisierbar! TA T j sollte zu jedem Zeitpunkt vor Commit lokal rücksetzbar sein andere T i dürfen nicht betroffen sein Serialisierbarkeitstheorie: Gebräuchliche Klassenbeziehungen SR: serialisierbare Historien RC: rücksetzbare Historien ACA: Historien ohne kaskadierendes Rücksetzen ST: strikte Historien Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 39
Schreib- /Leseabhängigkeiten Kri0sch für lokale Rücksetzbarkeit sind Schreib- / Leseabhängigkeiten w j [A]... r i [A] Defini0on: T i liest von T j in H, wenn gilt 1. T j schreibt mindestens ein Datum A, das T i nachfolgend liest: w j [A] < H r i [A] 2. T j wird (zumindest) nicht vor dem Lesevorgang von T i zurückgesetzt: a j H r i [A] 3. Alle anderen zwischenzeitlichen Schreibvorgänge auf A durch andere TA T k werden vor dem Lesen durch T i zurückgesetzt: Wenn w j [A] < H w k [A] < H r i [A], dann a k < H r i [A] H =... w j [A]... w k [A]... a k... r i [A] Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 40
Rücksetzbare Historie Defini0on: Eine Historie H heißt rücksetzbar (recoverable, RC), falls für alle T i, T j, i j gilt: falls T i von T j liest, dann muss T j vor T i ihr Commit ausführen: c j < H c i H =... w j [A] r i [A] w i [B] c j... a i [c i ] Beispiel: Dirty Read H = w 1 (A) r 2 (A) c 2 a 1 T 2 liest von T 1, aber kein c 1 vor c 2 è H ist nicht rücksetzbar! Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 41
Historie ohne kaskadierendes Rücksetzen Schriz T1 T2 T3 T4 T5 0. 1. 2. 3. 4. 5. 6. 7. 8. 9. w 1 [A] a1 (abort) r 2 [A] w 2 [B] r 3 [B] w 3 [C] r 4 [C] w 4 [D] r 5 [D] Kaskadierendes Rücksetzen abort verursacht Folge von weiteren aborts beeinträch0gt die Leistungsfähigkeit des Systems Defini0on: Eine Historie vermeidet kaskadierendes Rücksetzen (avoids cascading aborts, ACA), wenn c j < H r i [A] gilt, wann immer T i von T j liest Änderungen dürfen erst nach Commit freigegeben werden! Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 42
Strikte Historien Ist folgende Historie unproblema0sch? H = r 1 [B] r 2 [C] w 1 [B] w 2 [B] w 1 [A] a 1 r 2 [A] c 2 H ist serialisierbar: SG(H) = T 1 à T 2 H ist ACA, da T 2 NICHT von T 1 liest (warum?) Problem: Abort- Behandlung von T 1 wird kompliziert - typisches Vorgehen (UNDO- Recovery): für alle w(x) den Zustand von X direkt vor dem Schreiben wiederherstellen - "blindes" Schreiben von B durch T 2 würde dadurch fälschlicherweise auch rückgängig gemacht! - Problem wird durch strikte Historien vermieden Defini0on: Eine Historie H ist strikt, wenn für je zwei TA T i und T j gilt: Wenn w j [A] < H o i [A] (mit o i = r i oder o i = w i ), dann muss gelten: c j < H o i [A] oder a j < H o i [A] Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 43
Klassen von Historien Beziehungen zwischen den Klassen alle Historien SR RC ACA ST serielle Historien Scheduler sollte nur Historien aus SR ACA zulassen! Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 44
Klassen von Historien (2) Beispiele H: r 1 [C] w 1 [B] r 1 [A] c 1 r 2 [B] w 2 [B] w 2 [A] H SR : r 1 [C] r 2 [B] w 2 [B] w 1 [B] w 2 [A] r 1 [A] c 1 c 2 (nicht RC) H RC : r 1 [C] r 2 [B] w 2 [B] w 1 [B] w 2 [A] r 1 [A] c 2 c 1 (nicht ACA) H ACA : r 1 [C] r 2 [B] w 2 [B] w 1 [B] w 2 [A] c 2 r 1 [A] c 1 (nicht ST) H ST : r 1 [C] r 2 [B] w 2 [B] w 2 [A] c 2 w 1 [B] r 1 [A] c 1 (nicht S) H S : r 2 [B] w 2 [B] w 2 [A] c 2 r 1 [C] w 1 [B] r 1 [A] c 1 Scheduler gewährleistet die Einhaltung der Konfliktserialisierbarkeit der gewählten Klasse hier nur Diskussion einfacher Sperrverfahren Scheduler heißt Sperrverwalter oder Lock Manager c 2 Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 45
RX- Sperrverfahren Sperrmodi Sperrmodus des Objektes: NL (no lock), R (read), X (exclusive) Sperranforderung einer Transak0on: R, X Kompa0bilitätsmatrix: aktueller Modus des Objekts NL R X angeforderter Modus der TA R + + - X + - - Falls Sperre nicht gewährt werden kann, muss die anfordernde TA warten, bis das Objekt freigegeben wird (Commit/Abort der die Sperre besitzenden TA) Wartebeziehungen werden in einem Wait- for- Graph (WfG) verwaltet Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 46
RX- Sperrverfahren (2) Ablauf von Transak0onen T1 T2 a b Bem. NL NL lock(a, X) X 1... lock (b, R) R 2... lock (b, R) R 2, R 1 lock (a, R) X 1 T2 wartet, WfG: a T 2 à T 1... unlock (a) NL > R 2 T2 wecken,...... WfG: - unlock (b) R 2 Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 47
Zweiphasen- Sperrprotokolle Einhaltung folgender Regeln gewährleistet Serialisierbarkeit: Vor jedem Objektzugriff muss Sperre mit ausreichendem Modus angefordert werden Gesetzte Sperren anderer TA sind zu beachten Eine TA darf nicht mehrere Sperren für ein Objekt anfordern Zweiphasigkeit (two- phase locking, 2PL): - Anfordern von Sperren erfolgt in einer Wachstumsphase - Freigabe der Sperren in Schrumpfungsphase - Sperrfreigabe kann erst beginnen, wenn alle benö0gten Sperren gehalten werden Spätestens bei Commit sind alle Sperren freizugeben Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 48
Zweiphasen- Sperrprotokolle - Beispiel Beispiel für ein 2PL- Protokoll BOT lock (a, X)... lock (b, R)... lock (c, X)... unlock (b) unlock (c) unlock (a) Commit w(a) r(b) w(c) Zugriff auf n Sätze einer Tabelle - einzelne Sätze oder ganze Tabelle sperren? - dynamische Entscheidung: Sperr-Eskalation An der SQL- Schnizstelle ist die Sperranforderung und freigabe nicht sichtbar! erfolgt implizit/automa0sch beim Ausführen von DML- Befehlen Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 49
Zweiphasen- Sperrprotokolle (2) Anwendung des 2PL- Protokolls T1 T2 Bem. BOT lock (a,x) read (a) write(a) lock (b, X) read (b) unlock (a) unlock (b) abort! BOT lock (a, X) read (a) write (a) unlock (a) commit T2 wartet, WfG: T2 wecken, WfG: - dirty read! a T 2 à T 1 Zweiphasiges Protokoll reicht für den praktischen Einsatz nicht aus! Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 50
Zweiphasen- Sperrprotokolle (3) Formen der Zweiphasigkeit zweiphasig: strikt zweiphasig: preclaiming: #Sperren BOT EOT BOT EOT BOT EOT Strikte 2PL- Protokolle SS2PL (strong 2PL) gibt alle Sperren (X und R) erst bei Commit frei S2PL (strict 2PL) gibt alle X- Sperren erst bei Commit frei Sie verhindern dadurch dirty reads und kaskadierendes Rücksetzen Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 51
Verklemmungen (Deadlocks) Aucreten von Verklemmungen ist inhärent und kann bei pessimis0schen Methoden (blockierende Verfahren) nicht vermieden werden. Nicht- serialisierbare Historie läuft vor ab T1 w(a) w(c) SG T 1 T2 r(c) r(b) T 2 T 3 T3 w(b) r(a) RX- Verfahren verhindert das Aucreten einer nicht- serialisierbaren Historie, aber nicht (immer) Deadlocks wartet auf T1 X(a) X(c) WfG T 1 T2 R(c) R(b) T 2 T 3 T3 X(b) R(a) Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 52
Logging und Recovery Aufgabe des DBMS: Automa0sche Behandlung aller erwarteten Fehler Was sind erwartete Fehler? DB- Opera0on wird zurückgewiesen, Commit wird nicht akzep0ert,... Stromausfall, DBMS- Probleme,... Geräte funk0onieren nicht (Spur, Zylinder, Plaze defekt) Vorausgesetzt wird (für das Fehlermodell) korrektes Verhalten von DBMS, Gerätesteuerung, Korrektur von Lesefehlern Fehlermodell von zentralisierten DBMS Transak0onsfehler (z. B. Deadlock) Transak0ons- Recovery Systemfehler (Verlust aller HSP- Inhalte) Crash- Recovery Gerätefehler Medien- Recovery Katastrophen Katastrophen- Recovery Erhaltung der physischen Datenintegrität Periodisches Erstellen von Datenkopien Führen von Änderungsprotokollen für den Fehlerfall (Logging) Bereitstellen von Wiederherstellungsalgorithmen im Fehlerfall (Recovery) Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 53
Was passiert bei einem Crash? T1 ändert R1 und fügt R2 ein T2 liest die gesamte Tabelle S Tabellen mit mengenorientierten Operationen R S Datensystem satzorientierte Operationen DB-Puffer P1 R1 R2 Rn S1 S2 Sm R1 S2 P17 Zugriffssystem Rn P7 Speichersystem S1 R2 P2 P3 Externspeicher P1 P7 P2 P17 P3 Geändert: P1, P3, P17, davon P1, P17 schon auf Plaze geschrieben Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 54
Logging und Recovery (2) Logging Sammeln von Redundanz im Normalbetrieb zur Fehlerbehebung Verschiedene Verfahren für Logging (logisch, physisch, physiologisch) DBMS garan0ert physische Datenintegrität Bei jedem Fehler (z. B. Ausfall des Rechners, Crash des Betriebssystems oder des DBMS, Fehlerhacigkeit einzelner Transak0onsprogramme) wird eine korrekte Datenbank rekonstruiert Nach einem (Teil- )Crash ist immer der jüngste transak0onskonsistente Zustand der DB zu rekonstruieren, in dem alle Änderungen von Transak0onen enthalten sind, die vor dem Zeitpunkt des Fehlers erfolgreich beendet waren und sonst keine automa0sche Wiederherstellung bei Restart (Wiederanlauf) des Systems Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 55
Logging und Recovery (3) Hauptspeicher transient A T 1 T 5 A' B B' Crash T 2 T 4 T 6 C C' T 3 T 7 nicht-atomares A B C Einbringen von Seiten A B' C' materialisierte DB Externspeicher permanent Maßnahmen beim Wiederanlauf (siehe auch Beispiel) Ermizlung der beim Crash ak0ven Transak0onen (T 5, T 6, T 7 ) Wiederholen (REDO) der Änderungen von abgeschlossenen Transak0onen, die vor dem Crash nicht in die Datenbank zurückgeschrieben waren (A A') Rücksetzen (UNDO) der Änderungen der ak0ven Transak0onen in der Datenbank (B' B) Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 56
Schnizstelle zwischen AP und DBS transak0onsbezogene Aspekte Aktionen auf Seite des AP Aktionen auf Seite des DBS BOT... Op i... EOT Befehle Sicherstellen der Rücksetzbarkeit von Änderungsoperationen Ausführen von DML-Befehlen (Überprüfen der unverzögerten Integritätsbedingungen) (Überprüfen der verzögerten Integritätsbedingungen) C O Phase 1 Sicherstellen der Wiederholbarkeit aller Änderungen 2PC M M I Phase 2 Freigabe der Betriebsmittel (Sperren) T Weiterarbeit im AP Bestätigung über erfolgreiches Ende an das AP Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 57
Verarbeitung in Verteilten Systemen Ein verteiltes System besteht aus autonomen Subsystemen, die koordiniert zusammenarbeiten, um eine gemeinsame Aufgabe zu erfüllen Client/Server- Systeme Mehrrechner- DBS,... Beispiel: The Coordinated Azack Problem red general attack at dawn blue general Generals-Paradoxon Grundproblem verteilter Systeme: Mangel an globalem (zentralisiertem) Wissen symmetrische Kontrollalgorithmen sind oc zu teuer/ineffek0v fallweise Zuordnung der Kontrolle Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 58
Verarbeitung in Verteilten Systemen (2) Erweitertes Transak0onsmodell verteilte Transak0onsbearbeitung (Primär-, Teiltransak0onen) zentralisierte Steuerung des Commit- Protokolls 1 Koordinator C N Teiltransaktionen (Agenten) A 1 A 2... A N rechnerübergreifendes Mehrphasen- Commit- Protokoll notwendig, um Atomarität einer globalen Transak)on sicherzustellen Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 59
Verarbeitung in Verteilten Systemen (2) Anforderungen an geeignetes Commit- Protokoll: Geringer Aufwand (#Nachrichten, #Log- Ausgaben) Minimale Antwortzeitverlängerung (Nutzung von Parallelität) Robustheit gegenüber Rechnerausfällen und Kommunika0onsfehlern Zentralisiertes Zweiphasen- Commit- Protokoll stellt geeignete Lösung dar Erwartete Fehlersitua0onen Transak0onsfehler Systemfehler (Crash) - i. allg. par0elle Fehler (Rechner, Verbindungen,...) Gerätefehler Fehlererkennung z. B. über Timeout Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 60
Zentralisiertes Zweiphasen- Commit Zustandsübergang Nachricht Zustandsübergang Phase 1 (Voting) C Initial A i Wait * Begin PREPARE READY / FAILED * Prepared/ Aborted Phase 2 (Decision) * Committing/ Aborting End COMMIT / ABORT ACK * Committed/ Aborted * Synchrone Log-Ausgabe (log record is force-written) End ist wichtig für Garbage Collection im Log von C Protokoll (Basic 2PC) Folge von Zustandsänderungen für Koordinator und für Agenten - Protokollzustand auch nach Crash eindeu0g: synchrones Logging - Sobald C ein NO VOTE (FAILED) erhält, entscheidet er ABORT - Sobald C die ACK- Nachricht von allen Agenten bekommen hat, weiß er, dass alle Agenten den Ausgang der TA kennen C kann diese TA vergessen, d. h. ihre Log- Einträge im Log löschen! Warum ist das 2PC- Protokoll blockierend? Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 61
Commit: Kostenbetrachtungen Vollständiges 2PC- Protokoll (N = #Teil- TA, davon M = #Leser) Nachrichten: 4N Log- Ausgaben (forced log writes): 2 + 2N Antwortzeit: längste Runde in Phase 1 (kri0sch, weil Betriebsmizel blockiert) + längste Runde in Phase 2 Aufwand bei spezieller Op0mierung für Leser: Lesende Teil- TA nehmen nur an Phase 1 teil, dann Freigabe der Sperren Nachrichten: 4N 2M Log- Ausgaben: 2 + 2N 2M für N > M Lässt sich das zentralisierte 2PC- Protokoll weiter op0mieren? Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 62
Zusammenfassung Transak0onsparadigma Verarbeitungsklammer für die Einhaltung der Constraints des DB- Schemas Verdeckung der Nebenläufigkeit (concurrency isola0on) Synchronisa0on Verdeckung von (erwarteten) Fehlerfällen (failure isola0on) Logging und Recovery Erhaltung der seman0schen Datenintegrität Beschreibung der Rich0gkeit von Daten durch Prädikate und Regeln Unterscheide: Transak0onskonsistenz, Opera0onskonsistenz, Ak0onskonsistenz, Gerätekonsistenz Beim ungeschützten und konkurrierenden Zugriff von Lesern und Schreibern auf gemeinsame Daten können Anomalien aucreten Theorie der Serialisierbarkeit Konfliktopera0onen: Kri0sch sind Opera0onen verschiedener Transak0onen auf denselben DB- Daten, wenn diese Opera0onen nicht reihenfolgeunabhängig sind! Serialisierbarkeitstheorem: Eine Historie H ist genau dann serialisierbar, wenn der zugehörige Konfliktgraph G(H) azyklisch ist Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 63
Zusammenfassung (2) Serialisierbare Abläufe gewährleisten automa0sch Korrektheit des Mehrbenutzerbetriebs erzwingen u. U. lange Blockierungszeiten paralleler Transak0onen Realisierung der Synchronisa0on durch Sperrverfahren Sperren stellen während des laufenden Betriebs sicher, dass die resul0erende Historie serialisierbar bleibt Bei einer Konfliktopera0on blockieren sie den Zugriff auf das Objekt (Deadlock- Problem ist inhärent) Basis- Protokoll: 2PL Sperrverfahren sind pessimis0sch und universell einsetzbar Logging- und Recovery- Verfahren automa0sche Behandlung für erwartete Fehler Fehlerarten: Transak0ons-, System-, Gerätefehler und Katastrophen Zweiphasen- Commit- Protokolle (2PC) Hoher Aufwand an Kommunika0on und E/A Op0mierungsmöglichkeiten sind zu nutzen Maßnahmen erforderlich, um Blockierungen zu vermeiden! Kri0sche Stelle: Ausfall von C Informa0onssysteme 2015 Kapitel 8: Grundlagen des Transak0onskonzepts 64