Wenn gewährleistet sein muß, daß alle Anwender zu jedem Zeitpunkt mit identischen Daten arbeiten, kommt als Lösung nur eine zentrale Datenbank in Frage. Sind bei einer solchen Lösung noch ältere Datenbank-Management-Systeme (DBMS) wie IMS, CA/ IDMS - oder noch schlimmer - eine Sammlung von VSAM-Dateien im Einsatz, dfrfte es allerdings sehr schwierig, wenn nicht gar unmöglich sein, auf einer solchen Datenbank gleichzeitig OLTP-Anwendungen (Online Transaction Processing) und Decision-Support-Anwendungen zu fahren, ohne dabei signifikante Performance-Verluste in der Transaktionsverarbeitung zu erleiden.

Diese DBMS bieten weder von ihrem Design her ausreichende Antwortzeiten, noch sind sie für flexible interaktive Abfragesysteme entwickelt worden. Um dennoch den Benutzeranforderungen nach flexiblen Decision-Support- und Management-InformationsSystemen (DSS/EIS) gerecht zu werden, kann eine zweite Datenbank mit replizierten Daten der OLTP-Datenbank aufgebaut werden. So bleibt die zeitkritische OLTP-Datenbank von zusätzlichen Belastungen unberührt.

Trotz allem schränken zentrale Datenbanken die Handlungsfähigkeit eines Unternehmens unter Umständen erheblich ein, da die Verfügbarkeit der Daten extrem durch Netzwerkprobleme, Netzwerkverzögerungen oder Systemausfälle beeinträchtigt werden kann. Ganz abgesehen von den Netzwerkkosten einer solchen Konstellation.

Steigt nun die Anzahl der Benutzer oder nimmt das Datenvolumen sehr stark zu, kommt es nicht selten zu Skalierungsproblemen. Eine Lösung hierzu bieten heute moderne parallele Datenbankarchitekturen in Verbindung mit kosteneffizienten Mehrprozessorsystemen.

Wenn eine zentrale Datenhaltung keine optimale Lösung darstellt, wie sieht es dann mit Partitionierung der Daten in Verbindung mit verteilten Datenbanktechnologien aus?

Verteilte Datenbanken bieten dann eine gute Alternative, wenn größtenteils auf Daten eines lokalen Servers zugegriffen wird und nur in Ausnahmefällen Daten anderer Server benötigt werden beziehungsweise Updates auf mehreren Servern gleichzeitig gefahren werden müssen. Werden nun Tabellen in Partitionen aufgeteilt und diese nach logischen Aspekten über die jeweiligen Server verteilt, lassen sich einerseits die Kommunikationskosten erheblich reduzieren, und andererseits sind die erforderlichen Daten lokal für den Anwender verfügbar.

Leider sind verteilte Datenbanken bis heute trotz allem keine kosteneffiziente Lösung für Anwendungen, die regelmäßig auf mehrere Datenbank-Server zugreifen. Außerdem ist der zusätzliche Administrationsaufwand nicht unerheblich. Ein Datenverteilungskonzept muß erstellt und gepflegt werden, Netzwerk- und Datenbankspezialisten müssen verteilte Datenbanken im Hinblick auf Performance, Netzwerkkosten und -geschwindigkeit optimieren.

Systemdesigner müssen ihr Augenmerk vor allem auf Abfragen richten, die Joins über mehrere Datenbank-Server herstellen. Joins, die auf einem zentralen Datenbank-Server vielleicht nur Minuten dauern, verursachen bei mehreren solcher Systeme unter Umständen das "Schaufeln" von Megabytes an Daten, vielleicht sogar noch über ein langsames WAN, was zu Antwortzeiten im Stundenbereich führen kann.

Letztendlich ist die Verfügbarkeit der Daten wie in einem zentralen System von der Zuverlässigkeit des Netzwerks und aller beteiligten Server abhängig.

Werden Daten in Form von Kopien auf den entsprechenden Servern bereitgestellt, also auf mehrere Server repliziert, können viele der Probleme zentraler und verteilter Datenhaltung gelöst werden. Die Verfügbarkeit der Informationen läßt sich erheblich verbessern, da die Zuverlässigkeit des Netzwerks kein kritischer Faktor mehr ist. Alle Daten sind lokal vorhanden, so entstehen keine weiteren Kommunikationskosten. Auch die Antwortzeiten werden erheblich verbessert, da keine Daten in Echtzeit über das Netz geschaufelt werden müssen und alle Joins lokal ausführbar sind.

Da nun Anwender, Daten und Abfragen über mehrere Rechner verteilt sind, ist in den meisten Fällen auch das Skalierungsproblem gelöst. Nicht selten läßt sich auch der Zugriff auf Informationen vereinfachen und somit eine bessere Performance erzielen, da eine replizierte Datenbank oft auch Daten unterschiedlichster Herkunft und Quellen zusammenfaßt.

In vielen Fällen reicht es aus, nur Teilmengen der ursprünglichen Tabelle - selektierte Zeilen oder Spalten - zu replizieren. Zum Beispiel kann eine Kundentabelle so aufgeteilt werden, daß den einzelnen Geschäftsstellen, die Dienste für einen jeweils spezifischen Kundenstamm anbieten, nur diese Daten lokal zur Verfügung stehen. Auf verschiedene Arten lassen sich auch Replikationen erzeugen, die auf abgeleiteten Daten basieren. So ist es möglich, etwa kummulierte Kosten oder Umsatzwerte der einzelnen Niederlassungen in einer Umsatztabelle ffr die Zentrale anzubieten.

Es gibt die unterschiedlichsten Verfahren, Daten zu replizieren. Entscheidend für die Auswahl einer Methode ist die Zeit, in der die Informationen synchronisiert werden sollen. Müssen alle Kopien immer denselben Inhalt haben, oder können sie zumindest für eine bestimmte Zeit inkonsistent sein? Welche Zeitspanne ist akzeptabel? Die Beantwortung dieser Frage ist entscheidend, da die Problematik synchroner Updates die Vorteile der Replikation durchaus zunichte machen kann.

Die Länge des Intervalls während dem die Kopien inkonsistent sind, wird als "Lag" bezeichnet. Wenn das Lag null ist, werden die Kopien gleichzeitig aktualisiert ist das Lag größer als null, erfolgt die Aktualisierung asynchron.

Um ein synchrones Update zu gewährleisten, muß man nicht nur die primäre Kopie der Daten schützen, sondern auch alle Re-plikationen. Außerdem benötigt man ein Protokoll für Zugriffssperren wie zum Beispiel ein Two-Phase-Commit, um sicherzustellen, daß alle Kopien immer übereinstimmen. Und schließlich müssen alle zu replizierenden Server immer verfügbar sein, um Änderungen wirksam werden zu lassen.

Folglich sind synchrone Updates nur dann sinnvoll, wenn ein sehr schnelles Netzwerk existiert oder die Anzahl der gleichzeitigen Updates klein genug ist, um die Geduld der Anwender nicht zu sehr zu strapazieren. Sonst ist die asynchrone Replikation wesentlich vorteilhafter. Für die meisten Anwender sind zeitlich versetzte Updates ausreichend, da gewisse Verzögerungen keine Probleme bereiten.

Bessere Verfügbarkeit und Performance

Um das Lag möglichst gering zu halten und gleichzeitig die Nachteile synchroner Updates zu umgehen, müssen Änderungen an die Replikate weitergeleitet werden, sobald sie auf dem Master durchgeführt wurden - nach dem Commit. In diesem Fall entspricht das Lag der Übertragungszeit und der Zeit, die benötigt wird, um die Änderungen aufzunehmen und weiterzuleiten. In einem LAN dauert eine solche Replikation weniger als zehn Sekunden. Auf diese Weise müssen Modifikationen auf der primären Kopie nicht repliziert werden, bevor sie als abgeschlossen gelten. Damit lassen sich die Performance und die lokale Verfügbarkeit verteilter Umgebungen erheblich verbessern.

Durch den schnellen Transfer der Daten werden selbst unternehmenskritische Anwendungen optimal unterstützt. Wenn längere inkonsistente Zustände aktzeptabel sind, können Änderungen zunächst auf dem Master gesammelt und dann periodisch an die Replikate weitergeleitet werden. Dieses Verfahren eignet sich beispielsweise ideal für Data-Warehouse-Umgebungen, in denen eine Aktualisierung der Daten in periodischen Abständen vollkommen ausreicht.

Die einfachste Form der Replikation ist eine Konfiguration, in der Änderungen nur an der Masterkopie gestattet sind, die diese an alle Replikate weiterleitet. Eine andere Variante beinhaltet die Möglichkeit, jedes Replikat zu modifizieren. Allerdings kann es bei einer solchen Konfiguration zu widersprüchlichen Updates kommen, wenn mehrere Anwender oder Applikationen Kopien ein und desselben Records gleichzeitig unterschiedlich ändern.

Diese Methode ist auch unter "Update-anywhere", beziehungsweise "Peer-to-peer-Replikation" bekannt. Typisches Beispiel ffr ein Unternehmen, das besonders von dieser Update-anywhere-Methode profitieren kann, ist ein Versandhaus mit gebührenfreier telefonischer Bestellannahme (siehe Abbildung). Hier wird jeder Anruf, je nach Tageszeit und Auslastung, an einen von zwei zuständigen Hub-Servern dirigiert.

Beide Server müssen in der Lage sein, die resultierenden Datensätze zu aktualisieren, auf dem anderen Hub-Server zu replizieren und an die Buchhaltung weiterzuleiten, sobald die Bestellung feststeht.

Die Buchhaltung wiederum muß die Rechnungsdaten für jede Bestellung aktualisieren und diese Informationen auf den Hub-Servern replizieren, für den Fall, daß Kunden ihre Bestellung ändern möchten oder Nachfragen haben. Alle diese Informationen können in vorkonfigurierbaren Intervallen an die regionalen Niederlassungen (Server) weitergeleitet werden, wo sie unter Umständen für Marketing- und Umsatz-Trendanalysen vorliegen müssen.

Bestellungen rasch weitergeleitet

In einem solchen Versandhaus ist es besonders wichtig, daß eine Bestellung, sobald sie auf dem Server Hub 1 vorliegt, schnellstmöglich auf dem Server Hub 2 repliziert und außerdem an die Buchhaltung weitergeleitet wird. Denn angenommen, ein Kunde möchte seine Bestellung ändern, so müssen alle Standorte (Server) über die aktuellsten Daten verfügen, da sonst eventuell ein nicht existierender Datensatz aktualisiert wird.

Informix hat sich mit derartigen Problemstellungen intensiv befaßt und entsprechende Mechanismen beziehungsweise Algorithmen zur Konfliktfeststellung und -lösung entwickelt. Anhand des Primärschlüssels werden die einzelnen Records miteinander verglichen. Existieren nun zu einem Record widersprfchliche Änderungen, tritt automatisch eine Konfliktauflösungsroutine in Kraft, die beispielsweise folgende Regel enthält: "Latest update wins". Mit Hilfe gespeicherter Prozeduren (stored procedure) lassen sich auch eigene Regeln definieren.

Konflikte sind ausgeschlossen

In vielen Fällen reicht es allerdings aus, Daten nur für den reinen Lesezugriff netzwerkweit auf allen Servern zu replizieren und den einzelnen regionalen Servern die Möglichkeit zu bieten, ihre eigenen "regionalen" Daten zu aktualisieren oder zu schreiben. In einem solchen Szenarium kann es nicht zu Konflikten kommen, und dennoch hat jeder Anwender lokalen Zugriff auf alle Daten. Eigentümer jeder einzelnen Dateneinheit kann ein einzelner Benutzer, eine Abteilung oder eine Region sein.

Alle Replikationsverfahren beinhalten, ungeachtet ihres Funktionsumfangs, einen Mechanismus, nach dem Änderungen aufgenommen und weitergeleitet werden. Eine effiziente Methode setzt zum Beispiel auf dem Recovery Log der Datenbank auf.

Änderungen der Daten, die für die Replikation markiert sind, werden in einen Aufbewahrungsbereich kopiert. Diese Methode, die auch als "Log Sniffing" bezeichnet wird, hat die geringste Auswirkung auf die Arbeitslast des Datenbank-Servers, da sie sehr wenig Prozessor-Leistung erfordert, nur aus dem im Hauptspeicher liegenden Log liest und die zu replizierenden Daten in spezielle Tabellen (pro Zielserver eine) schreibt, die ebenfalls im Hauptspeicher liegen.

Angeklickt

In diesem Artikel werden die Basisverfahren der Replikation und deren Auswirkungen beschrieben. Fast alle namhaften Datenbankanbieter haben sich dieses Themas angenommen, und es ist faszinierend zu sehen, wie unterschiedlich sie die damit verbundenen Probleme lösen. Letztendlich wird die Praxis zeigen, inwieweit Replikationen ein aktueller Trend, oder eine echte Notwendigkeit sind.

*Barbara Finger ist Product Manager Database Servers bei der Informix Software GmbH, Ismaning bei München.