Die Funktionsweise des XTT-Driver Moduls ist detailliert in den MOS-Notes 1389592.1 für 11g und 2005729.1 für 12c beschrieben. Das Modul basiert im Wesentlichen auf der „Transportable Tablespace“-Methode von Oracle (Enterprise Edition erforderlich). Die Parametrisierung des XTT-Driver Moduls erfolgt über die Datei „xtt.properties“. Darin werden die zu transportierenden Tablespaces, Angaben zur Quell- und zur Ziel-Datenbank sowie der Parallelisierungsgrad innerhalb der einzelnen Migrationsschritte angegeben. Am Ende der MOS-Notes gibt es eine Download-Möglichkeit des Moduls in der Version 3, die Bestandteil dieser Ausführungen ist. Mittlerweile existiert auch eine neue Version 4. Dazu nachher mehr in diesem Monatstipp.
Im Rahmen der Verwendung des XTT-Driver Moduls., lassen sich folgende Phasen unterteilen, wobei nur während der Migrationsphase die Quell-Datenbank offline ist:
Aufgrund der Erfahrung mit den ersten Migrationen ist es absolut empfehlenswert, die o. g. Phasen bereits testweise in einer produktionsnahen Umgebung anstatt gleich in der eigentlichen Produktionsumgebung durchzuführen. Um die Zielumgebung nicht jedes Mal neu aufsetzen zu müssen, empfehlt es sich, mit garantierten „Restore Points“ zu arbeiten.
In der Vorbereitungsphase sind vor allem die Voraussetzungen für eine Migration, wie sie in den MOS-Notes beschrieben sind, zu beachten. Der XTT-Treiber überprüft diese Voraussetzungen leider erst während der eigentlichen Migrationsphase, so dass im „Worst-Case“ der gesamte Zyklus nochmals begonnen werden muss. Daher müssen die Voraussetzungen unbedingt berücksichtigt werden. Während unserer Migration sind u. a. zusätzlich noch folgenden Dinge aufgefallen:
Um bei den einzelnen Schritten nicht jedes Mal den Output vom Quell-System auf das Ziel-System kopieren zu müssen, empfiehlt es sich, die Verzeichnisse über einen NFS-Share zu verbinden.
In der Transport-Phase werden die Datenfiles entweder mit Hilfe von RMAN oder mit dem DBMS-FILE_TRANSFER-Package vom Quell- auf das Ziel-System übertragen. Oracle empfiehlt bei sehr vielen Datendateien, die DBMS_FILE_TRANSFER- Methode zu verwenden. In der Konfigurationsdatei “xtt.properties” werden für die Quell- und für die Ziel-Datenbank die Pfade der Datenfiles mit Hilfe von „Datenbank-Directories“ angegeben. Für Quell- und Ziel-Datenbank können auch mehrere Pfade eingetragen werden (N:N oder N:1).
-----------------------------------------------------------------------------------------------------------------------------------
Ein Auszug aus der „xtt.properties“:
srcdir=XTT_SOURCE_DF1,XTT_SOURCE_DF2
# Name der Directories, die auf die Verzeichnisstruktur in der Quell-Datenbank zeigen
dstdir=XTT_DEST_DF
# Name der Directories, die auf die Verzeichnisstruktur in der Ziel-Datenbank zeigen
srclink=XTT_TTSLINK
# Name des DB-Links, der in der Ziel- Datenbank auf die Quell-Datenbank zeigt
platformid=2
# Angabe Plattform 2=Solaris
parallel=8
# Anzahl Prozesse bei RMAN Incremental
rollparallel=8
# Anzahl Prozesse für RMAN Roll Forward
getfileparallel=8
# Anzahl Prozesse bei DBMS_FILE_TRANSFER
tablespaces=USERS,ADM_DATA,ADM_INDEX,MTA_DATA,MTA_INDEX
# Tablespaces , die migriert werden
------------------------------------------------------------------------------------------------------------------------------------
Der Aufruf mit dem XTT-Driver Modul lautet hierzu auf dem Quell-System:
$ORACLE_HOME/perl/bin/perl xttdriver.pl -p ------------------------- RMAN-Methode
$ORACLE_HOME/perl/bin/perl xttdriver.pl -S ------------------------- DBMS-FILE-Transfer-Methode
Auf dem Ziel-System werden die Datenfiles der transportierten Tablespaces folgendermaßen angelegt:
$ORACLE_HOME/perl/bin/perl xttdriver.pl -c --------------------------- RMAN-Methode
$ORACLE_HOME/perl/bin/perl xttdriver.pl -G --------------------------- DBMS-FILE-Transfer-Methode
Zu beachten ist hierbei, dass die Datenbank-Dateien auf dem Zielsystem nur physikalisch angelegt, aber noch nicht im Controlfile der Ziel-Datenbank eingetragen werden.
Bei mehreren Datenbanken empfiehlt es sich, ein Shell-Skript zu erstellen, dass die Befehle automatisiert auf dem Quell- als auch auf dem Ziel-System via SSH durchführt.
Während der inkrementellen Synchronisation (Roll Forward) wird die Ziel-Datenbank auf den aktuellen Stand der Quell-Datenbank gebracht. Diese Phase kann mehrmals aufgerufen werden.
Beim Aufruf auf dem Quell-System wird zwischen einer 11g und einer 12c Datenbank-Version unterschieden
$ORACLE_HOME/perl/bin/perl xttdriver.pl -i -------------------- 11g
$ORACLE_HOME/perl/bin/perl xttdriver.pl –bkpinc -------------------- 12c
Auf dem Ziel-System sind die folgenden Kommandos aufzurufen:
$ORACLE_HOME/perl/bin/perl xttdriver.pl -r -------------------- 11g
$ORACLE_HOME/perl/bin/perl xttdriver.pl –recover -------------------- 12c
Eine Ausnahme stellen die 11.2.0.3 Datenbanken dar. Bei dieser Version ist der vom XTT-Treiber aufgerufene RMAN nicht in der Lage, einen Roll Forward mit gleichzeitiger Konvertierung der Endianness durchzuführen. Um dies zu ermöglichen, muss auf dem Ziel-System eine Instanz mit dem Namen „xtt“ in der Version 11.2.0.4 gestartet sein. Dann übernimmt diese Hilfs-Instanz die Konvertierung.
Nach jedem „Roll-Forward“ kann mit dem folgenden Befehl die SCN für jeden weiteren Aufruf in der Datei „xttplan.xtt“ gespeichert werden:
$ORACLE_HOME/perl/bin/perl xttdriver.pl -s --------------------------- 11g und 12c
Bei dem vorliegenden XTT-Modul ist es wichtig, nach einem inkrementellen Backup sofort den Recover auf dem Ziel-System durchzuführen. Mehrere inkrementelle Backups ohne gleichzeitiges Recovery auf dem Ziel-System funktionieren bei dieser Version noch nicht.
In dieser Phase werden die Tablespaces der Quell-Datenbank offline gesetzt, ein abschließender finaler inkrementeller Backup und Restore durchgeführt und die transportierten Tablespaces in der Ziel-Datenbank eingebunden.
Der finale inkrementelle Backup wird folgendermaßen aufgerufen:
$ORACLE_HOME/perl/bin/perl xttdriver.pl -i -------------------- 11g
$ORACLE_HOME/perl/bin/perl xttdriver.pl –bkpexport -------------------- 12c
Der Restore auf dem Ziel-System entsprechend:
$ORACLE_HOME/perl/bin/perl xttdriver.pl -r ------------------- 11g
$ORACLE_HOME/perl/bin/perl xttdriver.pl –resincrdmp ------------------- 12c
Auch hier ist bei einer zu migrierenden 11.2.0.3 Datenbank zu berücksichtigen, dass der Restore und die Konvertierung auf dem Ziel-System über eine 11.2.0.4 Dummy-Instanz erfolgen muss.
Anschließend wird durch den XTT-Driver ein „xttplugin.txt“-File und ein „Dump“-File für den Import der Metadaten erzeugt:
$ORACLE_HOME/perl/bin/perl xttdriver.pl -L -e
Das automatisch generierte xttplugin.txt-File muss mit den kundenspezifischen Einträgen versehen und anschließend auf dem Ziel-System ausgeführt werden. Die Phase ist sehr kritisch, da bei Abbruch ein Neuaufsetzen der Ziel-Datenbank erforderlich ist. Daher sollten, wie bereits besprochen, in der Vorbereitungsphase die Voraussetzungen für die Migration mit dem XTT-Driver detailliert geklärt werden.
Abschließend werden in dieser Phase die transportierten Tablespaces auf Read-Write gesetzt.
In der Validierungsphase werden die Datendateien der angehängten Tablespaces auf Block-Korruptionen untersucht. Dazu wird der RMAN benutzt:
RMAN> validate tablespace <tablespace-name> check logical;
In der Post-Migrationsphase werden alle Objekte des System-Tablespaces mit dem Data Pump Import über einen „Database Network Link“ aus der Quell-Datenbank importiert. Bei Vorhandensein von Baselines, temporären oder externen Tabellen sind diese Objekte ebenfalls in die Ziel-Datenbank mit den jeweiligen Methoden zu importieren. Es empfiehlt sich auch, die Grants auf SYS-Objekte in der Quell-Datenbank zu ermitteln, da diese gemäß MOS 1911151.1 nicht automatisch mit dem Data Pump Job in die Ziel-Datenbank importiert werden. Ein Kompilieren aller Objekte sowie ein Consistency Check zwischen Quell- und Ziel-System gehören ebenfalls zu dieser Phase. Nach erfolgreichem Abschluss dieser Tätigkeiten hat man eine Migration von auch großen Datenbanken (ca. 8 TB) über Betriebssystem-Grenzen hinweg mit minimaler Downtime erreicht.
Mit der Version 4 des XTT-Treibers verspricht Oracle einige Verbesserungen wie
Bei den Tests (Stand Dezember 2018) hat die unterbrechungsfreie Hinzufügung neuer Tablespaces und Datendateien nicht funktioniert. Wenn Datenbanken ab der Version 11.2.0.4 migriert werden sollen, kann diese Version aber ansonsten durchaus verwendet werden.
Das XTT-Treiber Modul ist eine geeignete Möglichkeit, um bei Betriebssystem-Wechsel die Ausfallzeit zu vermindern. So war es bei der beschriebenen Umstellung möglich, auch sehr große Datenbanken (8 TB) innerhalb weniger Stunden zu migrieren. Entgegen der Vorgabe einer 1:1-Umstellung war bei einigen Datenbanken auch ein gleichzeitiger Upgrade von 11.2.0.3 auf 11.2.0.4 problemlos möglich.
Grundsätzlich muss berücksichtigt werden, dass zusätzliche Datenbank-Objekte aus dem System-Tablespace ebenfalls übertragen werden müssen und es dadurch bei Datenbanken mit sehr vielen Objekten (z. B. SAP / Oracle EBusiness Suite) zu einer höheren Downtime kommen kann.
Es empfiehlt sich auch, Anwendungen wie z. B. APEX oder OWB auf dem Ziel-System vorzuinstallieren und die zugehörigen Schemata von der Migration auszuschließen.
In unserer Know-How Datenbank finden Sie mehr als 300 ausführliche Beiträge zu den
Oracle-Themen wie DBA, SQL, PL/SQL, APEX und vielem mehr.
Hier erhalten Sie Antworten auf Ihre Fragen.