Transaktionen in verteilten Datenbanken Torsten Junge / 96I tjunge@imn.htwk-leipzig.de

Übersicht Woher kommen Transaktionen? Anforderungen an Transaktionen Struktur verteilter Transaktionen X/Open Standard Two Phase Commit Protokoll Crash Recovery Transaktionen in verteilten DB

Woher kommen Transaktionen? „Closed Shop“ Betrieb: Programmabarbeitung im reinen Batch-Betrieb, d.h.: Programme wurden eingereicht und sequentiell abgearbeitet kein direkter Benutzerzugang Informationen über Prg.-Ablauf an zentr. Stelle langsam, aufwendig aber wohl geordnet Transaktionen in verteilten DB

Online Transaction Processing Online-Zugriff der Benutzer auf Daten und Programme Neues Problem: Wie garantieren, daß Benutzer sich nicht gegenseitig Programme sperren / Daten zerstören? Sequentielle Abarbeitung für den Zeitraum der Bearbeitung einer Ressource muß unabhängig von anderen Prg. / Benutzern garantiert werden Transaktionen in verteilten DB

Transaktion Folge von Operationen, welche eine gegebene Datenbank in ununterbrechbarer Weise von einem konsistenten Zustand in einen anderen überführt Transaktionen in verteilten DB

Anforderungen an Transaktionen Atomic - untrennbare Einheit; Alles oder nichts Consistent - System befindet danach entweder im Zustand vor oder nach der T. Isolated - Teilergebnisse sind für nicht eingebundene Ressourcen nicht sichtbar Durable - Ergebnisse sind dauerhaft Transaktionen in verteilten DB

Besonderheiten in verteilten DB Eine T. kann Daten in DB1 und DB2 ändern (2) DB1 kann T. erfolgreich abschließen; DB2 mit Fehler ein Koordinator ist erforderlich Transaktionen in verteilten DB

Komponenten zur Abwicklung verteilter Transaktionen Anwendungssystem Initiator einer Transaktion Ressource Manager regelt den Zugriff auf Ressourcen, z.B. DBs oder Dateisysteme Transaction Manager Verwaltung / Koordination von T. z.B. über die Bereitstellung von Transaktionskennungen Transaktionen in verteilten DB

X/Open Distributed Transaction Processing Reference Modell Transaktionen in verteilten DB

Struktur verteilter Transaktionen Mehrere Knoten (Ressource Manager) können beteiligt sein Startknoten - Koordinatorknoten Aufrufstruktur - gerichteter Graph (Baum) Knoten nicht einzeln rücksetzbar Transaktionen in verteilten DB

Two Phase Commit Protokoll (1) bei EOT PREPARE an alle beteiligten RMs RMs sichern Wiederholbarkeit durch Schreiben der Log-Daten sowie eines PREPARED Satz RMs senden jeweils PREPARED/FAILED an Koordinator bei FAILED wird die T bereits lokal zurückgesetzt, da globales FAIL feststeht Transaktionen in verteilten DB

Two Phase Commit Protokoll (2) nach PREPARED von allen RMs und Eintrag in Log-Datei gilt T als erfolgreich COMMIT an alle beteiligten RMs, diese schreiben COMMIT Satz in Log-Datei und quittieren (ACK) bei FAILED von mind. einem RM ABORT an alle RMs, die mit COMMIT geantwortet haben Transaktionen in verteilten DB

2PC Protokoll als PAP Transaktionen in verteilten DB

Crash Recovery (1) Sub - Knoten COMMIT Satz: erfolgreiche T. - REDO Rec. ABORT Satz: n. erfolgreiche T. - UNDO Rec. PREPARED Satz: Erg. bei Koordinator nach-fragen; dieser hält Erg. noch, da kein ACK; entsprechend Ergebnis UNDO/REDO keiner der 3: T abbrechen, da 2PC noch nicht begonnen wurde Transaktionen in verteilten DB

Crash Recovery (2) Koordinator Ende Satz: UNDO/REDO je nach Commit-Erg. kein Ende Satz: ABORT Satz: UNDO Rec.; Information der beteiligten RMs COMMIT Satz: REDO Rec.; Information der beteiligten RMs keiner der 3: UNDO Rec.; Information der beteiligten RMs Transaktionen in verteilten DB

Literatur E. Rahm: Mehrrechner-Datenbanksysteme G. Vossen: Datenmodelle, Datenbanksprachen und Datenbank-Management-Systeme basicpro 1/99: W. Lale: Transaktionsmonitore http://kant.ti5.tu-harburg.de/Lecture/98-99ws/Tp/* Transaktionen in verteilten DB