Von Frank Reichart*

Die Technologie der verteilten Datenbanken existiert bei den Mainframes schon seit Mitte der 80er. Vor einigen Jahren zogen auch die Hersteller von Unix-Loesungen nach. Bei allen stellt sich die Frage nach ihrem sinnvollen Einsatz. Lastverteilung im Rechenzentrum und Anpassung an die Unternehmensorganisation sind die primaeren Gruende fuer Datenverteilung.

Ein verteiltes Datenbanksystem erlaubt der Anwendung Zugriff und Bearbeitung lokal und entfernt gespeicherter Daten. Die Applikation merkt dabei von der Verteilung nichts (Transparenz). Jede Datenbank bleibt eine eigenstaendige Einheit, die sich auch nach Wegfall der Rechnerverbindungen lokal weiterbearbeiten laesst (lokale Autonomie).

Im Rechenzentrum liegen Cluster im Trend

Mainframe-basierte Datenbanksysteme ermoeglichen den Zugriff und auch das Update auf verteilte Datenbanken seit Mitte der 80er Jahre, etwa "Sesam" und "UDS" unter BS2000. Seit etwa drei Jahren bieten auch die meisten im Unix-Markt dominierenden Datenbankloesungen wie Informix und Oracle diese Technologie an.

Generell gibt es zwei Gruende fuer den Einsatz verteilter Datenbanken: die Bewaeltigung von Kapazitaetsengpaessen und organisatorische Gesichtspunkte.

Wenn im Rechenzentrum ein Rechner an seine Kapazitaetsgrenze stoesst, werden die Daten auf mehrere Datenbanken und auf verschiedene Rechner verteilt. Die Verteilkomponente des Datenbanksystems vermittelt der Anwendung dabei den Eindruck, dass es sich um einen logischen Datenbestand handelt. Hier geht der Trend zu Cluster- Architekturen: Mehrere ueber hochperformante Verbindungen gekoppelte Rechner greifen auf eine physikalische Datenbank zu. Beispiele sind Hiplex- (SNI) und Parallel-Sysplex-Cluster (IBM) sowie das Datenbanksystem Parallel Server von Oracle.

Ist die Anpassung der Datenorganisation an die Unternehmensstruktur (Zentrale, Filialen, Werke etc.) das Ziel, werden die Daten dort abgelegt, wo man sie vorrangig benoetigt. Unter entsprechenden Bedingungen und bei einer gut implementierten Verteilung reduziert sich der Kommunikations-Overhead gegenueber einer rein zentralen Datenhaltung deutlich. Dies wirkt sich auch positiv auf die Verfuegbarkeit aus, da die lokalen Daten beim Ausfall der Netzverbindung weiterhin zur Verfuegung stehen. Voraussetzung ist jedoch, dass sich die Daten wirklich regional aufteilen lassen, und der Zugriff oder Abgleich mit entfernt gespeicherten Daten einen bestimmten Umfang nicht uebersteigt. Als grobe Faustregel gilt: Eine verteilte Loesung ist dann sinnvoll, wenn sich nicht mehr als etwa ein Drittel der Abfragen an entfernte Datenbanksysteme richtet.

Allerdings beeinflusst die Uebertragungsgeschwindigkeit zwischen den Rechnern das Zeitverhalten von verteilten Datenbanksystemen (VDBS) stark. Durch neue Technologien im WAN-Bereich, etwa ATM und Breitband-ISDN, wird sich diese Performance-Problematik sicherlich etwas entschaerfen, die komplexen administrativen und planerischen Probleme bleiben aber dennoch bestehen. Zudem sind die Kommunikationsgebuehren zu beachten.

Oftmals haben separate Bereiche und Abteilungen ueber Jahre hinweg ihre eigene Datenbank aufgebaut. Werden diese miteinander verknuepft, laesst sich unter Umstaenden der Informationsfluss verbessern und die Produktivitaet steigern. Voraussetzung ist jedoch, dass ueberall das gleiche Datenbanksystem eingesetzt wird; heterogen verteilte Datenbanken sind mangels am Markt akzeptierter Standards bisher kaum moeglich. Eine Ausnahme bilden Gateway- Loesungen, die gegenueber solchen Umgebungen aber funktional und leistungsmaessig eingeschraenkt sind.

Der Einsatz verteilter Datenbanken stellt besondere Anforderungen an das Datenbanksystem:

Damit die Anwendungsprogramme von der Verteilung unberuehrt bleiben, duerfen sich die Formulierung eines Auftrags an das Datenbanksystem und die Identifizierung der Datenobjekte wie Datenbank- und Tabellennamen nicht vom lokalem Zugriff unterscheiden. Diese Eigenschaft nennt man Ortsunabhaengigkeit oder Ortstransparenz.

Beim Schreibzugriff auf verteilte Datenbanken duerfen, damit der Datenbestand konsistent bleibt, nicht abgeschlossene Transaktionen im Falle von Netzunterbrechungen und Rechnerausfaellen nicht zurueckgesetzt werden. Das Datenbanksystem muss also eine netzweite Transaktionssicherung gewaehrleisten. Bei der Datenkonsistenz handelt es sich um die Hauptanforderung an verteilte Datenbanken, deshalb sollte das Datenbanksystem diesbezueglich schon eine entsprechende Praxisreife bieten.

Im Mehrbenutzerbetrieb ist es moeglich, dass mehrere Transaktionen gleichzeitig den gleichen Datensatz aendern wollen. Da dies zu inkonsistenten Daten fuehren wuerde, kann jeweils nur eine Transaktion Aenderungen durchfuehren, waehrend der Datensatz fuer die anderen gesperrt ist. Wenn sich Transaktionen dabei gegenseitig blockieren und deshalb nicht abgeschlossen werden, spricht man von einem Deadlock. Diese Situationen zu erkennen und aufzuloesen ist bei verteilten Loesungen von besonderer Bedeutung, da eventuell die Betriebsmittel gleich mehrerer Datenbanksysteme blockiert werden.

Verteilte Datenbanken muessen ein Netz effizient nutzen, da bei hohen Transaktionsraten ein Engpass auftreten kann. Ebenso entstehen bei gebuehrenpflichtigen Leitungen hohe Kosten. Deshalb ist eine Funktionalitaet gefordert, mit der sich die Dateien und auch die Kommunikation gebuendelt ueber das Netz transportieren lassen.

Das Datenbanksystem sollte sowohl eine zentrale als auch eine dezentrale Administration zulassen. Befinden sich die VDBs zum Beispiel auf Systemen im Rechenzentrum, kann eine zentrale Verwaltung durchaus effizienter sein. Dagegen ist es bei raeumlich verteilten Datenbanken oft sinnvoller, auf eine zentrale Steuerung zu verzichten, um bei einem Netzausfall mit den lokalen Daten weiterarbeiten zu koennen.

Es sollten sich ressourcenstarke Rechner einsetzen lassen, da insbesondere bei OLTP-Anwendungen viele Benutzerauftraege parallel ausgefuehrt werden. Dabei kommt es nicht nur auf die Prozessor- Power an. Ein klassischer Fehler ist, dass nur Performance- Benchmark-Werte betrachtet und dem Preis des Rechnersystems gegenuebergestellt werden, etwa Dollar/tps. Speziell bei grossen Datenbankanwendungen ist die Systemleistung jedoch nur einer von vielen Parametern. Ein adaequat eingesetzter Datenbank-Server muss neben einer entsprechenden Rechenleistung folgendes bieten:

- die Moeglichkeit, grosse Datenmengen zu speichern und schnell darauf zugreifen zu koennen;

- hohen Datendurchsatz;

- hohe Ausfallsicherheit und Verfuegbarkeit;

- effiziente Sicherungsverfahren mit hoher Kapazitaet;

- eine komfortable und weitgehend automatisierte Systemadministration bis hin zum RZ-Betrieb;

- die Moeglichkeit zur grossen Stapelverarbeitung (Batch) sowie

- einen leistungsfaehigen Transaktionsmonitor fuer den OLTP-Betrieb.

Wie die oben genannten An-

forderungen von einem Datenbanksystem technisch realisiert werden, soll am Beispiel des relationalen Datenbanksystems "Sesam/SQL- Server" von Siemens-Nixdorf aufgezeigt werden. Bei etwa 20 Prozent der Sesam-Installationen wird die Verteilkomponente Sesam-DCN bereits produktiv genutzt.

Datenkonsistenz mit Hilfe von Two-Phase-Commit

Eine Verteiltabelle verwaltet die Informationen, welche Datenbank auf welchem Rechner liegt und wie sich diese erreichen laesst. Die Verteilungsregeln sind im laufenden Betrieb aenderbar. Die Verteilung erfolgt fuer das Anwendungsprogramm transparent. Anweisungen an die Datenbank sind beim lokalen und entfernten Rechner gleich. Das Anwendungsprogramm muss also nicht geaendert werden.

Damit die Transaktionssicherung auch im Fall der Verteilung besteht, wird eine globale Transaktion in Untertransaktionen aufgesplittet, die auf den einzelnen Rechnern ausgefuehrt werden. Die Synchronisation der Untertransaktionen erfolgt dabei durch das sogenannte Two-Phase-Commit-Protokoll. Beim Abschluss der Transaktion muessen die beteiligten Datenbanksysteme die Untertransaktion entweder abschliessen oder zuruecksetzen. Diese erste Phase nennt man Prepare to Commit. Nur wenn alle Partner zusichern, dass sie ihre Transaktion durchfuehren koennen, werden sie im zweiten Schritt aufgefordert, diese zu beenden. Andernfalls werden alle Untertransaktionen auf allen beteiligten Rechnern zurueckgesetzt. Das Two-Phase-Commit-Protokoll sorgt so fuer eine netzweite Datenkonsistenz.

Probleme koennen jedoch entstehen, wenn beteiligte Rechner ausfallen. Das Datenbanksystem muss daher ueber Mechanismen verfuegen, um solche Situationen zu bewaeltigen. Das Anlegen globaler Sicherungsdaten ermoeglicht einen Wiederanlauf, wenn in der ersten Phase das System ausfaellt, das gerade die globale Koordinationssteuerung durchfuehrt. Eine weitere Schwierigkeit tritt auf, wenn in der zweiten Phase des Protokolls die Partner zum endgueltigen Beenden oder Ruecksetzen der Transaktionen aufgefordert werden, aber nicht alle Rechner erreichbar sind. Der Sesam/SQL-Server hat fuer diesen Fall ein Mailbox-Verfahren entwickelt, das sicherstellt, dass sich solche Auftraege spaeter nachholen lassen.

Jedesmal, wenn eine Transaktion auf eine Sperre laeuft, wird ueberprueft, ob dadurch ein Deadlock ausgeloest wurde. Ueber die Netzwerkkomponente steht diese Funktion auch bei verteilten Datenbanken zur Verfuegung. Gegenueber der Timer-Loesung bietet dieses Prinzip den Vorteil, dass eine Transaktion nur bei einer wirklichen Deadlock-Situation zurueckgesetzt wird und nicht, weil ein Timer wegen hoher Netzlast abgelaufen ist.

Durch den Schubmodus nutzen verteilte Datenbanken das Netz wesentlich effizienter: So werden beim Zugriff auf mehrere Datensaetze einer entfernten Datenbank die Ergebnisse gebuendelt zurueckgeliefert. Dadurch reduziert sich der Netzwerk-Overhead, was den Durchsatz speziell bei hohen Transaktionsraten steigern kann.

Die Moeglichkeit, auf verteilte Datenbanken zuzugreifen, wird heute von mehreren Datenbanksystemen angeboten. Dabei bestehen zum Teil noch grosse Unterschiede im technischen Reifegrad. Trotz innovativer Technologie ist die Implementierung verteilter Datenbanken jedoch nicht trivial.

* Frank Reichart ist im Marketing Datenbanken der BS2000-Unit der Siemens-Nixdorf Informationssysteme AG in Muenchen beschaeftigt.