8. Transaktionsverarbeitung. Architektur von Datenbanksystemen I

Transkript

1 8. Transaktionsverarbeitung Architektur von Datenbanksystemen I

2 Einordnung ARCHITEKTUR VON DATENBANKSYSTEMEM I - Key/Value Store - Row Store - Column Store - Data Compression - Transaction Processing - CAP Theorem Transaction Service Storage Service Durability Service - Logging - Recovery 2

3 Prinzip transaktionaler Verarbeitung TRANSAKTIONEN Zusammenfassung von aufeinanderfolgenden DB-Operationen, die eine Datenbank von einem konsistenten Zustand wieder in einen konsistenten Zustand überführt. MERKE das Ende einer Transaktion muss nicht notwendigerweise in einem anderen konsistenten Zustand enden Transaktionen werden immer beendet - normal (commit): Änderungen sind permanent in DB - abnormal (abort / rollback): bereits durchgeführte Änderungen werden zurückgenommen 3

4 ACID-Eigenschaften ATOMARITÄT (ATOMICITY) Unteilbarkeit durch Transaktionsdefinition (Begin End) Alles-oder-Nichts Prinzip, d.h. das DBS garantiert - entweder die vollständige Ausführung einer Transaktion - oder die Wirkungslosigkeit der gesamten Transaktion (und damit aller beteiligten Operationen) KONSISTENZERHALTUNG (CONSISTENCY) Eine erfolgreiche Transaktion garantiert, dass alle Konsistenzbedingungen (Integritätsbedingungen) eingehalten worden sind ISOLATION (ISOLATION) Mehrere Transaktionen laufen voneinander isoliert ab und benutzen keine (inkonsistenten) Zwischenergebnisse anderer Transaktionen DAUERHAFTIGKEIT (DURABILITY) Alle Ergebnisse erfolgreicher Transaktionen müssen persistent gemacht werden (worden sein) 4

5 Anmerkungen zur Konsistenz in DBS BEISPIEL vorgegebene Konsistenzbedingung: x=y BOT // DB ist konsistent read(x) read(y) x := x+1 write(x) // DB ist zeitweilig inkonsistent y := y+1 write(y) EOT // DB ist wieder konsistent ARTEN VON KONSISTENZ Datenbankkonsistenz - alle (auf der DB definierten) Konsistenzbedingungen sind erfüllt Transaktionskonsistenz - der nebenläufige Ablauf der Transaktionen ist korrekt - Gefahr der Anomalien 5

6 Gefährdung der Datenbankkonsistenz UNTERSCHIEDLICHE SICHTWEISEN Korrektheit der Abbildungshierarchie Übereinstimmung zwischen DB und Miniwelt durch das Anwendungsprogramm durch das DBS und die Betriebsumgebung Mehrbenutzer-Anomalien Synchronisation Fehler auf den Externspeichern, Inkonsistenzen in den Zugriffspfaden Fehlertolerante Implementierung unzulässige Änderungen Integritätsüberwachung des DBS TA-orientierte Verarbeitung Undefinierter DB-Zustand nach einem Systemausfall Transaktionsorientierte Fehlerbehandlung (Recovery) 6

7 Synchronisation 7

8 Synchronisation ZIEL Erhaltung der Transaktionskonsistenz (= operationelle Integrität) im Mehrbenutzerbetrieb GRÜNDE FÜR DEN MEHRBENUTZERBETRIEB Verteilung generell (z.b. EC-Automat) CPU-Nutzung während systemgetriebenen und benutzergetriebenen TA-Unterbrechungen Kommunikationsvorgänge in verteilten Systemen MÖGLICHE ANOMALIEN OHNE SYNCHRONISATION Verlorengegangene Änderungen (lost update) Abhängigkeiten von nicht freigegebenen Änderungen (dirty read, dirty overwrite) Inkonsistente Analyse (non-repeatable read) Phantom-Problem GEGENSTAND DER SYNCHRONISATION Vermeidung der gegenseitigen Beeinflussung von Lese- und Schreiboperationen Verhinderung von Anomalien im Mehrbenutzerbetrieb 8

9 Anomalien BEISPIEL FÜR LOST UPDATES BESCHREIBUNG Konkurrierendes Verändern eines Datenelementes 9

10 Anomalien (2) BEISPIEL FÜR DIRTY READ BESCHREIBUNG Abhängigkeiten von nicht freigegebenen Änderungen (rekursives Zurücksetzen) 10

11 Anomalien (3) BEISPIEL FÜR NON-REPEATABLE READ BESCHREIBUNG Während der Verarbeitung von T 2 wird der Datenbestand durch T 1 verändert T 2 sieht konsistente Zustände, jedoch unterschiedliche! 11

12 Anomalien (4) Phantom Problem Lesetransaktion (Gehaltssumme prüfen) Änderungstransaktion (Einfügen eines neuen Angestellten) SELECT SUM(Gehalt) INTO :summe FROM pers WHERE anr=17 SELECT Gehaltssumme INTO :gsumme FROM abt WHERE anr=17 IF gsumme <> summe THEN <Fehlerbehandlung> INSERT INTO Pers(pnr, anr, gehalt) VALUES (4567, 17, ) UPDATE Abt SET gehaltssumme = gehaltssumme WHERE anr=17 Interpretation: dirty read auf höherer Ebene (relationenübergreifend!) 12

13 Modell und Serialisierbarkeit DAS READ/WRITE-MODELL Transaktion T ist eine endliche Folge von Operationen (Schritten) p i der Form r(x i ) oder w(x i ) T = DEFINITION Eine verschränkte Ausführung mehrerer Transaktionen heißt serialisierbar, wenn ihr Effekt zum Effekt einer (beliebig gewählten) seriellen Ausführung dieser Transaktionen ist. Vollständige Transaktion T hat als letzten Schritt entweder einen Abbruch a oder ein Commit c: SCHEDULER 13

14 Verschränkte Ausführung SHUFFLE(T ) Menge aller verschränkten Ausführungen der Einzelschritte aller in der Menge T enthaltenen Transaktionen T i alle Operationen der Transaktionen T i sind genau einmal in jedem Element enthalten BEISPIEL T1 = r1(x) w1(x) T2 = r2(x) r2(y) w2(y) Shuffle (T ) = Relative Reihenfolge der Operationen einer Transaktion wird beibehalten 14

15 Schedule und Serieller Schedule SCHEDULE Ein Schedule ist ein Präfix eines vollständigen Schedules. SERIELLER SCHEDULE Ein serieller Schedule s für T ist ein vollständiger Schedule der Form Resultierender serieller Schedule für zwei Transaktionen T1 = r1(x)w1(x)c1 T2 = r2(x)w2(x)c2 s1 = s2 = 15

16 Korrektheitskriterium & Konflikte KORREKT Eine Schedule s ist korrekt, wenn der Effekt des Schedules s (Ergebnis der Ausführung) äquivalent dem Effekt eines (beliebigen) seriellen Schedules s bzgl. derselben Mengen von Transaktionen ist KONFLIKTE SERIALISIERBAR Ist ein Schedule s äquivalent zu einem seriellen Schedule s, dann ist s serialisierbar (zu s ). 16

17 Konfliktserialisierbarkeit KONFLIKTRELATION C VON S : BEREINIGTE KONFLIKTRELATION Mit conf(s) wird bereinigte Konfliktrelation bezeichnet, in der keine abgebrochenen Transaktionen mehr vorkommen KONFLIKTMATRIX aborted(s): Menge der abgebrochenen Transaktionen des Schedules s 17

18 Beispiel Konfliktrelation GEGEBEN: SCHEDULE S 18

19 Konfliktserialisierbarkeit KONFLIKTÄQUIVALENZ Zwei Schedules s und s heißen konfliktäquivalent falls - op(s) = op(s ) - conf(s) = conf(s ) KONFLIKTSERIALISIERBARKEIT Ein Schedule s ist genau dann konfliktserialisierbar, wenn s konfliktäquivalent zu einem seriellen Schedule ist. Klasse aller konfliktserialisierbaren Schedules: CSR (für engl. conflict serializable) BEISPIEL 19

20 Konfliktserialisierbarkeit TEST Auf Konfliktserialisierbarkeit durch Vergleich mit den seriellen Schedules GEGEBEN: Schedule s 20

21 Graphbasierter Test KONFLIKTGRAPH G(s) = (V,E) von Schedule s BEISPIEL Schedule s Knotenmenge V enthält alle in s vorkommenden Transaktionen Kantenmenge E enthält alle gerichteten Kanten zwischen zwei in Konflikt stehenden Transaktionen, also: 21

22 Eigenschaften EIGENSCHAFTEN VON KONFLIKTGRAPH G(S) Ist s ein serieller Schedule, dann ist der vorliegende Konfliktgraph ein azyklischer Graph KONFLIKTGRAPHEN UND SERIALISIERBARKEIT Für jeden Schedule s gilt: Für jeden azyklischen Graphen G(s) lässt sich ein serieller Schedule s konstruieren, sodass s konfliktserialisierbar zu s ist (Test bzw. durch topologisches Sortieren) Enthält ein Graph Zyklen, dann ist der zugehörige Schedule nicht konfliktserialisierbar 22

23 Probleme zur Laufzeit PROBLEME Zur Laufzeit nur unvollständige Schedule verfügbar à Überwachung unvollständiger Schedules notwendig DER SCHEDULER Transaktionen, die noch kein commit gemacht haben, können jederzeit abgebrochen werden. 23

24 Zustände einer Transaktion 24

25 Arten von Scheduler AGGRESSIVER SCHEDULER ein Scheduler ist aggressiv, wenn er Konflikte zulässt und dann versucht, aufgetretene Konflikte zu erkennen und aufzulösen KONSERVATIVER SCHEDULER ein Scheduler arbeitet konservativ, wenn er Konflikte möglichst vermeidet, dafür aber Verzögerungen von Transaktionen in Kauf nimmt maximiert die Parallelität von Transaktionen Risiko: Transaktionen werden erst am Ende ihrer Ausführung zurückgesetzt erlauben nur eine geringe Parallelität von Transaktionen minimieren den Rücksetzungsaufwand für abgebrochene Transaktionen im Extremfall findet keine Parallelisierung von Transaktionen mehr statt, d.h., es werden immer alle Transaktionen bis auf eine verzögert 25

26 Synchronisation durch Sperren 26

27 PESSIMISTISCHE SYNCHRONISATIONSVERFAHREN REALISIERUNG EINES LOGISCHEN EINBENUTZERBETRIEBS Einführung von Sperren für exklusiven Zugriff auf Datenobjekte für jedes benutzte Datenobjekt wird zentral in einer Sperrtabelle die Nutzungsart (Sperrmodus) protokolliert ARTEN VON SPERREN X (exclusive)-sperre (=Schreibsperre) S/R (shared/read)-sperre (=Lesesperre) KOMPATIBILITÄTSMATRIX gibt Auskunft, ob eine Sperranforderung für ein (möglicherweise bereits gesperrtes) Objekt gewährt werden kann 27

28 Synchronisation mit Sperren WANN SIND SPERREN ZU ERWERBEN? Statisches Sperren - zu Beginn der Transaktion alle Sperren anfordern ( preclaiming ) - Nachteil: Man muss alles sperren, was man brauchen könnte. Dynamisches Sperren - während der Transaktion werden Sperren nach Bedarf angefordert - Nachteil: Verklemmungen (deadlocks) WANN SIND SPERREN FREIZUGEBEN? Sperren müssen bis zum Ende der Transaktion gehalten werden, um Serialisierbarkeit zu garantieren Abschwächung zur Optimierung - frühzeitiges Freigeben z.b. von Lesesperren - Nachteil: wiederholtes Lesen desselben Satzes kann dann unterschiedliche Ergebnisse liefern REGELN FÜR DEN UMGANG MIT SPERREN Jedes Datenobjekt, auf das zugegriffen werden soll, muss vorher gesperrt werden Eine Transaktion fordert eine Sperre, die sie bereits besitzt, nicht noch einmal an Eine Transaktion muss die von anderen Transaktionen gesetzten Sperren beachten Am Ende einer Transaktion sind alle Sperren wieder freizugeben (Eswaran, Gray, Lorie und Traiger 1976) 28

29 Zweiphasen-Sperrprotokoll ZWEIPHASIGKEIT Anfordern von Sperren erfolgt in einer Wachstumsphase Freigabe der Sperren in Schrumpfungsphase Sperrfreigabe kann erst beginnen, wenn alle Sperren gehalten werden MIKROSKOPISCHE SICHTWEISE AUF DAS FREIGEBEN VON SPERREN 29

30 Verschärfung des Zweiphasen-Sperrprotokolls MERKE bei fehlerfreiem Betrieb ist diese Voraussetzung (fast) ausreichend, um einen korrekten Transaktionsablauf zu gewährleisten Problem des kaskadierenden Abbruchs einer Transaktion - Rücksetzen von TAs, die bereits freigegebene Daten gelesen haben - Rücksetzen von TAs, die bereits selbst schon committed sind! FREIGABE ALLER SPERREN ERST AM ENDE EINER TRANSAKTION Striktes Zweiphasen-Sperrprotokoll Profil der Sperranforderungen und Sperrfreigaben PROBLEM: FREIGABE ALLER SPERREN IST NICHT ATOMAR DURCHFÜHRBAR Einführung einer zweiphasigen Commit-Behandlung Phase 1: Sichern der isolierten Wiederholbarkeit und Schreiben des EOT-Satzes Phase 2: Freigabe aller Sperren und Beenden der Aktivität 30

31 Entstehung und Behandlung von Deadlocks BEISPIEL EINES ELEMENTAREN DEADLOCKS Transaktion T1 T1 hält X-Sperre auf A T1 benötigt B zum beenden Transaktion T2 T2 hält X-Sperre auf B T2 benötigt A zum beenden VORAUSSETZUNGEN FÜR DEADLOCK paralleler Zugriff exklusive Zugriffsanforderungen (X-Sperren) anfordernde TA besitzt bereits Sperren auf Datenobjekte keine vorzeitige Freigabe von Sperren auf Datenobjekte (non-preemption) es existieren zyklische Wartebeziehungen zwischen zwei oder mehr Transaktionen 31

32 Deadlock Lösungsmöglichkeiten TIMEOUT-VERFAHREN Transaktion wird nach festgelegter Wartezeit auf eine Sperre zurückgesetzt problematische Bestimmung des Timeout-Wertes DEADLOCK-VERHÜTUNG (PREVENTION) keine Laufzeitunterstützung zur Deadlock-Behandlung erforderlich Bsp.: Preclaiming (in DBS i. a. nicht praktikabel) DEADLOCK-VERMEIDUNG (AVOIDANCE) potentielle Deadlocks werden im voraus erkannt und durch entsprechende Maßnahmen vermieden à Laufzeitunterstützung nötig DEADLOCK-ERKENNUNG (DETECTION) Explizites Führen eines Wartegraphen (wait-for graph) und Zyklensuche zur Erkennung von Verklemmungen Deadlock-Auflösung durch Zurücksetzen einer oder mehrerer am Zyklus beteiligter TA (z. B. Verursacher oder billigste TA zurücksetzen) 32