Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

10.11.1989 - 

Verteilte Systeme sind nicht gleich verteilte Systeme

Ohne "2-Phasen-Commit" läuft künftig nichts mehr

Der Horror für Unternehmen mit verteilter Datenhaltung: Ein entferntes System fällt aus, und die dort gelagerten Daten können weder abgefragt noch aktualisiert werden. Der Verlust der Datenkonsistenz droht. Hier sorgt das 2-Phasen-Commit-Protokoll für Abhilfe. Doch nicht alle Datenbankprodukte, die sich verteilt nennen, bieten diese Möglichkeit.

In einem verteilten Datenbank-Verwaltungssystem können Fehlerzustände auftreten, in deren Folge einzelne Rechner nicht mehr erreichbar sind. Damit in solchen Fällen keine Fehler bei den Daten entstehen, ist eine Verständigung zwischen den Rechnern erforderlich. Eine solche Verständigungsmöglichkeit ist das 2-Phasen-Commit-Protokoll.

Der Begriff 2-Phasen-Commit geht auf einen von J. N. Gray 1978 veröffentlichten Artikel "Anmerkungen zu Datenbank-Betriebssystemen" zurück. Die Funktion des Protokolls ist, die Änderungen auf mehreren Systemen derart zusammenzufassen, daß entweder alle oder keine Änderungen durchgeführt werden. Die Eigenschaft, systemübergreifende Änderungen durchführen zu können wird mit dem Begriff "Atomarität" bezeichnet.

Mehr Flexibilität für den Anwender

Von einem Datenbank-Verwaltungssystem (DBMS) wird die Atomarität eines einzelnen Änderungsbefehls erwartet. Das aber ist keine Selbstverständlichkeit, denn ein Änderungsbefehl verursacht üblicherweise mehrere Änderungen an den Daten und Zugriffspfaden.

Darüber hinaus bieten Datenbanksysteme Transaktionen an, wodurch die Atomarität mehrerer Änderungsbefehle gewährleistet werden kann. Eine Transaktion kann automatisch vom DBMS oder auf Anforderung vom Anwender eingeleitet werden. Beendet wird sie in der Regel auf Anforderung des Users.

Nach einer schwerwiegenden Störung vor dem Ende der Transaktion sorgt das DBMS von sich aus für deren Atomarität, indem es alle bisherigen Änderungen der Transaktion storniert. Darüber hinaus bietet ein DBMS dem Anwender in der Regel auch die Möglichkeit, angefangene (Änderungs-) Transaktionen ungeschehen erscheinen zu lassen Nur damit kann der Anwender angemessen auf Ereignisse reagieren, die ihm erst während der Transaktion bekannt werden.

Die Notwendigkeit, Atomarität von Änderungen, also das Ende einer Transaktion, zweiphasig zu kontrollieren, besteht genau dann, wenn Änderungen technisch in mehrere unabhängige (Sub-)Transaktionen aufgeteilt sind, die aber aus Sicht der Anwendung eine Einheit bilden.

Für solche übergreifenden Änderungen muß das Ende der Transaktion in zwei Phasen unterteilt werden. Die erste Phase beginnt mit der Aufforderung an alle beteiligten (Sub-)Systeme: "Prepare to Commit". Das (Sub-)System prüft, ob die (Sub-) Transaktion also die hier gewünschten Änderungen, durchführbar sind. Sind sie es nicht wird die (Sub-)Transaktion erfolglos beendet, die Änderungen erscheinen ungeschehen Sind die Änderungen realisierbar, so werden sowohl ihre Durchführbarkeit als auch ihre Rücksetzbarkeit dauerhaft (auf Festspeicher) garantiert. Anschließend oder zeitgleich können entsprechende "Prepare to Commit" an die anderen (Sub-) Systeme geschickt werden, die auch Teile der zusammengehörenden Änderungen durchzuführen haben.

Die erste Phase endet mit den Antworten aller (Sub-)Systeme auf die "Prepare to Commit" Anforderung. Die zweite Phase beginnt mit der Auswertung dieser Antworten. Meldet eines der (Sub-)Systeme, daß es die (Sub-)Transaktion nicht durchführen kann, wird auch bei allen anderen (Sub-)Systemen die (Sub-)Transaktion storniert. Damit wird die gesamte Transaktion erst gar nicht begonnen.

Haben alle betroffenen (Sub-) Systeme ihre Transaktionsbereitschaft signalisiert, so besteht nun die Möglichkeit, sämtliche (Sub-)Transaktionen durchführen zu lassen ("Commit"). Damit ist die gesamte Transaktion atomar durchgeführt. Haben alle (Sub-)Systeme die erfolgreiche Stornierung beziehungsweise Durchführung ihrer (Sub-)Transaktion bestätigt, ist auch die zweite Phase beendet.

Sind bei der atomar durchzuführenden Änderung verschiedene (Sub-)Systeme beteiligt, die nur durch eine Anwendung zusammenhängen, kann auch nur der Anwender dieses Protokoll programmieren Dieser Aufwand sollte jedoch nicht unterschätzt werden.

Gateways und transparente Transaktionen

Falls bei einer atomar durchzuführenden Änderung verschiedene, unmittelbar miteinander kommunizierende (Sub-) Systeme beteiligt sind, kann eines davon das Protokoll übernehmen. Wenn ein DBMS nun auch den Zugriff auf andere Datenbanksysteme an diesem oder anderen Rechnern ermöglicht, so kann es mit dem 2-Phasen-Commit-Protokoll Atomarität von zusammenhängenden Änderungen gewährleisten. Bemerkt der Anwender nichts von der Verteilung, spricht man von transparenten Transaktionen.

Stammen die an der Kommunikation beteiligten DB-Systeme von verschiedenen Herstellern, so handelt es sich um ein Gateway. Dem Verfasser ist kein System bekannt, das die Atomarität solcher Änderungen gewährleistet, die über mehrere Gateways oder über ein Gateway und eigene Daten verstreut sind.

Für verteilte und herkömmliche DBs

Sind alle Systeme von einem Hersteller, spricht man von einem verteilten Datenbank-Verwaltungssystem (DDBMS). Ein DDBMS gewährt dem Anwender eine einheitliche logische Sicht auf physisch verteilte Daten. Das 2-Phasen-Commit-Protokoll ist also sowohl bei verteilten als auch bei herkömmlichen Datenbanken notwendig.

Unter einer verteilten Datenbank wird die physische Verteilung einer Datenbank auf mehrere Rechner verstanden, wobei der Anwender die Datenbank als eine logische Einheit sieht.

Der Ablauf einer Änderung richtet sich nach der Art der Datenverteilung. Hier werden die horizontale Partitionierung und die Replikation unterschieden.

Horizontale Partitionierung

Ist beispielsweise die Mitarbeiterdatei einer Firma nach den Arbeitsplätzen der Mitarbeiter verteilt, so spricht man von horizontaler Partitionierung. Sollen alle Mitarbeiter unter 30Jahren eine Prämie erhalten, so sind überall die Mitarbeiterdateien zu ändern.

Wenn nun ein Rechner ausfallt, nachdem ihm der Änderungsauftrag zugeteilt wurde, dann kann man zunächst nicht feststellen, ob er die Änderung durchgeführt hat oder nicht.

Die anderen beteiligten Rechner dürfen ihren Anteil der Änderung also weder endgültig abschließen noch rückgängig machen.

Warten, bis der ausgefallene Rechner wieder erreichbar ist, kann zu lange dauern und nützt auch nichts. Ob nämlich der ausgefallene Rechner den Änderungsauftrag überhaupt nicht erhalten oder bereits vollständig abgeschlossen hat, ist in der Regel nicht ersichtlich. Dies zu erkennen ist die Aufgabe eines verteilten Datenbanksystems Horizontale Partitionierung wird bereits von einigen Produkten auch für Änderungen transparent unterstützt.

Ein zweites Beispiel soll anhand einer Handelsfirma, die ihren Warenbestand auf mehrere Lagerorte verteilt, das Prinzip der replizierten Datenverarbeitung illustrieren. Von jedem Lager aus können sowohl Bestellungen als auch Lieferungen ausgehen, die auch andere Lager betreffen. In jedem Lager wird der gesamte verteilte Bestand geführt.

Ist diese Bestandsführung DV-gestützt, spricht man von replizierter Datenhaltung. Jedes Lager kann dabei vor Ort den gesamten Bestand durchsuchen und lesen. Insbesondere kann jedes Lager für sich Bestellungen veranlassen und unverbindliche Angebote für Lieferungen erstellen. Erst bei verbindlichen Angeboten oder Auslieferungen müssen alle Lager informiert werden.

Selbstverständlichkeit für überlebende DBMS

Ist ein Lager für ein solches Update nicht erreichbar, muß die Information solange sicher aufbewahrt werden, bis das Lager erreicht werden kann. Bis dahin kann der durch die Information veranlaßte Vorfall nicht ausgeführt werden.

Der gesamte Ablauf unterstellt ein 2-Phasen-Commit-Protokoll:

- Festschreiben des geplanten Angebots bei einem beliebigen Lager mit der Information, was von welchem Lager zu liefern ist.

- Verteilung des Angebotes an alle Lager.

- Ist ein betroffenes Lager nicht erreichbar oder meldet es Lieferschwierigkeiten, wird die Stornierung des Angebotes allen Lagern mitgeteilt.

- Haben alle Lager ihren Anteil der Lieferung vorläufig bestätigt und entsprechend notiert, so werden die Ergebnisse bei dem oben ausgewählten Lager festgeschrieben, und das nun verbindliche Angebot wieder allen Lagern bekanntgegeben.

Fällt nach dem Festschreiben des verbindlichen Angebotes irgendeine Verbindung oder Lagerwaltung aus, so geht das Angebot nicht verloren Jedes betroffene Lager hat nämlich das Angebot verbindlich oder halbverbindlich notiert. Ein Lager darf über den angebotenen Bestand nicht verfügen, es sei denn es erhielte eine Stornierung.

Alle Anzeichen deuten aber darauf hin, daß verteilte Datenbanken mit 2-Phasen-Commit-Protokoll in den nächsten Jahren für alle dann noch überlebenden DBMS zur Selbstverständlichkeit werden.

*Heinz Bayen ist Leiter der Datenbankentwicklung bei der Infodas Gesellschaft für Systementwicklung mbH, Köln

Verteilte Datenbanksysteme am Markt

Adabas von der Software AG bietet den normalen Zugriff auf entfernte Adabas-Daten.

DDB/4 von der Nixdorf AG bietet Zugriff auf entfernte Datenbanken und horizontale Partitionierung. Rechnerübergreifende Änderungen werden atomar über ein transparentes 2-Phasen-Commit-Protokoll durchgeführt.

Ingres von der Relational Technology GmbH bietet lesenden Zugriff auf einen anderen Rechner.

Nonstop SQL von der Tandem Computers GmbH bietet Transaktionen über Datenbanken, die horizontal partitioniert sein dürfen.

Oracle von der Oracle Deutschland GmbH bietet lesenden Zugriff auf entfernte Datenbanken.

Pisa/NT von der Infodas GmbH ermöglicht transparenten Zugriff auf entfernte Datenbanken, die zusätzlich repliziert sein dürfen. Die Replikate einer Datenbank werden durch ein transparentes Protokoll geändert das dem 2-Phasen-Commit ähnelt.

Supra von der Cincom Systems Inc. bietet ein transparentes 2-Phasen-Commit-Protokoll über mehrere Rechner mit horizontalen Partitionen.

Sybase von der Sybase Inc. bietet den normalen Zugriff auch auf entfernte Datenbasen. Ein 2-Phasen-Commit-Protokoll kann und muß vom Anwender programmiert werden.

UDS-D von der Siemens AG bietet transparenten Zugriff auf entfernte Datenbanken. Sind an einer Änderungstransaktion mehrere Rechner beteiligt, wird die Transaktion vom UDS-D transparent mit einem 2-Phasen-Commit-Protokoll abgeschlossen.

VAX Rdb/VMS von der Digital Equipment Corporation bietet normalen Zugriff auf entfernte Datenbanken.