1999 hörte ich zum ersten Mal von einer Replikationslösung für die Oracle Datenbank. Zu dieser Zeit arbeitete ich als Projektleiter bei einem Consulting-Unternehmen und hatte in einem Projekt für ein Telekommunikationsunternehmen einige Erfahrung mit Oracle Advanced Replication sammeln können.
Das Produkt SharePlex klang vielversprechend und so begann ich, mich in die Architektur und Funktionen einzuarbeiten. In den folgenden Jahren bekam ich so mehr und mehr Erfahrung in der Administration mit diesem Produkt. 2002 habe ich dann ein Projekt betreut, in dem der Kunde bereits Oracle Standby als Desaster Recovery Lösung im Einsatz hatte aber nicht ganz zufrieden damit war. Der Grund war, dass die Standby Datenbank prinzipiell aufgesetzt werden konnte, es aber zu diesem Zeitpunkt keine Möglichkeit gab, die Funktion zu testen. Wenn man die Datenbank öffnete, um zu validieren, dass die Daten übertragen worden waren, war die Standby Funktion irreversibel verloren und man musste von vorne anfangen. Ein Read-Only Öffnen, wie es heute bei Data Guard üblich ist, war damals nicht möglich.
Als Alternative haben wird dem Kunden dann das Produkt „SharePlex for Oracle“ von Quest als Desaster Recovery Lösung angeboten und der Kunde war einverstanden. Es war ein sehr erfolgreiches Projekt, auch weil der Kunde sofort die Vorteile sah, dass beide Datenbanken geöffnet waren und im Fehlerfall nur die Anwendung umgeschaltet werden musste.
Als nächstes stand 2003 dann der Upgrade auf Oracle 9i an (ich glaube, es war 9i Release 2). Nach einigen Tests mit der Anwendung sprach nichts gegen den Upgrade außer, dass die Downtime für den Upgrade zu lange war. Den Upgrade zunächst an einer Datenbank durchzuführen und dann an der zweiten haben wir uns nicht getraut, da an der Anwendung selbst auch noch einige Änderungen durchgeführt werden mussten.
Aber wir hatten ja SharePlex im Einsatz. Also haben wir ein „Minimum Downtime Upgrade“ Projekt aufgesetzt und ich denke, es war das erste Mal, dass eine Replikationslösung für den Upgrade einer Oracle Datenbank benutzt wurde um somit die Downtime drastisch zu reduzieren.
Minimum Downtime Migration
Für die Migration haben wir zunächst den Post Prozess, der die Daten aus der Datenbank EMAIL1 in die Datenbank EMAIL2 kopiert hat, gestoppt. Damit hatten wir eine Read-Only Kopie der Datenbank und konnten zwei neue Datenbanken (EMAILN1 und EMAILN2) aufsetzten. Da die Datenbankgröße mit 40 GB eher überschaubar war, konnten wir es uns leisten, zwei Datenbanken auf jedem Rechner zu betreiben.
Mit dem normalen Export / Import haben wir dann die beiden Datenbanken befüllt. Durch die Read-Only Kopie hatten wir einen exakten Synchronisationspunkt, denn Flashback Query gab es zu diesem Zeitpunkt nur in Oracle 9i und fiel damit aus.
Nach dem Setup von SharePlex zwischen den neuen Datenbanken und einer temporären Replikation zwischen der alten Oracle8i und der neuen Oracle9i Datenbank konnten wir den Post Prozess auf der EMAIL2 wieder starten und – kein Wunder – nach ein paar Stunden waren alle vier Datenbanken in Sync. Zunächst haben wir dann ein paar Validierungen auf den neuen Datenbanken durchgeführt und in der darauf folgenden Woche die Anwendung auf die neue Datenbank umgeschaltet. Der Downtime war somit ausschließlich durch das Umschalten der Anwendung bedingt.
Das war meine erste aber nicht letzte Migration, die ich mit Hilfe von SharePlex durchgeführt habe.
Letzte Woche habe ich die neueste Version (8.5) von SharePlex heruntergeladen. In den vergangenen Jahren habe ich einige Installationen und PoCs mit SharePlex gemacht und dabei mit GoldenGate und Dbvisit Replicat verglichen und mir ist auf einmal aufgefallen, dass sich das Produkt gar nicht so sehr verändert hat in den 12 (!) Jahren nach meiner ersten Migration mit SharePlex. Natürlich gibt es Anpassungen an die Oracle Versionen und neue Features aber im Wesentlichen ist die Funktionalität gleich geblieben. Heißt das jetzt, dass SharePlex „alt“ ist? Überhaupt nicht! In weniger als 15 Minuten konnte ich SharePlex für zwei Datenbanken, einmal Version 11.2.0.4 und einmal 12.1.0.2, installieren, konfigurieren und damit Daten erfolgreich replizieren.
Falls Sie es auch einmal ausprobieren wollen, hier ist die Anleitung dazu:
Setup SharePlex
- Packen Sie die SharePlex Software in einem beliebigen Verzeichnis aus
- Führen Sie das Programm aus:
- Das Verzeichnis für die Software Installation (SP_HOME)
- Das Verzeichnis für die Konfigurationsdateien, Logfiles, etc (SP_SYS_VARDIR). Ich würde Ihnen empfehlen, hierfür ein separates Filesystem zu verwenden.
- Des weiteren werden die Datenbank Version, Datenbankname, TCP-Ports etc. abgefragt.
- Nach der Installation muss noch ein Datenbank Schema angelegt werden. Wenn es bei Ihnen keine bestimmten Vorgaben gibt, würde ich empfehlen, hierfür das Programm „ora_setup“ aus dem SP_HOME/bin Verzeichnis zu verwenden. Dabei gibt es wiederum Abfragen nach Benutzernamen, Passwort, etc.
- Als nächstes wird der Management Prozess „sp_cop“ als Hintergrundprozess gestartet
- Und jetzt ist es Zeit, die eigentliche Replikation aufzusetzen. Die Konfigurationsdatei könnte hierbei kaum einfacher sein:
- Datenquelle ist eine Oracle Datenbank „o“ mit dem Namen „RICHARD“
- Die zu replizierende Tabelle heißt auf der Quelle „sptest.customers“ (<Schemaname>.<Tabellenname>)
- Auf dem Ziel heißt die Tabelle ebenfalls „sptest.customers“
- Die Zieldatenbank liegt auf dem Server „cage“, ist eine Oracle Datenbank „o“ und die Datenbank heißt „JOHN“
- Mit dieser Konfigurationdatei kann die Replikation aktiviert werden. Das SharePlex Kontrollkommando „sp_ctrl“ hilft bei der Aktivierung und dem Monitoring:
$SP_HOME/bin/sp_ctrl sp_ctrl> activate config
sh SharePlex-8.5.0...
Sie werden dann durch die Installationsroutine geleitet. Zwei Verzeichnisse werden benötigt:
$SP_HOME/bin/sp_cop &
datasource:o.RICHARD #Source Table Destination Table Routing Map sptest.customers sptest.customers cage@o.JOHN
Diese Datei enthält die folgenden Informationen und liegt im Verzeichnis $SP_SYS_VARDIR/config:
Das war’s. Mit diesen wenigen und, meiner Ansicht nach leicht nachzuvollziehenden, Punkten, kann eine einfache SharePlex Replikation zwischen zwei Datenbanken aufgebaut werden. Natürlich gibt es auch ein Skript, was die Konfigurationsdatei aufbaut (build_config.sql bzw. config.sql). Wer also keinen Editor mag, kann einfach die SQL-Skripte aufrufen.
Zusammenfassung
DELL Software bietet eine Demolizenz an, die 30 Tage gültig ist. Damit kann man sicherlich schon einige Versuche starten. Es gibt außerdem Gerüchte, dass die nächste Version von SharePlex Multitenant Database unterstützen soll und wie Sie vielleicht gesehen haben, bin ich ein Fan von Pluggable Databases und werde sicherlich versuchen, SharePlex baldmöglichst dafür zu testen. Daher hoffe ich, dass ich Ihnen in einem der nächsten Blogs erklären kann, wie man eine Oracle 11g WE8ISO Datenbank mit minimal Downtime in eine Pluggable Database mit Unicode Zeichensatz migriert.