Transaktionen in verteilten Datenbanken

Transaktionen in verteilten
Datenbanken
Torsten Junge / 96I
[email protected]
Übersicht
•
•
•
•
•
•
Woher kommen Transaktionen?
Anforderungen an Transaktionen
Struktur verteilter Transaktionen
X/Open Standard
Two Phase Commit Protokoll
Crash Recovery
Transaktionen in
verteilten DB
2
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
3
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
4
Transaktion
Folge von Operationen, welche eine
gegebene Datenbank in ununterbrechbarer
Weise von einem konsistenten Zustand in
einen anderen überführt
Transaktionen in
verteilten DB
5
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
6
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
7
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
8
X/Open Distributed Transaction
Processing Reference Modell
Transaktionen in
verteilten DB
9
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
10
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
Transaktionen in
verteilten DB
11
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
Transaktionen in
verteilten DB
12
2PC Protokoll als PAP
Transaktionen in
verteilten DB
13
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 nachfragen; dieser hält Erg. noch, da kein ACK;
entsprechend Ergebnis UNDO/REDO
d keiner der 3: T abbrechen, da 2PC noch nicht
begonnen wurde
Transaktionen in
verteilten DB
14
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
beteiligten RMs
Transaktionen in
verteilten DB
15
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
16