Datenbankverwaltung: Beschleunigung mit Oracle-Replikation

Oracle-Replikation gibt es schon eine ganze Weile und hat sich zu einer ausgereiften Umgebung mit einem großen Funktionsumfang entwickelt, die alle Anforderungen an eine weiträumig verteilte Datenverarbeitung erfüllt.

Replikation war ursprünglich als eine Möglichkeit gedacht, um Oracle-Tabellen oder Subsets von Tabellen auf weit verteilten Datenbank-Servern lokal verfügbar zu machen. Erreicht wurde dies mithilfe von Schnappschüssen (also zu einem bestimmten Zeitpunkt erstellten Kopien) der gewünschten Tabellen, die von einem Master-Server auf einen oder mehrere entfernte Slave-Server kopiert wurden.

Diese Schnappschuss-Verfahren war besonders effektiv bei relativ statischen Tabellen, die keine häufigen Aktualisierungen erforderten, um mit den Master-Tabellen synchronisiert zu bleiben. Anwendungen mit ausschließlichem Lesezugriff profitierten vom Einsatz von Schnappschüssen, da zeitraubende Übertragungen im WAN überflüssig wurden, was die Performance deutlich verbesserte.

Schnappschüsse sind heute eher unter dem Begriff Materialized Views bekannt, und die Erstellung entfernter Materialized Views von Master-Tabellen ist immer noch eine gängige Verwendung der Replikation, doch inzwischen hat sich die Technologie erheblich weiterentwickelt und unterstützt eine wesentlich breitere Palette von Datenbank-Objekten. Im Folgenden soll zuerst die Schnappschuss-Methode erläutert und dann ein Überblick über die fortgeschritteneren Methoden gegeben werden.

Eine ganze Reihe von Faktoren bedingt Entscheidungen für die Tabellen-Replikation in Oracle. Besonders wichtig sind dabei die Größe der Tabelle und die Änderungshäufigkeit der Tabellendaten (Abbildung A). Kleine statische Tabellen sind ideale Kandidaten für die Schnappschuss-Replikation für entfernte Anwendungen, die nur lesend auf die Daten zugreifen, wohingegen umfangreiche dynamische Master-Tabellen mit vielen Einfügungen, Updates und Löschungen häufige Aktualisierungen erfordern, die Systeme und Netzwerk stark belasten würden. Schnappschüsse sind für solche umfangreichen dynamischen Master-Tabellen keine gute Lösung, weshalb man hier auf fortgeschrittenere Verfahren (wie weiter unten beschrieben) zurückgreifen sollte.

Abbildung A: Replikations-Alternativen, abhängig von Tabellengröße und Änderungshäufigkeit

Im Hinblick auf die System- und Netzwerk-Performance muss man beachten, welche Größe die erstellten Schnappschüsse haben und wie häufig sie erstellt bzw. aktualisiert werden müssen. Wie Abbildung A zeigt, kann man jederzeit einen Schnappschuss neu erstellen oder eine vollständige Aktualisierung durchführen. Man kann auch automatisch periodische Aktualisierungen durchführen oder bestimmte Auslöser definieren, die dafür sorgen, dass Änderungen an einer Master-Tabelle von den Slave-Schnappschüssen übernommen werden. Die folgenden Faustregeln können dabei helfen, die am besten geeignete Methode auszuwählen.