7 Transaktionsverwaltung in Verteilten Datenbanksystemen

7.2 Commit-Behandlung

Bereits in zentralisierten DBS kommt der Commit-Behandlung durch das DBS eine entscheidende Rolle hinsichtlich der Atomarität und Dauerhaftigkeit von Transaktionen zu. Nachdem der Benutzer (bzw. das Anwendungsprogramm) mit der EOT-Anweisung das Transaktionsende signalisiert, werden DBVS-seitig zwei Phasen durchlaufen. Zunächst werden sämtliche Datenbankänderungen sowie ein sogenannter Commit-Satz auf die Log-Datei geschrieben (Phase 1)[24]. Wurde diese Phase erfolgreich abgeschlossen, d.h., der Commit-Satz wurde auf die Log-Datei geschrieben, ist das erfolgreiche Ende der Transaktion garantiert ("Alles"-Fall). Durch das Schreiben der Log-Daten ist die Wiederholbarkeit der Transaktion auch nach einem Rechnerausfall gewährleistet. In Phase 2 der Commit-Behandlung werden dann erst die Änderungen der erfolgreich beendeten Transaktion anderen Transaktionen sichtbar gemacht, z.B. durch Freigabe der Sperren. Transaktionen, die vor Abschluß der ersten Commit-Phase (z.B. durch einen Rechnerausfall) unterbrochen wurden, werden zurückgesetzt ("Nichts"-Fall).

Zur Wahrung der Transaktions-Atomarität in Verteilten DBS müssen sich alle an einer globalen Transaktion T beteiligten Knoten auf ein gemeinsames Commit-Ergebnis einigen. T muß also entweder an allen Knoten abgebrochen werden (Abort) oder an allen Knoten erfolgreich zu Ende kommen (Commit). Um dies zu erreichen, ist ein verteiltes Commit-Protokoll erforderlich. Eine Grundforderung an ein geeignetes Protokoll ist die Korrektheit, d.h., es muß die Alles-oder-Nichts-Eigenschaft sowie die Dauerhaftigkeit von Transaktionen auch im Fehlerfall gewährleisten. Unter Leistungsgesichtspunkten sollten dabei möglichst wenige Nachrichten und Schreibvorgänge auf die Log-Datei benötigt werden, da beide Faktoren die Antwortzeiten verlängern und Overhead einführen. Eine weitere Forderung ist eine hohe Robustheit des Protokolls gegenüber Fehlern, um z.B. die Wahrscheinlichkeit einer "Blockierung" (s.u.) möglichst gering zu halten. Damit im Zusammenhang steht die Forderung, daß jeder der beteiligten Rechner möglichst lange das Recht haben sollte, eine globale Transaktion von sich aus abzubrechen ("unilateral abort"). Die Unterstützung einer hohen Robustheit erfordert jedoch i.d.R. zusätzliche Nachrichten und E/A-Vorgänge und geht damit auf Kosten der Leistungsfähigkeit. Da der Fehlerfall (hoffentlich) selten eintrifft, sollte daher der Optimierung des Leistungsverhaltens im Normalbetrieb Vorrang eingeräumt werden.

Bei den vorzustellenden Commit-Protokollen nehmen wir generell an, daß an jedem Knoten ein Transaktions-Manager (TM) existiert, der für die Transaktionsverwaltung der lokal ausgeführten (Teil-)Transaktionen verantwortlich ist und der mit den Transaktions-Managern der anderen Knoten im Rahmen des Commit-Protokolls kooperiert. Insbesondere verwaltet jeder TM eine lokale Log-Datei, in der sämtliche Commit-Entscheidungen protokolliert werden. Für Verteilte Datenbanksysteme kann der Transaktions-Manager als Teil der an jedem Knoten laufenden DBVS-Instanz aufgefaßt werden, so daß für Commit-Entscheidungen sowie DB-Änderungen dieselbe Log-Datei verwendet werden kann[25].

In verteilten Commit-Protokollen kommt dem Transaktions-Manager des Heimatknotens einer Transaktion die Sonderrolle des Commit-Koordinators zu. Aufgabe des Koordinators ist die Ermittlung des globalen Commit-Ergebnisses (Commit oder Abort) und dessen Mitteilung an die an der Transaktionsausführung beteiligten Rechner. Die Transaktions-Manager der Rechner, an denen eine Sub-Transaktion ausgeführt wurde, wollen wir als Agenten bezeichnen.

Abb. 7-2: Kommunikationsstrukturen für verteilte Commit-Protokolle

Zur Kommunikation zwischen Koordinator und Agenten kommen unterschiedliche Aufrufstrukturen in Betracht, die in Abb. 7-2 gezeigt sind. Bei der zentralisierten Commit-Struktur (Abb. 7-2a) kommuniziert der Koordinator direkt mit jedem Agenten, während zwischen den Agenten i.d.R. keine Kommunikation stattfindet. Der Vorteil liegt vor allem darin, daß die Commit-Behandlung parallel mit allen Agenten durchgeführt werden kann. Die lineare Commit-Struktur (Abb. 7-2b) verlangt dagegen eine Sequentialisierung der Commit-Bearbeitung, erlaubt jedoch Einsparungen in der Nachrichtenanzahl (s.u.). Die hierarchische Struktur (Abb. 7-2c) schließlich berücksichtigt die hierarchische Aufrufstruktur innerhalb einer globalen Transaktion, wie sie im Transaktionsbaum repräsentiert ist. Sie kann als allgemeinste Struktur aufgefaßt werden, da sich die beiden ersten Ansätze als Spezialfälle ergeben.

Wir stellen im folgenden zunächst als Basismodell ein Zwei-Phasen-Commit-(2PC)-Protokoll vor, das die beiden eingangs erwähnten Phasen der Commit-Behandlung verteilt realisiert und auf der zentralisierten Kommunikationsstruktur basiert. Danach werden lineare und hierarchische 2PC-Protokolle erläutert. In Kap. 7.2.4 werden dann verschiedene Optimierungen verteilter Commit-Protokolle zur Reduzierung der Nachrichtenanzahl präsentiert. Abschließend behandeln wir noch ein 3-Phasen-Commit-Protokoll, welches vor allem eine höhere Robustheit im Vergleich zu 2PC-Verfahren anstrebt.

[24] Wir gehen in diesem Kapitel stets von einer sogenannten Noforce-Strategie [HR83] zur Propagierung von DB-Änderungen aus. Dabei werden während der Commit-Behandlung (im Gegensatz zur Force-Alternative) geänderte DB-Seiten nicht in die physische Datenbank zurückgeschrieben, sondern die Änderungen lediglich in der Log-Datei protokolliert.
[25] Im X/Open-Modell erfolgt dagegen eine Trennung zwischen Transaktions-Managern und sogenannten Resource-Managern wie dem DBVS (Kap. 2.1.4, Kap. 11.4.1). Dabei ist der TM im wesentlichen für die Commit-Behandlung zuständig, während Synchronisation und Logging den Resource-Managern überlassen bleiben. Dies ist vorteilhaft zur Unterstützung heterogener Resource-Manager, verlangt jedoch i.a. getrennte Log-Dateien und damit erhöhten Log-Aufwand.
7.2.1 - Verteiltes Zwei-Phasen-Commit (Basis-Protokoll)
7.2.2 - Lineares Zwei-Phasen-Commit
7.2.3 - Hierarchische 2PC-Protokolle
7.2.4 - Optimierungen von 2PC-Verfahren
7.2.5 - Drei-Phasen-Commit