Datenbankverwaltung: Beschleunigung mit Oracle-Replikation

Wenn eine Tabelle klein ist und nur relativ statische Daten enthält, ist es häufig einfacher, den alten Schnappschuss zu verwerfen und einen ganz neuen zu erstellen, als die Option REFRESH COMPLETE zu verwenden. Man könnte ein einfaches Skript erstellen, das von cron aufgerufen wird und in bestimmten Zeitabständen das Löschen und Neu-Erstellen vornimmt.

Eine Alternative zum Erstellen eines Schnappschusses ist die Verwendung von Distributed SQL, um die replizierte Tabelle direkt in der Slave-Datenbank zu erstellen. Man beachte, wie im folgenden CTAS-Beispiel eine Datenbank-Verbindung verwendet wird, um ein Subset der Master-Tabelle emp aus der zentralen Datenbank zu erstellen:

Kleine dynamische Tabellen

Bei kleineren Tabellen könnte man bei jedem Update eine Aktualisierung auslösen. Da die Tabelle jedoch recht klein ist, würde die Schnappschuss-Logdatei wahrscheinlich nicht sehr viele Änderungen verzeichnen. Es ist daher durchaus möglich, dass eine Übernahme der Änderungen in den Schnappschuss in längeren Zeitabständen ausreicht. Hier ein Beispiel für eine REFRESH FAST-Spezifikation, die einmal in der Stunde eine Aktualisierung durchführt:

Große statische Tabellen

Bei umfangreicheren Tabellen mit statischen Daten kann man die Aktualisierungsintervalle erheblich verlängern. Das folgende Beispiel führt jeweils am ersten Sonntag in jedem Quartal einen REFRESH COMPLETE durch:

Große dynamische Tabellen

Sehr umfangreiche Tabellen vollständig zu verwerfen und neu zu erstellen, ist keine gute Idee, da dies System und Netzwerk stark belasten würde. Dasselbe gilt auch für die Option REFRESH COMPLETE – beide Optionen würden einfach zu viel Zeit brauchen. Es folgt eine bessere Möglichkeit, solche Tabellen auf dem aktuellen Stand zu halten.