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.

Page: 1 2 3 4

ZDNet.de Redaktion

Recent Posts

Black Friday: Vorsicht vor schädlichen QR-Codes

Bösartige QR-Codes, die per E-Mail versendet werden, eignen sich sehr gut, um Spam-Filter zu umgehen.

1 Tag ago

Black Friday: Zahl der ominösen Shopping-Websites steigt

Unsichere Websites und Phishing-Mails in Verbindung mit Black Friday können kauffreudigen Konsumenten zum Verhängnis werden.

1 Tag ago

SmokeBuster bekämpft SmokeLoader

Malware SmokeLoader wird weiterhin von Bedrohungsakteuren genutzt, um Payloads über neue C2-Infrastrukturen zu verbreiten.

1 Tag ago

Taugen Kryptowährungen als Unterstützer der Energiewende?

Bankhaus Metzler und Telekom-Tochter MMS testen, inwieweit Bitcoin-Miner das deutsche Stromnetz stabilisieren könnten.

2 Tagen ago

Supercomputer-Ranking: El Capitan überholt Frontier und Aurora

Mit 1,7 Exaflops ist El Capitan nun der dritte Exascale-Supercomputer weltweit. Deutschland stellt erneut den…

2 Tagen ago

Ionos führt neue AMD-Prozessoren ein

Der deutsche Hyperscaler erweitert sein Server-Portfolio um vier Angebote mit den neuen AMD EPYC 4004…

2 Tagen ago