Die Anbieter von Hardware und Software vermerkten in den letzten Jahren

verstärkt verteilte Datenbanksysteme. Inzwischen liegen auch Erfahrungen mit

dem Einsatz der Produktion vor. Im folgenden werden die Funktionen verteilter

Datenbanksysteme erläutert und Erfahrungen der Praxis von

Anwenderunternehmen beschrieben.

Ein verteiltes Datenbanksystem erlaubt dem Anwendungsprogramm, auf Daten desselben Rechners und auf Daten entfernter Rechner zuzugreifen. Dabei präsentiert es auch die entfernten Daten so, als befänden sie sich lokal (Abbildung 1). Diese Eigenschaft ist das wesentliche funktionale Merkmal eines verteilten Datenbanksystems. Es wird in der Fachwelt "Single System Image" genannt.

Das Single System Image macht die eigentliche Attraktivität verteilter Datenbanksysteme gegenüber anderen Verteilungsformen aus. Eine Alternative zum verteilten Datenbanksystem ist zum Beispiel die sogenannte verteilte Transaktionsverarbeitung. Bei dieser Methode schickt eine Anwendung Aufträge an Anwendungen entfernter Rechner. Die beteiligten Datenbanksysteme, die von den Anwendungen benutzt werden, arbeiten rein lokal. Daher müssen die mit der Verteilung verbundenen Probleme von den Anwendungsprogrammen zu lösen sein. Dies ist aber meist mit beträchtlichen Entwicklungs- und Anpassungskosten verbunden.

Ein verteiltes Datenbanksystem hebt die starre Zuordnung von Datenbanken und Anwendungen zum Rechner auf, ohne daß die Anwendungen hiervon berührt würden. Im Prinzip lassen sich damit Anwendungen und Daten unabhängig voneinander und beliebig auf die Rechnerknoten eines Netzes verteilen. Der Anwender sollte aber darauf achten, daß sich die Daten jeweils an dem Rechner befinden, an dem sie am häufigsten benötigt werden (Lokalitätsprinzip). Damit spart er Kommunikationszeiten und entsprechende Kosten. Andere Rechner können diesen Datenbestand bei Bedarf abfragen oder ändern.

Weniger Aufwand - größere Flexibilität

Das Datenbanksystem erschließt den Ablagerort der Daten aus dem Directory beziehungsweise einer Verteiltabelle des Datenbanksystems, in der die Beziehung von Datenobjekt und Ort beschrieben ist. Der Anwender braucht nur dafür zu sorgen, daß eine Verteiltabelle zum Verarbeitungszeitpunkt an jedem benötigten Rechner zur Verfügung steht.

Dies reduziert den Aufwand für die Synchronisierung auf ein Minimum und erhöht die Flexibilität jede Datenbank bleibt eine eigenständige Einheit, die auch nach Wegfall der Rechnerverbindungen lokal weiterarbeiten kann. Auf diese Weise wird das Prinzip der lokalen Autonomie erfüllt.

Beim Übergang von zentralen zu verteilten Datenbanken muß lediglich die Verteiltabelle bearbeitet werden. Die Neuaufnahme eines zusätzlichen Rechnerknotens ins Netz ist im besten Fall sogar ohne Unterbrechung des Datenbankbetriebs der schon installierten Rechnerknoten möglich.

Das Single System Image bringt für das verteilte Datenbanksystem allerdings eine Reihe recht anspruchsvoller Probleme mit sich. Das gesamte lokale Verhalten des Datenbanksystems muß unverändert bleiben, auch wenn im Verteilungsfall mehrere Data-Base-Handler auf mehreren Rechnern zusammenarbeiten müssen. Dies betrifft Syntax und Funktionalität der Schnittstelle zwischen Datenbanksystem und Anwenderprogramm, aber auch die Transaktionssicherung und den Wiederanlauf nach Rechnerausfall.

Damit die Anwendungsprogramme von der Verteilung unberührt bleiben, dürfen sich die Formulierung eines Auftrags an das Datenbanksystem und die Identifizierung der angesprochenen Datenobjekte wie Datenbanknamen und Tabellennamen nicht vom lokalen Zugriff unterscheiden. Diese Eigenschaft ist unter der Bezeichnung Ortsunabhängigkeit oder Ortstransparenz bekannt. Der Bezug zum Ort der angesprochenen Daten darf ausschließlich in der Verteiltabelle beschrieben werden.

Das relationale Datenmodell bietet hierzu in der Theorie einen Vorteil, der in der Praxis wenig ausgeschöpft wird: Mit der Definition eines View, sprich einer Benutzerschicht, über verteilte Tabellen kann eine zuvor lokale Tabelle ersetzt werden.

So lassen sich bei unberührtem Anwendungsprogramm sogar Teile von Tabellen verteilen. Eine vertikale Fragmentierung ergibt sich aus einem View, der die Teiltabellen über einen Join verknüpft. Eine horizontale Trennung von Tabellen wird möglich durch einen View, der die Teiltabellen über die "Union"-Funktion vereinigt.

Allerdings schränkt die relationale Zugriffssprache SQL die auf solche Views anwendbaren Anweisungen ein. Erlaubt sind zum Beispiel nur Lese- und keine Änderungszugriffe. Die einschlägigen veriteilten Datenbanksysteme verzichten noch weitgehend auf das Splitting von Tabellen und beschränken sich auf Datenbank oder Tabelle als Granulat der Verteilung.

Anspruchswolle Optimierungsalgorithmen

Beim verteilten Einsatz von Datenbanken darf auch die lokal vorhandene Freiheit beim Ansprechen mehrerer Datenobjekte nicht eingeschränkt werden. Eine Anweisung im Anwendungsprogramm, die mehrere Tabellen anspricht, muß auch arbeiten können, wenn die Tabellen auf verschiedenen Rechnern verteilt sind.

Um allerdings etwa einen verteilten Join mit guter Performance abwickeln zu können, sind vom Hersteller anspruchsvolle Optimierungsalgorithmen zu Implementieren. Andernfalls muß der Anwender in Kauf nehmen, daß große Satzmengen über die Leitung zum Rechner des Anwendungsprogramms gebracht und erst dort zu einer eventuell kleinen Ergebnismenge verschnitten werden. Es gibt derzeit fast keine Systeme, die für einen Auftrag über mehrere Rechner solche Algorithmen bereitstellen.

Verteilte Transaktionen und das Two Phase Commit

Einen umfassenderen Problembereich bilden Anweisungsfolgen, die in einer Transaktionsklammer auf Daten mehrerer Rechner schreibend zugreifen (Abbildung 1). Damit die Transaktionssicherung auch im Fall der Verteilung aufrechterhalten wird, ist die globale Transaktion in Subtransaktionen zu unterteilen, die auf den einzelnen Rechnern ausgeführt und unter einander synchronisiert werden.

Läßt sich eine Subtransaktion nicht durchfuhren - etwa in einer Deadlock-Situation -, muß die globale Transaktion zurückgesetzt werden. Hier ist der Einsatz des Two-Phase-Commits gefragt.

Bei Abschluß der Transaktion müssen die beteiligten Data-Base-Handler in der Lage sein, die Subtransaktion entweder abzuschließen oder zurückzusetzen. Diese erste Phase ist das "Prepare to Commit". Nur wenn von allen Partnern die Zusicherung kommt, daß sie ihre Transaktion durchfuhren können, werden sie - das ist die zweite Phase - aufgefordert, diese tatsächlich zu beenden. Andernfalls sind alle Subtransaktionen zurückzusetzen.

Die Erkennung und die optimale Auflösung von Sperrsituationen wie Deadlocks und Longlocks stellt sich im Falle der Verteilung komplexen dar als bei konventionellen Datenbanken. Der Grund: Transaktionen können hier die Betriebsmittel auch mehrerer Data-Base-Handler blockieren. Dadurch treten möglicherweise rechnerübergreifende Sperrsituationen auf.

Bei sich ändernden Transaktionen über mehrere Rechner muß auch der Wiederanlaufmechanismus des Datenbanksystems nach einem Sessionabsturz neuartige Situationen beherrschen. Das geschieht in Abhängigkeit davon, bei welchem Schritt des Two-Phase-Commits eine Session unterbrochen wurde.

Wenn nach der ersten Phase (Prepare to Commit) diejenige Komponente ausfällig die gerade sie globale Transaktionssteuerung nach den Regeln des Two-Phase-Commit-Protokolls koordiniert, muß mit Hilfe globaler Sicherungsdaten ein "globaler" Wiederanlauf durchgeführt werden.

Ein anderes Problem taucht auf, wenn in der zweiten Phase des Protokolls die beteiligten Partner zum endgültigen Beenden oder Rücksetzen der Transaktion aufgefordert werden, aber nicht alle Rechner erreichbar sind. Das BS2000-Datenbanksystem Sesam von Siemens-Nixdorf hat für diesen Fall ein Mailboxverfahren entwickelte das sicherstellt, daß solche Aufträge Später nachgeholt werden können.

Die Aufgaben im Zusammenhang mit der Transaktionssicherung sind nur mit beträchtlichem Aufwand für Forschung und Realisierung zu lösen. Daher unterscheiden sich die am Markt angebotenen Produkte bezüglich der Transaktionsfunktionen beträchtlich.

Änderungen konnten nur lokal durchgeführt werden

Die ersten verteilten Systeme erlaubten Anfang der 80er Jahre nur Leseaufträge an einen einzigen entfernten Rechnerknoten innerhalb einer Transaktion. Änderungen konnten nur lokal durchgeführt werden. Seit Mitte der 80er Jahre wird auch die Möglichkeit von Änderungsaufträgen an einem entfernten Rechnerknoten innerhalb einer Transaktion angeboten.

Diese Funktionalität des "Remote Unit of Work", die eine Transaktionseinheit auf einen einzigen entfernten Datenserver beschränkt, ist auch Stand der Technik bei den heute für heterogene Systeme entstehenden Client/Server-Lösungen. Die dort benötigten Standards werden derzeit von der SQL Access Group auf der Basis des ISO-normierten, Remote-Data-Access-Protokoll RDA und von der IBM mit einem eigenen DRDA-Protokoll erarbeitet.

Homogene verteilte Datenbanksysteme dagegen, wo an allen Rechnerknoten das gleiche Datenbanksystem läuft, erlauben zusätzlich "Multi Site Retrieval" innerhalb einer Transaktion. Das Two-Phase-Commit-Verfahren, mit der Möglichkeit des "Multi Site Update" innerhalb einer Transaktion, unterstützen bisher nur wenige Systeme, obwohl viele Hersteller es schon seit Jahren ankündigen.

Ein Beispiel aus der Praxis

Im folgenden soll als konkretes Beispiel eine Anwendung aus dem Behördenbereich geschildert werden. Dort läuft ein verteiltes Datenbanksystem auf BS2000-Rechnern von Siemens-Nixdorf. Auf zwei Mainframes verteilt entlastet die Datenbank die Großrechner. Sie bilden einen Verfügbarkeitsverbund (Abbildung 2). Fällt der eine aus, übernimmt der andere dessen Arbeit mit. Sie stehen beide im selben Rechenzentrum und sind direkt über Vorrechner gekoppelt.

An der Abwicklung eines für diese Anwendung typischen Vorganges wie der Auftragsbearbeitung sind sowohl externe Rechner als auch Dialogstationen der Anwender beteiligt. Insgesamt nehmen rund 500 Rechner - häufig Unix-Systeme unterschiedlicher Hersteller über Datex-L mit der zentralen Server-Anwendung Verbindung auf. Etwa 500 Dialogstationen und Drucker des Anwenders sind durch vorgeschaltete dezentrale Datenstationsrechner über, Standleitung an die Zentrale angeschlossen. An den Datenstations-Rechnern findet eine Vorverarbeitung der Eingaben mit Plausibilitätsprüfungen und Fehlermeldungen statt.

Täglich zirka 200 000 Datenbank-Transaktionen

Die Anwendung arbeitet im 24-Stunden-Betrieb, wobei pro Tag an die 50 000 Vorgänge abgewickelt werden. Da ein Vorgang aus mehreren Transaktionen der beteiligten Kommunikationspartner besteht, fallen täglich zirka 200 000 Datenbank-Transaktionen an mit jeweils durchschnittlich drei Satzänderungen und zehn Lesezugriffen. Etwa 3000 Transaktionen davon sind verteilt und beinhalten Datenänderungen an beiden zentralen Rechnern innerhalb einer Transaktion.

Deshalb ist es unerläßlich, daß die übergreifende Transaktion nach einem Two-Phase-Commit-Protokoll durchgeführt wird. Mit diesem Verfahren konnte ein selbstentwickelter Mechanismus abgelöst werden. Die Antwortzeiten liegen jetzt etwa bei zwei Sekunden.

Ein verteiltes Datenbanksystem zur Lastverteilung im Rechenzentrum, wie in diesem Beispiel geschildert, wird durchaus nicht selten dann eingesetzt, wenn ein Rechner an seine, Kapazitätsgrenze stößt. Es bietet sich aber auch an, wenn mehrere kleinere Rechner einen Kostenvorteil bieten.

Außerdem kann die Verfügbarkeit der Anwendungskomponenten durch Verteilung auf mehrere Rechner positiv beeinflußt werden. Der Einsatz eines verteilten Datenbanksystems zur Aufteilung der Daten auf mehrere, räumlich getrennte Orte, muß im Gegensatz zur Lastverteilung im Rechenzentrum das Leistungsproblem stärker berücksichtigen.

Die Datenleitung als Flaschenhals

Die Übertragungsgeschwindigkeit der Daten über die Verbindungsleitung zwischen den Rechnern beeinflußt in starkem, Maße das Zeitverhalten von verteilten Datenbanksystemen. Der Transfer über Leitungen dauert im allgemeinen um ein Vielfaches länger und verursacht zudem höhere Kosten als die Abarbeitung eines Auftrags in der Datenbank. Dieses Problem ist neben den funktionalen Einschränkungen vieler verteilter Datenbanksysteme der zweite Faktor, der die Einsatzmöglichkeiten und die größere Verbreitung von verteilten Datenbanksystemen behindert. Die Nutzung von Glasfaserverbindungen in privaten und öffentlichen Netzen kann hier in Zukunft Abhilfe schaffen. Natürlich muß das verteilte Datenbanksystem die Abarbeitung der Aufträge so optimieren, daß der Datenaustausch zwischen den beteiligten Kommunikationspartnern minimiert wird.

Dabei hat das relationale Datenmodell mit seiner Mengenverarbeitung gegenüber anderen Datenmodellen wesentliche Vorteile, da hier ein einziger Auftrag genügt, um große Datenmengen zu durchsuchen und zu ändern. Die relationale Zugriffssprache SQL unterstützt zudem viele Verarbeitungsfunktionen, so daß ein Großteil der klassischen Aufgaben des Anwendungsprogramms bereits im Datenbanksystem erfüllt werden kann. Nur das fertige Ergebnis ist dann noch über die Leitung zu schicken.

Daher kommt der Einsatz eines relationalen verteilten Datenbanksystems auch, dort in Frage, wo bisher die Anwendung selbst verteilt werden mußte, um durch Verarbeitungsleistung am entfernten Rechner die zu verschickende Menge der Daten gering zu halten. Als Faustregel gilt: Ein verteiltes Datenbanksystem ist dann sinnvoll einzusetzen, wenn nicht mehr als etwa ein Drittel der Aufträge an das Datenbanksystem entfernt abgewickelt werden muß. Verteilte Datenbanksysteme werden heute - abgesehen von der Lastverteilung - in zunehmendem Maße zur hausinternen Kommunikation benutzt, aber auch zur Kommunikation zwischen Städten.

Meist geht es jedoch um die Verknüpfung von verschiedenen Abteilungsrechnern und Mainframes im Rechenzentrum.

Als Beispiel für die geografische Verteilung von Daten soll eine Anwendung geschildert werden, bei der zudem die Replikation der Daten eine Rolle spielt. Replikation, also das doppelte Führen von Datenbeständen an verschiedenen Orten, wird in den gängigen verteilten Datenbanksystemen noch wenig angeboten. Es ist nämlich schwierig, eine generelle Lösung zu finden, die allen Ansprüchen an die Aktualität der Daten, an die Datenkonsistenz und an die Performance gerecht wird. Im folgenden Einzelfall soll eine bedarfsgerechte Anwenderlösung dargestellt werden:

Die Tiefbau-Berufsgenossenschaft mit Hauptsitz München ist ein gesetzlicher Unfallversicherungsträger, bei dem alle im Tiefbau beschäftigten Arbeitnehmer in Deutschland gegen Arbeits- und Wegeunfälle versichert werden. Um die Betreuung der Unfallverletzten bedarfsgerecht und zügig vor Ort zu gewährleisten hat das Unternehmen mehrere Gebietsverwaltungen im Bundesgebiet:

- Hannover (Gebietsverwaltung Nord),

- Berlin (Gebietsverwaltung Ost)

- Wuppertal (Gebietsverwaltung West), und

- München (Gebietsverwaltung Süd und Hauptverwaltung).

Jede Gebietsverwaltung führt auf BS2000-Mainframes ihre eigenen Datenbestände, zum Beispiel Unfallzeitpunkte, Mitglieder, Zahlungen, Unfalltermine und Mitarbeiterdaten. Damit die Hauptverwaltung und die übrigen Gebietsverwaltungen sich bei Bedarf ebenfalls dieser Daten bedienen können, werden in der Hauptverwaltung Replikate der dezentralen Datenbestände geführt. Die Gebietsverwaltungen sind mit der Hauptverwaltung über ein Datex-P-Netz (9600 Bit/sec) verbunden. Die dezentral anfallenden Änderungen werden nur einmal täglich via Filetransfer im zentralen Datenbestand aktualisiert. Auf diese Weise lassen sich die Übertragungszeiten kurz halten und die Anzahl der Verbindungen minimieren.

Seit 1989 eine eigene DV-Abteilung

Der Benutzer in einer Gebietsverwaltung braucht sich keine Gedanken darüber zu machen, ob die gewünschten Daten lokal oder entfernt in München geführt werden. Er hat lediglich anzugeben, was er suchen will. Die Tatsache, daß einige Aufträge nach München an der sehen, merkt er allenfalls etwas längeren Antwortzeit.

Der zentrale Datenbestand in München hat einen Umfang von 760 MB, die dezentralen Datenbestände liegen bei 36 bis 74 MB.

Die einzelnen Datenbanken bestehen aus bis zu 550 000 Sätzen. Es sind, insgesamt 198 Datensichtstationen angeschlossen, zusätzlich 23 emulierte PC.

Die Anzahl der Transaktionen an einen willkürlich gewählten Tag, dem 27. April 1992 zeigt die Tabelle.

Die Antwortzeit für eine lokale Transaktion liegt in München in 98 Prozent aller Fälle unter einer Sekunde. Die Antwortzeit für eine entfernte Transaktion von Hannover nach München betrug am 27. April je nach Art der Suchfrage zwischen 1,7 und 88 Sekunden, bei den vergleichbaren lokalen Transaktionen zwischen 1,7 und 3 Sekunden.

Die Tiefbaugenossenschaft besitzt seit 1989 eine eigene DV-Abteilung. Die Anwendungen wurden erstellt mit DRIVE, einer Sprache der vierten Generation, auf Basis des relationalen verteilten Datenbanksystems SESAM und des Transaktionsmonitors UTM. Mit nur acht Mannmonaten wurden 70 Programme erstellt (150 sind es heute). Nach halbjährigem Testbetrieb läuft das Verfahren seit Januar 1989 im Produktivbetrieb. Verteilte Datenbanksysteme sind also keine Zukunftsmusik, sondern bei vielen Anwendern schon Realität. Der immer stärkere Ausbau der privaten und öffentlichen Netze und der zunehmende Komfort der öffentlichen Kommunikationsdienste wird diesen Trend beschleunigen.