DML
Werbung
Anwendersoftware (AS) Grundlagen von Datenbanken und Informationssystemen Kapitel p 9: Transaktionsverwaltung Bernhard Mitschang Wintersemester 2008/09 Teile zu diesem Folienskript beruhen auf einer ähnlichen Vorlesung, gehalten von Prof. Dr. T. Härder am Fachbereich Informatik der Universität Kaiserslautern und Prof. Dr. N. Ritter am Fachbereich Informatik der Universität Hamburg. Für dieses Skriptum verbleiben alle Rechte (insbesondere für Nachdruck) bei den Autoren. Transaktionsverwaltung Übersicht • • • • Transaktionskonzept p DB-Recovery: Wiederherstellung im Fehlerfall Synchronisation TA-Verwaltung in verteilten Systemen © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 2 Transaktionsverwaltung Gefährdung der DB-Konsistenz DB Konsistenz Gefährdung der DBKonsistenz durch … … das Anwendungsprogramm … das DBMS und die Betriebsumgebung Korrektheit der Abbildungshierarchie Übereinstimmung zwischen DB und Miniwelt Mehrbenutzer-Anomalien unzulässige g Änderungen g ¾Synchronisation Sy c o sat o (Concurrency Control) ¾Integritätsüberwachung teg tätsübe ac u g des DBMS ¾TA-orientierte Verarbeitung Fehler auf den Externspeichern, Inkonsistenzen in den Zugriffspfaden undefinierter DB DB-Zustand Zustand nach einem Systemausfall ¾Fehlertolerante Implementierung ¾Archivkopien (Backup) ¾Transaktionsorientierte Fehlerbehandlung (Recovery) © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 3 Transaktionsverwaltung Klassische Transaktionsverarbeitung UPDATE accounts SET balance = balance - 1000€ WHERE K# = 03874; UPDATE accounts SET balance = balance + 1000€ WHERE K# = 01099 01099; TransakttionsProgram mme Transaktionssystem EOT © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart Karte ? PIN ? Konto ? Buchung Ausgabe Datenbanksystem # Kontostand 01099 038 874 BOT 900 -100 1500 2500 OK 4 Transaktionsverwaltung Ablaufkontrollstruktur: Transaktion (TA) • Eine Transaktion ist eine ununterbrechbare Folge g von DML-Befehlen,, die die Datenbank von einem logisch konsistenten in einen (neuen) logisch konsistenten Zustand überführt. • Beispiel eines TA-Programms: BOT UPDATE Konto ... UPDATE Schalter ... UPDATE Zweigstelle ... INSERT INTO Ablage (...) EOT © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 5 Transaktionsverwaltung ACID-Eigenschaften ACID Eigenschaften von Transaktionen • Atomicity y ((Atomarität)) TA ist kleinste, nicht mehr weiter zerlegbare Einheit Entweder werden alle Änderungen der TA festgeschrieben oder gar keine ((„alles-oder-nichts“-Prinzip) alles oder nichts“ Prinzip) • Consistency TA hinterlässt einen konsistenten DB-Zustand, DB Zustand, sonst wird sie komplett (siehe Atomarität) zurückgesetzt Endzustand muss alle definierten Integritätsbedingungen erfüllen Zwischenzustände h d während h d der d TA-Bearbeitung b dürfen d f inkonsistent k sein © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 6 Transaktionsverwaltung ACID-Eigenschaften ACID Eigenschaften von Transaktionen • Isolation Nebenläufig (parallel, gleichzeitig) ausgeführte TA dürfen sich nicht gegenseitig beeinflussen Parallele TA bzw. bzw deren Effekte sind nicht sichtbar (logischer Einbenutzerbetrieb) • Durability (Dauerhaftigkeit) g Wirkung erfolgreich abgeschlossener TA bleibt dauerhaft in der DB TA-Verwaltung muss sicherstellen, das dies auch nach einem Systemfehler (HW (HW- oder System System-SW) SW) gewährleistet ist Wirkung einer erfolgreich abgeschlossenen TA kann nur durch eine sog. kompensierende TA aufgehoben werden © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 7 Transaktionsverwaltung Schnittstelle zwischen Anwendungsprogramm (AP) und DBS START TRANSACTION Kennzeichnet Beginn einer Transaktion (BOT) nach SQL-Standard auch implizit möglich COMMIT [WORK] Kennzeichnet Ende einer Transaktion (EOT) Änderungen der Transaktion werden festgeschrieben ROLLBACK [WORK] [ ] Selbstabbruch der Transaktion (Abort) © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart SAVEPOINT <name> Definiert einen Sicherungspunkt innerhalb der Transaktion ROLLBACK [WORK] TO SAVEPOINT <name> Setzt S t t di die aktive kti T Transaktion kti auff einen Sicherungspunkt zurück 8 Transaktionsverwaltung Mögliche Ausgänge einer Transaktion BOT BOT BOT DML1 DML1 DML1 DML2 DML2 DML2 DML3 DML3 DML3 • • • • • • DMLn DMLn COMMIT ROLLBACK normales Ende abnormales Ende © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart Systemausfall, Programmfehler, usw. erzwungenes ROLLBACK erzwungenes abnormales Ende 9 Transaktionsverwaltung Schnittstelle zwischen Anwendungsprogramm (AP) und DBS Aktionen auf Seite des AP BOT • • • Opi Aktionen auf Seite des DBS Sicherstellen der Rücksetzbarkeit von Änderungsoperationen Befehle Ausführen von DML-Befehlen • • • ((Überprüfen p der unverzögerten g Integritätsbedingungen) Commit (Überprüfen der verzögerten Integritätsbedingungen) Phase 1 Phase 2 Sicherstellen der Wiederholbarkeit aller Änderungen Freigabe der Betriebsmittel (Sperren) 2PC Bestätigung über erfolgreiches Ende an das AP © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 10 Transaktionsverwaltung TA Verwaltung TA-Verwaltung • Wesentliche Abstraktionen ((aus Sicht der DB-Anwendung) g) zur Gewährleistung einer ‚fehlerfreien Sicht‘ auf die Datenbank im logischen Einbenutzerbetrieb Failure Transparency Alle Auswirkungen auftretender Fehler bleiben der Anwendung verborgen Concurrency Transparency Es sind keine anwendungsseitigen Vorkehrungen zu treffen, um Effekte der Nebenläufigkeit beim DB-Zugriff auszuschließen © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 11 Transaktionsverwaltung TA Verwaltung TA-Verwaltung • TA-Verwaltung g koordiniert alle DBS-seitigen Maßnahmen, um ACID zu garantieren besitzt zwei wesentliche Komponenten - Synchronisation S h i i - Logging und Recovery kann a zentralisiert e a s e ode oder verteilt e e ((z.B. be bei VDBS) S) realisiert ea s e se sein soll Transaktionsschutz für heterogene Komponenten bieten © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 12 Transaktionsverwaltung Abstraktes Architekturmodell • T1 T2 ... T Tn Verteilung der DB-Operationen in VDBS und Weiterreichen an den Scheduler zeitweise Deaktivierung k von TA (b (bei Überlast) Koordination der Abort- und CommitBehandlung Transaktionsmanager Scheduler Speichersystem RecoveryKomponente DB-Pufferverwaltung Transaktionsmanager • Scheduler (Synchronisation) kontrolliert die Abwicklung der um DB Daten konkurrierenden TA DB-Daten • Recovery-Komponente sorgt für die Rücksetzbarkeit/ Wiederholbarkeit der Effekte von TA DB • DB-Pufferverwalter stellt DB-Seiten bereit und gewährleistet persistente Seitenänderungen © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 13 Transaktionsverwaltung Übersicht • • • • Transaktionskonzept p DB-Recovery: Wiederherstellung im Fehlerfall Synchronisation TA-Verwaltung in verteilten Systemen © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 14 Transaktionsverwaltung DB-Recovery DB Recovery • Automatische Behandlung aller ‚erwarteten‘ Fehler durch das DBMS • Erwartete Fehler DB-Operation wird zurückgewiesen Commit wird nicht akzeptiert Stromausfall Geräte funktionieren nicht (Spur, Zylinder, Platte defekt) ... • Voraussetzung Log-Datei Log Datei Sammeln redundanter AP1 AP2 APn … Information während des normalen Betriebs (Protokolldatei, Logging) DBMS © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart permanente Datenbank 15 Transaktionsverwaltung DB Recovery DB-Recovery • Fehlermodell von zentralisierten DBMS Transaktionsfehler Systemfehler Gerätefehler • Probleme Fehlererkennung Fehlereingrenzung Abschätzung des Schadens Durchführung der Recovery „A recoverable action is 30% harder and requires 20% more code than a non-recoverable action“ (J. Gray) © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 16 Transaktionsverwaltung Zielzustand nach Recovery • Transaktionsparadigma p g verlangt g Alles-oder-Nichts-Eigenschaft von Transaktionen Dauerhaftigkeit erfolgreicher Änderungen • Zielzustand nach erfolgreicher Recovery jüngster transaktionskonsistenter DB-Zustand Durch die Recovery-Aktionen ist der jüngste Zustand vor Erkennen des F hl Fehlers wiederherzustellen, i d h t ll der allen semantischen Integritätsbedingungen entspricht, der also ein möglichst aktuelles, exaktes Bild der Miniwelt darstellt © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 17 Transaktionsverwaltung Recovery Arten Recovery-Arten 1. Transaktions-Recovery (R1) Zurücksetzen einzelner (noch nicht abgeschlossener) Transaktionen im laufenden Betrieb (Transaktionsfehler Deadlock) (Transaktionsfehler, Arten - Vollständiges Zurücksetzen auf Transaktionsbeginn g (TA-UNDO) ( ) Partielles Zurücksetzen auf Rücksetzpunkt (Savepoint) innerhalb der Transaktion 2 Crash 2. Crash-Recovery Recovery (R2) nach Systemfehler Wiederherstellen des jüngsten transaktionskonsistenten DBZustands Notwendige Aktionen - (partielles) REDO für erfolgreiche Transaktionen (Wiederholung verloren gegangener Änderungen) Ä © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart - UNDO aller durch Ausfall unterbrochenen Transaktionen (Entfernen der Änderungen aus der permanenten DB) 3. Medien-Recovery (R3) nach Gerätefehler Spiegelplatten bzw. Vollständiges Wiederholen (REDO) aller Änderungen (erfolgreich abgeschlossener Transaktionen) auf einer Archivkopie 4. Katastrophen-Recovery (R4) Nutzung N t einer i aktuellen kt ll DB-Kopie DB K i in i einem ‚entfernten‘ System oder Stark verzögerte Fortsetzung der DBVerarbeitung mit repariertem/neuem System auf der Basis gesicherter Archivkopien (Datenverlust) 18 Transaktionsverwaltung Transaktions Recovery Transaktions-Recovery • A -> A' C -> C' ROLLBACK T1 D -> D' T2 A -> A'' E -> E' ROLLBACK Log-Inhalt Log Inhalt LSN Satz • ROLLBACK T1 UNDO LSN UNDO LSN ROLLBACK T2 UNDO LSN UNDO LSN UNDO LSN 2: A' → A 4: C' → C 5: D' → D 7: A' → A 8 8: E' → E … 1 T1, BOT 2 T1, A→ A' 3 T2 BOT T2, 4 T1, C → C' 5 T2, D → D' 6 T1, ROLLBACK 7 T2, A → A' 8 T2 E → E' T2, 9 T2, ROLLBACK © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 19 Transaktionsverwaltung Crash Recovery Crash-Recovery S t Systemfehler f hl A -> A' • ROLLBACK T1 E -> E' T2 C -> C' T3 A -> A'' • D -> D' T4 Log-Inhalt LSN Satz … DB-Inhalt Seite LSN A 5 20 T3, BOT B 15 30 T1, A→ A' C 10 40 T4, D → D' D' 40 50 T4, COMMIT E' 90 60 T3, C → C' 70 T1, ROLLBACK 80 T3, A → A' 90 T2, E → E' 100 T3, COMMIT © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart • Analyselauf: abgebrochene Transaktionen: T1, T2 erfolgreiche Transaktionen: T3, T4 UNDO: LSN 90: E E' → E LSN 30: nicht notwendig, da Seite A noch nicht geändert REDO REDO: LSN 40: nicht notwendig, da Seite D bereits geändert LSN 60: C → C' LSN 80: A → A' 20 Transaktionsverwaltung Übersicht • • • • Transaktionskonzept p DB-Recovery: Wiederherstellung im Fehlerfall Synchronisation TA-Verwaltung in verteilten Systemen © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 21 Transaktionsverwaltung Synchronisation • Einbenutzer-/Mehrbenutzerbetrieb t Einbenutzerbetrieb ... T1 ... T2 ... ... T3 Mehrbenutzerbetrieb ... ... T1 T2 T3 • CPU-Nutzung während TA-Unterbrechungen: E/A Denkzeiten D k i bei b i Mehrschritt-TA M h h i TA Kommunikationsvorgänge in verteilten Systemen ¾ be bei langen a ge TA zu u große g oße Wartezeiten a te e te für ü a andere de e TA (Sc (Schedulingedu g Fairneß) © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 22 Transaktionsverwaltung Anomalien • Anomalien im Mehrbenutzerbetrieb ohne Synchronisation y 1. Abhängigkeiten von nicht freigegebenen Änderungen (dirty read, dirty overwrite) 2 Verlorengegangene Änderungen (lost update) 2. 3. Inkonsistente Analyse (non-repeatable read) 4. Phantom Phantom-Problem Problem ¾ nur durch Änderungs-TA verursacht © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 23 Transaktionsverwaltung Dirty Read • Abhängigkeit gg von nicht-freigegebenen g g Änderungen g (Dirty ( y Read)) „schmutzig“ Daten (dirty data): - Geänderte, aber noch nicht freigegebene Daten - die TA kann ihre Änderungen bis Commit (einseitig) zurücknehmen T1 T2 Read (A); A := A + 100; Write ((A); ); Schmutzige Daten dürfen von anderen TAs nicht benutzt werden Read (A); Read (B); B := B + A; Write (B); Commit; Rollback; Zeit © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 24 Transaktionsverwaltung Lost Update • Verlorengegangene g g g Änderung g (Lost Update) ist in jedem Fall auszuschließen T1 T2 Read (A); Read (A); A := A - 1;; Write (A); A := A + 1; te ((A); ); Write Zeit © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 25 Transaktionsverwaltung Inkonsistente Analyse (Non-repeatable Read) Lesetransaktion (Gehaltssumme berechnen) Änderungstransaktion 2345 39.000 39 000 3456 48.000 UPDATE Pers SET Gehalt = Gehalt + 1000 WHERE Pnr = 2345; 2345 40.000 UPDATE Pers SET Gehalt G h l = Gehalt G h l + 2000 WHERE Pnr = 3456; 3456 50.000 SELECT Gehalt INTO :gehalt FROM Pers WHERE Pnr = 2345; summe := summe + gehalt; SELECT Gehalt INTO :gehalt FROM Pers WHERE Pnr = 3456; summe := summe + gehalt; © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart DB-Inhalt (Pnr, Gehalt) Zeit 26 Transaktionsverwaltung Phantom Problem Phantom-Problem Lesetransaktion Änderungstransaktion (Gehaltssumme überprüfen) (Einfügen eines neuen Angestellten) SELECT SUM (Gehalt) INTO :summe FROM Pers WHERE Anr = 17; INSERT INTO Pers ((Pnr, Anr, Gehalt)) VALUES (4567, 17, 55.000); UPDATE Abt SET Gehaltssumme = Gehaltssumme + 55.000 WHERE Anr = 17; SELECT Gehaltssumme INTO :gsumme FROM Abt WHERE Anr = 17; IF gsumme <> summe THEN <Fehlerbehandlung>; © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart Zeit 27 Transaktionsverwaltung Korrektheit • Vorüberlegungen g g einzelne Transaktion T - wenn T allein auf einer konsistenten DB ausgeführt wird, wird dann terminiert T (irgendwann) und hinterlässt die DB in einem konsistenten Zustand - während der TA TA-Verarbeitung Verarbeitung gibt es keine Konsistenzgarantien! mehrere Transaktionen DB Zustand DB-Zustand konsistent T BOT … … pot. inkonsistent … EOT konsistent - wenn Transaktionen seriell ausgeführt werden, dann bleibt die Konsistenz der DB erhalten - Ziel der Synchronisation: logischer Einbenutzerbetrieb, d.h. Vermeidung aller Mehrbenutzeranomalien © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 28 Transaktionsverwaltung Ablaufpläne für Transaktionen T1 T2 T3 verzahnter Ablaufplan © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart serieller Ablaufplan 29 Transaktionsverwaltung Serialisierbarkeit • Ziel: logischer Einbenutzerbetrieb, d.h. Vermeidung aller Mehrbenutzeranomalien • 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 DBZustand d und d die d gleichen l h Ausgabewerte b wie die d ursprüngliche l h Ausführung f h erzielt. • Hintergrund: Serielle Ablaufpläne sind korrekt Jeder Ablaufplan, der denselben Effekt wie ein serieller erzielt, ist akzeptierbar k i b © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 30 Transaktionsverwaltung DB Scheduler DB-Scheduler • T1 T2 ... T Tn Transaktionsmanager • Scheduler Speichersystem RecoveryKomponente DB-Pufferverwaltung DB © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart • • als Komponente der Transaktionsverwaltung zuständig für I von ACID kontrolliert die beim TA-Ablauf auftretenden Konfliktoperationen (Read/Write, Write/Read, Write/Write) garantiert insbesondere, dass nur „serialisierbare“ TA erfolgreich beendet werden nicht serialisierbare TAs müssen verhindert werden; dazu ist Kooperation p mit der Recoveryy Komponente erforderlich → Rücksetzen von TA 31 Transaktionsverwaltung Synchronisationsverfahren • Zur Realisierung g der Synchronisation y gibt g es viele Verfahren Pessimistisch Optimistisch Versionsverfahren Zeitmarkenverfahren, etc. • Pessimistische Verfahren basieren auf Sperren bei einer Konfliktoperation blockieren sie den Zugriff auf das Objekt universell einsetzbar Sperre auf Objekt y es gibt viele Varianten setzen T1 BOT w(y) EOT T2 BOT w(y) EOT auf Sperrfreigabe warten © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 32 Transaktionsverwaltung Konsistenzebenen • Motivation Serialisierbare Abläufe - gewährleisten „automatisch“ Korrektheit des Mehrbenutzerbetriebs - erzwingen u u. U. U lange Blockierungszeiten paralleler Transaktionen „Schwächere“ Konsistenzebene - bei der Synchronisation von Leseoperationen - erlaubt höhere Parallelitätsgrade und Reduktion von Blockierungen, erfordert aber Programmierdisziplin! - Inkaufnahme von Anomalien reduziert die TA-Behinderungen g © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 33 Transaktionsverwaltung Konsistenzebenen in SQL2 • SQL2 Q erlaubt Wahl zwischen vier Konsistenzebenen (Isolation ( Level)) bezüglich Synchronisation • SQL2 definiert die Konsistenzebenen über die Anomalien, die jeweils in Kauf genommen werden • Lost-Update muss generell vermieden werden d.h., Write/Write-Abhängigkeiten müssen stets beachtet werden • Zuordnung der Anomalien: Anomalie Konsistenzebene Dirty Read NonNon Repeatable Read Phantome READ UNCOMMITTED + + + READ COMMITTED - + + REPEATABLE READ - - + SERIALIZABLE - - - © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 34 Transaktionsverwaltung Konsistenzebenen in SQL2 • SQL-Anweisung: SET TRANSACTION [mode] [ISOLATION LEVEL level] START TRANSACTION [mode] [ d ] [ISOLATION [ LEVEL level] l l] Transaktionsmodus: mode ::= READ WRITE | READ ONLY Konsistenzebenen: level ::= READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE Default: READ WRITE ISOLATION LEVEL SERIALIZABLE Beispiel: SET TRANSACTION READ ONLY, ISOLATION LEVEL READ COMMITTED © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 35 Transaktionsverwaltung READ UNCOMMITTED • T2: READ ONLY,, READ UNCOMMITTED • T2 kann schmutzige Daten lesen • READ UNCOMMITTED und READ WRITE sind unverträglich, da anderenfalls Schreibvorgänge auf Basis von schmutzigen h Daten entstehen könnten T1 T2 Read (A); A := A + 100; Write ((A); ); Read (A); … Rollback; Zeit © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 36 Transaktionsverwaltung READ COMMITTED • T2: READ COMMITTED • T2 sieht unterschiedliche Zustände desselben Objekts A T1 Write ((A); ); Write (B); Commit; T2 Read (A); … Read (B); Read (A); Zeit © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 37 Transaktionsverwaltung Konsistenzebenen in kommerziellen Systemen • Kommerzielle DBS empfehlen meist Konsistenzebene REPEATABLE READ • Kommerzielle DBS verwenden u.U. nicht SERIALIZABLE als Default • Nach dem SQL-Standard muss ein DBS nicht alle Konsistenzebenen implementieren; zu jeder nicht verfügbaren Konsistenzebene muss dann eine restriktivere Ebene implementiert sein • Einige DBS bieten zusätzliche Konsistenzebenen bzw. Varianten der Konsistenzebenen des SQL-Standards DB2: 2 UNCOMMITTED CO READ, CURSOR C SO STABILITY, S READ STABILITY, S REPEATABLE READ SQ SQL Se Server: e S Snapshot-Isolationsstufe aps ot so at o sstu e bas basiert e t au auf Versionsverfahren e so s e a e Einige DBS bieten auch ’BROWSE‘-Funktion, d. h. Lesen ohne Setzen von Sperren © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 38 Transaktionsverwaltung Übersicht • • • • Transaktionskonzept p DB-Recovery: Wiederherstellung im Fehlerfall Synchronisation TA-Verwaltung in verteilten Systemen © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 39 Transaktionsverwaltung Verteilte Informationssysteme • Ein verteiltes Informationssystem y besteht aus autonomen Subsystemen, die koordiniert zusammenarbeiten, um eine gemeinsame Aufgabe zu erfüllen Beispiele - Client/Server-Systeme - Mehrrechner-DBS Mehrrechner DBS - Föderierte DBS - Parallele DBS - ... © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 40 Transaktionsverwaltung Mehrrechner DBS Mehrrechner-DBS KLASSIFIKATIONSMERKMALE: • Rechnerkopplung enge, lose oder nahe Kopplung • Räumliche Verteilung ortsverteilt oder lokal • Externspeicheranbindung gemeinsam (’shared’) oder partitioniert • Integrierte vs. föderative Mehrrechner-DBS • Homogene vs. heterogene DBS • Funktionale Spezialisierung vs. Gleichstellung der Prozessoren • vertikale ik l vs. horizontale h i l Verteilung V il © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 41 Transaktionsverwaltung TA-orientierte Verarbeitung g in heterogenen g Systemen y Server Kontext TA-Programm receive SQL call SQL store send DB X DB Y Sphere of Control (SoC), die z. B. durch einen TP-Monitor etabliert wurde • Ziel: Die gesamte verteilte Verarbeitung in einer ‚Kontrollsphäre‘ ist eine ACIDTransaktion Alle Komponenten werden durch die TA TA-Dienste Dienste integriert Für die Kooperation ist eine Grundmenge von Protokollen erforderlich © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 42 Transaktionsverwaltung Ressourcen Manager/Transaktions Manager Ressourcen-Manager/Transaktions-Manager • Ressourcen-Manager g ((RM)) RM sind Systemkomponenten, die Transaktionsschutz für ihre gemeinsam nutzbaren Betriebsmittel (BM) bieten RM gestatten die externe Koordination von BM-Aktualisierungen BM Aktualisierungen durch spezielle Commit-Protokolle Gewährleistung g von ACID für DB-Daten Gewährleistung von ACID für andere BM, z.B. persistente Warteschlangen, Nachrichten, Objekte von persistenten Programmiersprachen • Transaktions-Manager (TM) Erstellt Transaktions-Identifikatoren (TRIDS) Protokolliert die Beteiligung von RMs an Transaktionen Koordiniert die Commit-Verarbeitung einer Transaktion © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 43 Transaktionsverwaltung 2PC im zentralisierten Fall Koordinator (TM) • Teilnehmer (RM) • Yes Phase 1 P Prepare Commit Pha ase 2 • Ack © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart Annahme: Ein i Transaktionsmanager ki koordiniert k di i das d Commit der Transaktion Ziele in Phase 1: Koordinator K di t führt füh t Entscheidung E t h id bez. b Commit/Abort der Transaktion herbei Beteiligte RM führen Aktionen aus, die bis zum Ende der TA verzögert wurden Beteiligte RM machen Änderungen dauerhaft Ziele der Phase 2: Koordinator verteilt Entscheidung bez. Commit/Abort der Transaktion Koordinator macht Entscheidung durch Log-Eintrag dauerhaft Beteiligte RM führen Aktionen aus, d bis die b zum erfolgreichen f l h Commit der d TA verzögert wurden 44 Transaktionsverwaltung 2PC: Phase 1 Koordinator (TM) • Teilnehmer (RM) Lokales Prepare (Lazy) Yes Schreibe CommitEintrag in Log ((Force)) Lokales Prepare Schreibe PreparedEintrag in Log (Force) Phase 1 P Prepare • Commit Lokale CommitVerarbeitung (Lazy) Ack Lokale CommitVerarbeitung Schreibe Completion CompletionEintrag in Log (Force) Schreibe CompletionEintrag in Log (Lazy) © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart Pha ase 2 • Prepare-Eintrag: RM ist bereit zum Commit, d.h. alle bis zum Commit notwendigen Aktionen wurden ausgeführt und dauerhaft gemacht Commit-Eintrag: Alle beteiligten RM haben Commit zugestimmt Koordinator macht diese CommitEntscheidung durch Commit-Eintrag im Log g dauerhaft Was passiert, wenn der Koordinator ausfällt … ? direkt vor dem Schreiben des Commit-Eintrags direkt nach dem Schreiben des Commit-Eintrags 45 Transaktionsverwaltung 2PC: Phase 2 Koordinator (TM) • Teilnehmer (RM) • Lokales Prepare (Lazy) Yes - Sperren freigeben - Aktionen ohne UNDO • Commit Lokale CommitVerarbeitung (Lazy) Ack Lokale CommitVerarbeitung Schreibe Completion CompletionEintrag in Log (Force) Schreibe CompletionEintrag in Log (Lazy) © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart Completion-Eintrag (TM): Garbage Collection bez. bez TA Pha ase 2 Schreibe CommitEintrag in Log ((Force)) Lokales Prepare Schreibe PreparedEintrag in Log (Force) Phase 1 P Prepare Entscheidung verteilen: Koordinator teilt allen Teilnehmern die Commit-Entscheidung mit Completion-Eintrag (RM): Aktionen, die erst ausgeführt werden können, wenn Commit der TA feststeht wurden ausgeführt 46 Transaktionsverwaltung 2PC: Abbruch der Transaktion Koordinator (TM) Lokales Prepare Schreibe PreparedEintrag in Log (Force) Lokale Abort V Verarbeitung b it Schreibe CompletionEintrag in Log (Force) No Prepare Lokales Prepare (Lazy) Yes Lokales Prepare Schreibe PreparedEintrag in Log (Force) Phase 1 P Prepare Teilnehmer (RM2) Schreibe AbortEintrag in Log (Force) Abort Lokale AbortVerarbeitung (Lazy) Ack Lokale AbortVerarbeitung Schreibe CompletionEi t Eintrag i Log in L (Force) Pha ase 2 Teilnehmer (RM1) Schreibe C Completionl Eintrag in Log (Lazy) © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 47 Transaktionsverwaltung Zustandsübergänge Null = Savepoint 0 Begun = Savepoint 1 Savepoint p N Active während der TA-Verarbeitung Persistent Savepoint N Prepared Flüchtige Zustände Stabile Zustände Dauerhafte Zustände © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart Committing Aborting Committed Aborted nach TA-Ende 48 Transaktionsverwaltung Verteilte Transaktionen • Primär- und Teiltransaktionen 1 Koordinator A1 A2 C ... An Agenten/Teilnehmer (Teiltransaktionen) • Erwartete Fehlersituationen: Transaktionsfehler Systemfehler (Crash von Rechner, Verbindungen, ...) Gerätefehler • Fehlererkennung F hl k z.B. B üb über Timeout Ti © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 49 Transaktionsverwaltung 2PC im verteilten Fall • • • Annahmen: Transaktionsverarbeitung über mehrere Rechnerknoten verteilt Transaktionsmanager pro R h k t verwalten Rechnerknoten lt eingehende i h d und ausgehende Transaktionen Jeder TM führt 2PC für lokale RM aus Zusätzliche Fragestellungen: Kommunikationsstruktur während des 2PC (hierarchisch vs. flach) Welcher TM wird Koordinator der TA? Crash-Recovery und In-doubt Transaktionen Weitere Optimierungmöglichkeiten T Transaktion kti #0815 TM1 in: out: TM2, TM3 RM1 TM2 TM3 in: TM1 out: - in: TM1 out: TM4 RM2a RM2b K t 2 Knoten RM3 Knoten 3 TM4 in: TM3 out: - RM4 Knoten 4 © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 50 Transaktionsverwaltung Crash Recovery Crash-Recovery Teilnehmer • Letzter Eintrag zur TA im Log: Completion: p - TA bereits vollständig bearbeitet - 'ack' an Koordinator erneut verschicken Prepared: - Transaktion 'in doubt' - Entscheidung g bez. TA beim Koordinator nachfragen Sonst: - Transaktion a sa t o zurücksetzen u üc set e © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart Koordinator • Letzter Eintrag zur TA im Log: Completion: p - TA bereits vollständig bearbeitet - 'ack' von allen Teilnehmern erhalten Commit, Abort: - Entscheidung allen Teilnehmern erneut mitteilen Begin: - Prepare-Nachrichten erneut versenden 51 Transaktionsverwaltung Zusammenfassung • Transaktionsparadigma p g (ACID) ( ) Verarbeitungsklammer für die Einhaltung von semantischen Integritätsbedingungen Verdeckung von (erwarteten) Fehlerfällen (failure isolation) - Logging/Recovery Verdeckung der Nebenläufigkeit (concurrency isolation) - Synchronisation im SQL-Standard - Operationen: COMMIT WORK, ROLLBACK WORK - Beginn einer Transaktion explizit oder implizit © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 52 Transaktionsverwaltung Ergänzende Literatur zu diesem Kapitel [[GR93]] [GV02] [BN96] Jim Gray, y, Andreas Reuter: Transaction Processing: g Concepts p and Techniques. Morgan Kaufmann, 1993. Gerhard Weikum, Gottfried Vossen: Transactional Information Systems Morgan Kaufmann, Systems. Kaufmann 2002. 2002 Philip A. Bernstein, Eric Newcomer: Principles of Transaction Processing. Morgan Kaufmann, 1996. © Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart 53
