MIGRATION MIT DEM XTT-DRIVER MODUL

01.
Februar
2019
Veröffentlicht von: Kurt Sauer

Der vorliegende Monatstipp beschreibt die Migration mehrerer Produktiv-Datenbanken von Oracle Solaris auf Linux Red Hat mit Hilfe des XTT-Driver Moduls von Oracle im Rahmen eines Rechenzentrum-Umzuges. Wichtige Vorgaben für den RZ-Umzug waren eine möglichst geringe „Downtime“ während der Migration und eine 1:1 Umsetzung der Datenbank-Objekte beim Übergang von einem Betriebssystem mit Big-Endianness auf eines mit Little-Edianness.

XTT-DRIVER MODUL

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.

PHASEN DER MIGRATION

Im Rahmen der Verwendung des XTT-Driver Moduls., lassen sich folgende Phasen unterteilen, wobei nur während der Migrationsphase die Quell-Datenbank offline ist:

  • Vorbereitungsphase
  • Transportphase
  • Inkrementelle Synchronisierung zwischen Quell- und Ziel-Datenbank
  • Migrationsphase
  • Validierungsphase
  • Post-Migrationsphase

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.

Vorbereitungsphase

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:

  • Schema-User müssen bereits vorher mit einem existierenden Default-Tablespace in der Ziel-Datenbank angelegt werden
  • Oracle Default User (z. B. AUDSYS,DBSNMP,SYSMAN,GSMADMIN_INTERNAL,OJVMSYS etc.) sollten nicht in die Ziel-Datenbank übernommen werden
  • Existieren im „USERS“-Tablespace Objekte, die transportiert werden müssen – dann darf der Tablespace nicht in der Ziel-Datenbank existieren- es muss ein zweiter „USERS“-Tablespace (z. B. „USERS2“) als Default Tablespace angelegt und der Tablespace mit dem Namen „USERS“ gelöscht werden.
  • Die „TimeZone“-Version muss identisch zwischen Quell- und Ziel-Datenbank sein
  • Bei einer Quell-Datenbank mit unterschiedlicher Blocksize-Größe der Tablespaces muss der INIT.ORA-Parameter „db_Xk_cache_size“ für den „non-Default“- Tablespace angegeben werden
  • Bei einer Quell-Datenbank mit sehr vielen Daten-Files muss in der Ziel-Datenbank ggf. der INIT.ORA-Parameter „db_files“ erhöht werden.

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.

Transportphase

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.

Inkrementelle Synchronisierung zwischen Quell- und Ziel-Datenbank

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.

Migrationsphase

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.

Validierungsphase

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;

Post Migrationsphase

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.

VERSION 4 DES XTT-TREIBERS

Mit der Version 4 des XTT-Treibers verspricht Oracle einige Verbesserungen wie

  • automatisches Hinzufügung von in der Quell-Datenbank neu erzeugten Tablespaces bzw.  Datendateien in der Zieldaten-Datenbank
  • mehrmalige Aufrufmöglichkeit eines inkrementellen Backups auf der Quell-Datenbank ohne gleichzeitiges Recovery im Zielsystem
  • eine einfachere Kommando-Struktur

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.

FAZIT

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.

Crossplatform-Migration

Jede Menge Know-how für Sie!

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.