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
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
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
Transaktion
Folge von Operationen, welche eine
gegebene Datenbank in ununterbrechbarer
Weise von einem konsistenten Zustand in
einen anderen überführt
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
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
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
X/Open Distributed Transaction
Processing Reference Modell
Struktur verteilter Transaktionen
• Mehrere Knoten
(Ressource Manager) können beteiligt sein
• Startknoten -
Koordinatorknoten
• Aufrufstruktur -
gerichteter Graph (Baum)
• Knoten nicht einzeln rücksetzbar
Two Phase Commit Protokoll (1)
• Phase 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
Two Phase Commit Protokoll (2)
• Phase 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
2PC Protokoll als PAP
Crash Recovery (1)
• Sub - Knoten
a COMMIT Satz: erfolgreiche T. - REDO Rec.
b ABORT Satz: n. erfolgreiche T. - UNDO Rec.
c PREPARED Satz: Erg. bei Koordinator nach- fragen; dieser hält Erg. noch, da kein ACK;
entsprechend Ergebnis UNDO/REDO
d keiner der 3: T abbrechen, da 2PC noch nicht begonnen wurde
Crash Recovery (2)
• Koordinator
a Ende Satz: UNDO/REDO je nach Commit-Erg.
– kein Ende Satz:
b ABORT Satz: UNDO Rec.; Information der beteiligten RMs
c COMMIT Satz: REDO Rec.; Information der beteiligten RMs
d keiner der 3: UNDO Rec.; Information der
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/*
