Da die entscheidenden Informationen im Unternehmen heute nur noch über die DV verfügbar sind, müssen alle Unternehmensbereiche, auch räumlich getrennte, voll in die DV integriert sein. Dies führt zu Situationen, in denen eine rein zentrale Datenhaltung oder eine lokale Partitionierung nicht optimal ist, weil damit eingeschränkte Verfügbarkeit oder erhebliche Kommunikationskosten verbunden sind.

Neben Performance- oder Kapazitätsproblemen können auch organisatorische Gründe für eine verteilte Datenhaltung sprechen. Neuere betriebswirtschaftliche Entwicklungen, die zu selbständigen Teilunternehmungen führen, wie Profit-Center oder Lean Management, implizieren die Verteilung von Informationen. Dazu kommt die wachsende Nachfrage nach entscheidungsunterstützenden Informationssystemen, beispielsweise in Data-Warehouse-Konzepten.

Mit der Verteilung der Daten ergibt sich aber das Konsistenzproblem, um konsistente Daten zu erhalten, hatte man ja die zentrale Datenhaltung "erfunden". Das Dilemma "verteilt und dennoch konsistent" versucht die Replikation zu lösen. Je nach Situation, Aufgabenstellung und technischen Möglichkeiten wird die Lösung immer anders ausfallen. Schließlich bleibt unterm Strich immer ein Restproblem, eine wenn auch noch so kleine Konsistenzlücke, was aber nur logisch ist, denn vollständige Konsistenz bedeutet eben zentrale Datenhaltung, und hier ist Replikation überflüssig.

Technisch gesehen handelt es sich bei der Replikation zunächst um das Kopieren von Tabellenschemata und Daten einer Quelldatenbank in eine Zieldatenbank. Im Grunde stellt jeder Download, jede Kopie einer Excel-Tabelle von einem Server auf die lokale Platte eine Replikation dar. Obwohl solche Operationen zu redundanten Daten führen und jede weitere Änderung zu nicht mehr konsistenten Daten, sind sie in der Praxis häufig, denn derartige "Ad-hoc-Replikationen" haben auch ihre Vorteile:

-Verfügbarkeit von Daten: Werden etwa Preisinformationen und Kundendaten auf ein Notebook repliziert, so kann ein Vertriebsmitarbeiter vor Ort mit diesen Informationen arbeiten, ohne online mit dem Firmen-Server verbunden zu sein.

-Geringere Netzbelastung: Liegen häufig benötigte Daten lokal vor, so können sie ohne Netzzugriff gelesen und verwendet werden. Damit steigt die Performance, und die Kommunikationskosten sinken.

-Sicherheit: Werden wichtige Daten repliziert, sind sie durch Redundanz sicherer.

Die Nachteile sind jedoch die gleichen wie bei jedem Kopieren von Dateien: Änderungen an der Kopie werden entweder nicht berücksichtigt oder müssen von Hand in das Original eingearbeitet werden.

Der Replikationsvorgang versucht, diesen Schritt zu automatisieren, da der Ursprung der Änderungen bekannt ist. Das heißt, bei einer Replikation erfolgt im Gegensatz zum einfachen Kopieren ein Datenabgleich. Solange keine Konflikte durch Änderungen desselben Datensatzes an Original und Kopie enstehen, kann der Abgleich durch die Replikation geschehen. Bei Konflikten können Regeln zur Auflösung angegeben werden. Lassen sich Konflikte nicht auflösen, werden sie in einem Protokoll für eine manuelle Nachbearbeitung erfaßt.

Die Replikation kann entweder synchron oder asynchron erfolgen. Synchron bedeutet, daß die Quelle (Verleger) und alle Empfänger von Daten (Abonnenten) immer synchron sind. Nach einem Commit durch den Anwender besitzen Verleger und Abonnent immer den gleichen Datenbestand. Bei der Verwendung eines Servers sind die Transaktionen nach diesem Schema ausgelegt. Nach einem Commit sind alle Änderungen entweder sicher geschrieben, oder es wurde nichts geändert. So kann es bei einer synchronen Replikation nicht dazu kommen, daß ein Abonnent nicht den gleichen Stand wie der Verleger hat. Da bereits der Ausfall eines Abonnenten das System blockieren würde, gibt es Abstufungen innerhalb dieses Konzeptes. So kann es reichen, daß die Mehrzahl der Abonnenten verfügbar ist oder daß es nur auf bestimmte Abonnenten ankommt.

Die synchrone Replikation setzt jedoch eine hohe Verfügbarkeit des Transportmediums voraus (in der Regel das Netzwerk). Aus diesem Grund eignet sich die synchrone Replikation nur für eng gekoppelte Systeme.

Asynchrone Replikation bedeutet immer einen Zeitverzug zwischen der Änderung und dem Kopieren der Daten. Beim Verleger werden alle Änderungen gespeichert und zum Synchronisationszeitpunkt an die Abonnenten weitergegeben. Dieser Zeitpunkt kann sowohl vom Verleger als auch vom Abonnenten bestimmt werden. Wählt der Abonnent den Zeitpunkt, so ist es ausreichend, wenn er nur zum Replikationszeitpunkt, den er selbst bestimmen kann, mit dem Verleger verbunden ist.

Der Abonnent kann entweder permanent oder nur zeitweise verfügbar sein. Die permanente Verfügbarkeit ist eine Voraussetzung für die synchrone Replikation. Centura beispielsweise bietet eine asynchrone Replikation, wobei die Abonnenten nur für den Vorgang der Replikation eine Verbindung zu dem Verleger haben müssen. Diese Variante ist insbesondere für Notebooks geeignet, die sich lediglich für eine Replikation mit der Verlegerdatenbank verbinden.

Natürlich können auch mehrere Server innerhalb eines Netzes eine Replikation vornehmen. Sie kann allerdings nur von einem Abonnenten über den Replication Synchronization Agent (RSA) angestoßen werden. Der RSA kann in eine Applikation eingebettet werden, so daß ein einfacher Mausklick die Replikation starten kann. Es wäre denkbar, daß über Datenbankereignisse (events) und gespeicherte Prozeduren eine Replikation auch ganz ohne Clients vorgenommen wird.

Datenänderungen, die repliziert werden, müssen bis zum Replikationszeitpunkt protokolliert werden. Das kann in einer Log-Datei geschehen, die ohnehin geschrieben wird, oder durch Speicherung der entsprechenden SQL-Befehle. Im ersteren Fall lesen spezielle Log-Reader die Datei aus und kopieren Teile daraus zum Abonnenten. Obwohl dies ein sehr schnelles und den Server wenig belastendes Verfahren ist, kann nur innerhalb eines Produktes repliziert werden.

Da bei SQL-Datenbanken alle Datenänderungen über SQL-Befehle ausgeführt werden, ist es ausreichend, genau diese Befehle zu speichern, bei der Replikation zu kopieren und danach beim Abonnenten umzusetzen. Hält man sich an den ANSI-Standard (der für insert, update und delete ausreicht), so kann auch gegen Fremddatenbanken repliziert werden. Die Datenbanken werden einfach um zusätzliche Tabellen erweitert, die sämtliche Informationen für die Replikation beinhalten.

Die Varianten der Replikation

Da in beiden Fällen Daten zuerst gespeichert und später repliziert werden, nennt man diese Verfahren auch "store and forward".

Die Groupware "Lotus Notes", die 1989 eingeführt wurde, bietet ein Beispiel für eine Replikation. Hier werden zwischen einzelnen Rechnern Dokumente gespeichert und kopiert. Das Konzept dafür wurde bereits 1975 erstellt.

SQL-Base von Centura kann nicht nur innerhalb von eigenen SQL-Base-Datenbanken replizieren, sondern auch gegen Fremddatenbanken wie Oracle.

Zwischen den Replikaten kann es mehrere Beziehungen geben. Im einfachsten Fall werden von einer Datenbank Änderungen in eine zweite kopiert. Bei dieser Master-Slave-Architektur wird der Master auch Verleger und der Client Abonnent genannt. Daten werden nur vom Verleger zum Abonnenten repliziert.

Verlegerdatenbanken können aber auch als Abonnenten arbeiten. In diesem Falle ist es eine Master-Master-Architektur. Trotzdem werden bei einer Replikation immer Daten vom Verleger zum Abonnenten kopiert, so daß die Datenbanken zuerst Verleger, dann Abonnenten und umgekehrt sind. Bei manchen Herstellern gibt es spezielle Verteilungs-Server, die die Arbeit der Replikation zu mehreren Abonnenten übernehmen und somit den Verleger entlasten.

Replikation am Beispiel von SQL Base

Die Planung der Replikation umfaßt folgende Punkte:

- welche Daten und Objekte repliziert werden sollen,

- Datenfluß zwischen den Abonnenten und den Verlegern sowie

- Regeln für die Auflösung von Konflikten.

Dabei wird festgelegt, welche Benutzer welche Daten und Objekte erhalten. So erhalten zum Beispiel Vertriebsmitarbeiter nur Verkaufsinformationen, während Vertriebsleiter auch Personalinformationen repliziert bekommen. Um die Replikations-Performance zu verbessern, sollte man die Menge der Daten beschränken; standardmäßig ganze Datenbanken zu replizieren ist kein guter Ansatz. Um die Menge der Daten zu begrenzen und somit einen Performance-Gewinn zu haben, können die Basistabellen sowohl horizontal als auch vertikal partitioniert werden. Die horizontale Partitionierung entspricht einer Zeilenauswahl durch einen Select-Befehl, die vertikale einer Spaltenauswahl.

Außerdem müssen auch die Richtung der Replikation und die Rechte festgelegt werden. Im einfachsten Fall werden vom Verleger Daten zum Abonnenten kopiert.

Der Abonnent hat keine Möglichkeit, zwischenzeitlich seine lokalen Änderungen auch beim Verleger vorzunehmen. Falls auf der Seite des Verlegers die Datensätze ebenfalls lokal geändert wurden, so sind nach der Replikation die davor gemachten lokalen Änderungen auf dem Abonnenten auch überschrieben. Der Vorteil dieser Variante liegt in der Konfliktfreiheit. Falls Daten ebenfalls von dem Abonnenten an den Verleger weitergegeben werden, wird eine Zwei-Wege-Verbindung erstellt. Diese erlaubt, daß DML-Befehle (insert, update, delete) an beiden Stationen ausgeführt werden.

Alle Tabellen, deren Spalten repliziert werden, bezeichnet man als Replication Set. Zuständig für die Definition ist das Replication Management System, kurz RMS genannt.

Der Zeitpunkt der Replikation ist ebenfalls wichtig. In Spitzenzeiten kann sie ausgeschaltet werden. Ansonsten bestimmt bei Centura der Abonnent den Zeitpunkt der Replikation, nicht der Verleger.

Beim Verleger kann zusätzlich bestimmt werden, wie geänderte Daten bis zur Replikation gespeichert werden. Einerseits werden Datenänderungen über Trigger abgefangen und in spezielle Tabellen geschrieben. Diese Variante wird bei dem Abonnenten grundsätzlich verwendet und als "Delta"-Methode bezeichnet. Andererseits kann in der Verlegerdatenbank ein vollständiges Erneuern von Tabellen angegeben werden. Je nach Partitionierung werden bei der Replikation ganze Tabellen oder nur Teile davon kopiert. Bei dieser Variante werden keine Trigger benötigt.

Festlegen der Transaktionskonsistenz

Grundsätzlich wird eine Replikation als eine Transaktion aufgefaßt, das heißt entweder werden alle für die Replikation vorgesehenen Daten repliziert oder eben gar nichts. Dadurch kann es nicht vorkommen, daß eine Replikation durch beispielsweise einen Verbindungsabbruch nicht alle Daten oder bei einem erneuten Versuch Daten doppelt repliziert.

Allerdings kann bestimmt werden, wie Änderungen vom Abonnenten zum Verleger gelangen: zeilenweise oder gruppiert. Der Unterschied besteht darin, daß bei zeilenweiser Übertragung abgewiesene Zeilen (zum Beispiel wegen eines Konflikts) nicht übertragen, alle weiteren Zeilen aber beim Verleger eingespielt werden, was aber zu Integritätsproblemen führen kann. Gruppierte Übertragung dagegen bedeutet, daß entweder alle Zeilen oder keine angenommen werden. Abgewiesene und damit nicht übertragene Zeilen gibt es nicht und damit auch keine Integritätsprobleme.

Zu Konflikten kann es kommen, wenn redundante Daten an zwei Stellen geändert werden. Die Replikationsmechanismen müssen hier selbst Möglichkeiten zur Lösung anbieten, denn ansonsten könnte man mit "downloads" die Replikation nachbilden. Dies führt aber zu dem Problem, daß der Empfänger weiterarbeitet, gleichzeitig aber auch der Sender.

Prinzipiell ist die Konfliktvermeidung die bessere Lösung als die Konfliktauflösung. Konflikte werden vermieden, indem bei der Programmierung diese Gegebenheiten berücksichtigt werden. Dabei darf nur eine Station Daten ändern, alle anderen jedoch nur lesen. Weitere Möglichkeiten sind die Festlegung der Übertragungsrichtung: etwa immer nur vom Verleger zum Abonnenten, aber nicht zurück. Falls der Abonnent dennoch Daten zum Verleger übertragen darf, kann dies auf das Einfügen neuer Zeilen beschränkt werden, was immer konfliktfrei geschehen kann. Weiterhin besteht die Möglichkeit, Tabellen horizontal zu partitionieren. So kann beispielsweise ein Vertriebsmitarbeiter nur Daten eines bestimmten Postleitzahlengebietes bearbeiten.

Treten durch gleichzeitige Änderungen von Datensätzen sowohl beim Verleger als auch beim Abonnenten Konflikte auf, können Regeln zu deren Lösung angegeben werden. Dabei können Prioritäten vergeben werden: entweder werden immer die Änderungen des Verlegers oder die des Abonnenten berücksichtigt; eine der Änderungen geht hier auf jeden Fall verloren. Bei Spaltenaggregation werden Änderungen von allen Abonnenten angenommen. Anstatt einen Konflikt zu erzeugen, wird der neue (numerische) Wert dieser Spalte berechnet.

Problematisch sind Fälle, bei denen Änderungen (auf beiden Seiten) nicht verlorengehen dürfen. Diese Fälle werden in einem Fehler-Report aufgelistet und müssen per Hand nachbearbeitet werden.

Initialisierung der Replikation

Bevor eine Replikation erfolgen kann, muß der Abonnent initialisiert werden. Bei Centura wird dies durch den Replication Synchronization Agent (RSA) durchgeführt. Der RSA ist ein Client-Programm, das bei jedem Abonnenten verfügbar ist. Es gibt ihn auch als OLE-2-Version, so daß eine Synchronisation direkt in das eigene Programm eingebaut werden kann.

Zuerst werden bei dem Abonnenten sämtliche Tabellen mit Primärschlüssel kopiert, die beim Verleger zu dem Replication Set gehören. Vorhandene Tabellen können dabei überschrieben werden.

Es gibt die Möglichkeit vor und nach dem Initialisierungsschritt (SQL-Talk-)Skripte anzulegen, die spezielle Aufgaben übernehmen. Somit können auch Objekte wie Trigger in dieser Phase bei dem Abonnenten initialisiert werden.

Datenabgleich oder Synchronisation

Jeder Sychronisationsvorgang wird durch den Client gestartet. Dabei werden alle Datenänderungen (aus dem Replication Set) zu dem Verleger kopiert. Treten keine Konflikte auf, werden die Datenänderungen in die entsprechenden Tabellen eingetragen. Bei Konflikten werden die Datenänderungen in einer Konfliktliste erfaßt. Anschließend werden alle Änderungen vom Verleger zum Abonnenten kopiert und auf Konflikte überprüft.

Auch die Synchronisation sollte sorgfältig geplant sein, denn die Netzwerkbelastung nimmt erheblich zu, falls mehrere Abonnenten gleichzeitig synchronisieren wollen. Auch die Belastung der Verlegerdatenbank ist hoch, da alle Änderungen zuerst einmal verglichen und anschließend zu dem Abonnenten kopiert werden müssen.

Angeklickt

Bei einer Replikation erfolgt im Gegensatz zum Kopieren ein Datenabgleich. Sie kann synchron oder asynchron erfolgen. Synchrone Replikation erfordert hohe Verfügbarkeit des Transportmediums, asynchrone bedeutet immer Zeitverzug, doch ist sie für Notebooks geeignet. Da bei SQL-Datenbanken alle Datenänderungen über SQL-Befehle ausgeführt werden, ist es ausreichend, genau diese Befehle zu speichern, bei der Replikation zu kopieren und dann umzusetzen.

*Jürgen Durban ist Geschäftsführer des Systemhauses Durban Informatik GmbH in Karlsruhe.