Datenbank auf anderen Server migrieren

Gelegentlich kann es vorkommen, dass eine Datenbank “so wie sie ist” auf einen anderen Server verschoben werden soll. Kann man dabei eine Downtime in Kauf nehmen, stellt sich die Sache als relativ simpel dar:

Auf dem Zielsystem muss exakt dieselbe Verzeichnisstruktur wie auf dem Quellsystem geschaffen werden; insbesondere die Dump-Verzeichnisse (bdump, udump, etc.), die Control-Files, die Redo-Logs und natürlich die Datenfiles müssen an dieselbe Stelle verschoben werden. Nicht zu vergessen das SPFILE (sofern vorhanden), die INIT.ORA und das Password-File; alle drei Dateien befinden sich überlicherweise unter $ORACLE_HOME/dbs bzw. /database.

Auf Windows-Systemen ist ein weiterer Schritt erforderlich: hier muss der Dienst neu angelegt werden, der die Instanz erzeugt. Dies geschieht mit dem Oracle-Tool ORADIM.

oradim -new -sid orcl

“ORCL” ist hierbei die zu vergebende SID. Im Dienstemanager von Windows taucht dann sofort der Dienst “OracleServiceORCL” auf. Nun stellt man diesen ggf. noch auf “Automatisch starten” und schon kann man die verschobene Datenbank hochfahren.

Im Netzwerk bzw. auf den Clients muss dann noch die Net8-Konfiguration geändert werden, damit die Clients auch wissen, wo sich die neue Datenbank befindet.

Wo ist der CONSISTENT-Parameter bei Data Pump?

Beim Einsatz von Data Pump ab 10g mag sich mancher wundern, wo der CONSISTENT-Parameter geblieben ist. Dieser Parameter stellte beim EXP-Tool die Konsistenz der Daten während des gesamten Exports sicher — kein völlig unwichtiges Feature also.

Bei Data Pump (EXPDP / IMPDP) übernehmen diese Funktion die Parameter FLASHBACK_SCN und FLASHBACK_TIME. Diese Parameter schließen sich bei Benutzung gegenseitig aus. Der Einsatz von FLASHBACK_SCN sichert die Konsistenz eines Exports zu einer bestimmten SCN, und FLASHBACK_TIME zu einem bestimmten Zeitpunkt. Üblicherweise würde man hier SYSDATE bevorzugen.

Das Ganze liest sich dann wie folgt:

#> expdp system/passwd directory=flsh dumpfile=user001_2.dmp 
  logfile=user001_2.log schemas=usr001
  flashback_time="TO_TIMESTAMP (TO_CHAR (SYSDATE, 'YYYY-MM-DD HH24:MI:SS'), 
    'YYYY-MM-DD HH24:MI:SS')"

Hierzu wird übrigens das Feature “Flashback Query” herangezogen, die FLASHBACK AREA muss hierfür nicht definiert sein. “Flashback Query” bedient sich aus dem UNDO-Tablespace.

Interessant hierzu ist der Metalink Artikel 377218.1: Expdp Message “FLASHBACK automatically enabled” Does Not Guarantee Export Consistency. Demnach wirft EXPDP die Meldung “FLASHBACK automatically enabled” aus, was aber nicht automatisch heißt, dass der gerade gestartete Export konsistent ist. Um dies zu erreichen, muß immer mit den Parametern FLASHBACK_SCN oder FLASHBACK_TIME gearbeitet werden.

Bei EXP/IMP kannte nur EXP den CONSISTENT-Parameter, bei Datapump sind es sowohl EXPDP wie auch IMPDP — schließlich kann IMPDP via Network-Link auch “exportieren”.

Datapump-Export mit NETWORK_LINK dauert lange

Im Rahmen einer Migration bin ich heute über den Bug 4513695 gestolpert: der Datapump-Export braucht unter Umständen sehr lange für das Bestimmen der Tabellen-Größen, noch bevor der eigentliche Export angefangen hat.

Genau genommen handelt es sich hier ja um den Datapump-Import, da der NETWORK_LINK-Parameter nur beim IMPDP möglich ist.

Jedenfalls scheint der IMPDP hier ewig lange festzuhängen, ohne dass sich etwas bewegen würde:

Starting "SYSTEM"."SYS_IMPORT_SCHEMA_04":  system/******** LOGFILE=imdp.log PARALLEL=4 
  REMAP_SCHEMA=scott:scott_clone SCHEMAS=scott network_link=orcl

Estimate in progress using BLOCKS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA

Und dann war’s das für lange, lange Zeit.

Die Lösung des Problems steht u.a. in Metalink Note 416238.1: Impdp With NETWORK_LINK Runs Very Slowly at Estimate Stage.
Die Lösung des Problems ist einfach:

ALTER SYSTEM SET CURSOR_SHARING='EXACT';

in der Zieltabelle ausführen und dann geht’s. Eine Übersicht, welche Datenbank welchen Parameter “verträgt”, findet man in Metalink-Note 421441.1.

Schema klonen mit Datapump

Oracle hat mit Datapump ab 10g ein neues Tool eingeführt, das die alteingesessenen, aber bewährten Tools EXP und IMP ablösen soll. Dabei ist es deutlich mächtiger, bringt aber auch einige Einschränkungen im Vergleich zur bisherigen Vorgehensweise mit sich. Doch dazu in einem späteren Artikel mehr.

Datapump kann hervorragend zum Klonen ganzer Schemata (neudeutsch auch Schemas) benutzt werden, und das sogar ohne eine Export-Datei anzulegen.

Hierzu bedient man sich der NETWORK_LINK-Funktionalität von Datapump, in dem es unter Umgehung des Filesystems die zu importierenden Daten direkt aus der Quelldatenbank saugt. Notwendig hierzu ist ein DATABASE LINK auf die Quelldatenbank. Will man ein Schema in der gleichen Datenbank klonen, legt man einfach einen Link auf die eigene Datenbank an (loopback).

Beispiel: wir möchten die Schemas SCOTT und EMILY in die Schemas SCOTT_CLONE und EMILY_CLONE klonen. Quell- und Zieldatenbank sind identisch: ORCL.

Zunächst wird der Database Link angelegt, z.B. mit

CREATE PUBLIC DATABASE LINK "TO_ORCL" CONNECT TO "SYSTEM" IDENTIFIED by "manager" USING 'orcl'

Wie der Dokumentation zu entnehmen ist, sollte für das Logfile ein Directory-Objekt vorhanden sein:

CREATE DIRECTORY "DATA_PUMP_DIR" AS '/u01/oracle/admin/ORCL/dpdump'

Dann startet man den IMport, denn der EXport wird bei Verwendung des Network-Modus impliziert:

impdp system network_link=to_orcl logfile=cloning.log
remap_schema='SCOTT':'SCOTT_CLONE','EMILY':'ELIMY_CLONE' schemas=SCOTT,EMILY

Dies ist ein Beispiel mit zwei zu klonenden Schemas, das funktioniert natürlich auch mit einem oder auch drei equivalent.

Wichtig ist, dass man SCHEMAS=… angibt, sonst kopiert Datapump die gesamte Datenbank (was nicht funktionieren würde), und remappt dabei die angegebenen Schemas.