Oracle Data Pump: Keine Zeit verlieren
von Heinz-Wilhelm Fabry, ORACLE Deutschland B.V. & Co. KG

Mehr als 20 Jahre lang wurden die client-basierten Werkzeuge exp und imp zum Exportieren und Importieren von Daten eingesetzt. Seit Oracle Database 10g wird neue Funkionalität, wie zum Beispiel das Exportieren und Importieren von Daten, die mit dem Feature Transparent Data Encryption verschlüsselt sind, in diese Werkzeuge nicht mehr integriert. exp soll sogar über kurz oder lang völlig aus dem Lieferumfang der Datenbanksoftware fallen. imp wird es dagegen noch länger geben, denn Daten, die aus älteren Datenbankversionen mit exp exportiert wurden, sollen auch in neuere Versionen der Oracle Datenbank geladen werden können.

Ausschlaggebend für die Entscheidung, exp / imp nicht mehr weiterzuentwickeln, waren Performanceprobleme. Die Werkzeuge waren in einer Zeit entwickelt worden, in der eine Datenbank von einigen 100 MB als 'groß' angesehen wurde. Sie konnten allmählich mit den ständig wachsenden Datenmengen nicht mehr angemessen umgehen: Die Zeitfenster, die ein Export oder Import benötigte, wurden zunehmend unvereinbar mit den ständig schrumpfenden Wartungsfenstern einer Datenbankwelt, die sich in Richtung 24x7 Verfügbarkeit bewegte.

Der Nachfolger von exp / imp ist Oracle Data Pump. Durch verschiedene Verfahren - z.B Kopieren von Datendateien beim Transportieren von Tablespaces, Direct Path Exports und Imports, Verwendung von Externen Tabellen in einem Data Pump spezifischen Format und der möglichen Parallelisierung aller Vorgänge - erreicht Data Pump eine Steigerung der Performance um ein Vielfaches gegenüber exp / imp: Läufe, die mit exp / imp Stunden beanspruchen, können so in Minuten abgeschlossen werden. Allerdings sei auch erwähnt, dass die Performancevorteile erst ab einer bestimmten Datenmenge zum Tragen kommen. Bei geringen Datenmengen erhöht der zusätzliche administrative Aufwand, den Data Pump für die ins Auge gefassten großen Datenmengen betreibt, unter Umständen den Zeitbedarf für einen Export oder Import sogar geringfügig.

Dieser Beitrag skizziert die Architektur von Data Pump und gibt eine Einführung in das Arbeiten mit dem 'neuen' Werkzeug. Selbstverständlich sollte jeder, der regelmäßig Daten mit Data Pump exportiert oder importiert und das Werkzeug optimal ausnutzen will, sich bei Gelegenheit mit den Kapiteln aus dem Utility Guide vertraut machen, die Oracle Data Pump ausführlich beschreiben.

Vorab sei noch darauf hingewiesen, dass Data Pump und exp / imp NICHT miteinander kompatibel sind. Ein Export, der mit dem einen Werkzeug erzeugt wurde, kann nicht mit dem Import des anderen Werkzeugs verarbeitet werden.

Anmerkung: Bilder zum Tipp werden sichtbar, indem man mit der Maus über das Brillen Icon fährt.


Um das Bild wieder zu verkleinern, auf das Bild klicken.


Überblick

Data Pump besteht aus Komponenten, die in den zwei Packages DBMS_DATAPUMP und DBMS_METADATA zur Verfügung gestellt werden. Beide Packages können einerseits in eigenen Programmen verwendet werden. Welche Möglichkeiten das Package DBMS_METADATA bietet, wird in der Referenz PL/SQL Packages & Types beschrieben und in einem Community Tipp mit Beispielen erläutert. Eine Beschreibung der Komponenten von DBMS_DATAPUMP ist ebenfalls in der Referenz zu finden, eine Anleitung mit Beispiel zum Arbeiten enthält das Handbuch Utilities.

Andererseits bietet Oracle selbst zwei Standard Schnittstellen zu Data Pump, die den unterschiedlichen Arbeitsweisen Rechnung tragen, mit denen Anwender und DBAs arbeiten: Wie Abbildung 1 zeigt, stellt der Oracle Enterprise Manager unter Verschieben von Daten / Zeilendaten verschieben eine graphische Schnittstelle zur Verfügung.


Abbildung 1: Oracle Data Pump im Enterprise Manager

Wer lieber auf der Kommandozeile arbeitet, kann von dort mit dem sogenannten Client Interface expdp / impdp Daten exportieren und importieren.

Man kann wahrscheinlich behaupten, dass der Einsatz von Data Pump sich nicht wesentlich von dem Einsatz von exp / imp unterscheidet. So gibt es bei beiden die Möglichkeit, nach dem Aufruf der jeweiligen Client Interfaces die wichtigsten Informationen durch das Programm abfragen zu lassen. Data Pump führt hier allerdings dann grundsätzlich einen Schema Export / Import durch. Es gibt auch bei beiden die Möglichkeit, mit Parameterdateien zu arbeiten. Diese Variante wird sicherlich am häufigsten eingesetzt: Die gewünschten Optionen für den Export oder Import werden in einer Datei aufgelistet. Der Name der Datei wird dann beim Aufruf des Client Interface angegeben. Das hat natürlich den Vorteil, dass die gewünschten Optionen bei Bedarf oder im Rahmen von Batch Läufen immer wieder ohne zusätzlichen Aufwand zur Verfügung stehen.

Weil die meisten Anwender von exp / imp sich im Laufe der Zeit eine Reihe von Parameterdateien angelegt haben, die sie immer wieder benutzen, hat Oracle für Data Pump inzwischen den sogenannten legacy mode eingeführt: Die exp / imp Parameterdateien können nahezu unverändert weiterverwendet werden. Oracle empfiehlt lediglich, diese Parameterdateien bei Gelegenheit ("as time permits") auf die leicht veränderte Syntax von Data Pump umzustellen. Wie Data Pump im legacy mode die alten Parameter umsetzt und was an minimalen Änderungen nötig ist wird im entsprechenden Kapitel des Handbuchs ausführlich beschrieben - dabei machen die Angaben zu den nötigen Änderungen gerade mal eine halbe Seite aus.

Trotz dieser sehr anwenderfreundlichen Vorgehensweise muss man sich vor Augen halten, dass es wesentliche Unterschiede zwischen dem alten und dem neuen Werkzeug gibt:
  • Data Pump ist ein Server-basiertes Werkzeug. Anders als der Vorgänger exp / imp ist es also auch kein Bestandteil einer Oracle Client-Installation.
  • Data Pump nutzt das Job-System der Datenbank. Anders als beim Arbeiten mit exp / imp können also Export- und Importläufe mit Data Pump angehalten, verändert und abgebrochen werden. Die Data Pump Jobs laufen so, dass sie bei Problemen anhalten und wieder aufgenommen werden können (resumable). Das ist zwar grundsätzlich begrüßenswert, kann aber auch bei nicht ausreichendem Monitoring dazu führen, dass man vergeblich auf den Abschluß eines Jobs wartet, der wiederum auf die Lösung eines Problems wartet.
  • Data Pump schreibt bei einem Export alle Informationen über den Verlauf des Exports und die exportierten Objekte in eine Tabelle, die sogenannte master table. Die Tabelle wird im Default Tablespace des Benutzers angelegt, der den Export veranlasst. Dieser Benutzer benötigt also das Recht, Tabellen in dem Tablespace anzulegen, und ausserdem ausreichend Quota in diesem Tablespace. Die Tabelle erhält den Namen des Export Jobs und wird am Ende des Exports zum Teil des Exports. Die darin enthaltenen Informationen steuern dann den Import.
  • Die Dateien, die geladen oder geschrieben werden, müssen in einem logischen Verzeichnis liegen. Es wird mit dem Befehl CREATE DIRECTORY angelegt, der Zugriff darauf über die entsprechenden GRANTs freigegeben. Zur Vereinfachung kann man in der Umgebung des Benutzers die Umgebungsvariable DATA_PUMP_DIR anlegen. Alternativ kann auch ein bei der Installation der Datenbank angelegtes Verzeichnis mit dem gleichen Namen (DATA_PUMP_DIR) genutzt werden. Während Benutzer mit der Rolle DBA dieses Verzeichnis grundsätzlich verwenden können, muß der Zugriff darauf für andere Anwender ausdrücklich über die entsprechenden GRANTs gewährleistet werden. Auch wenn im oben beschriebenen legacy mode gearbeitet wird, muss der Zugriff auf ein Directory gewährleistet sein.
  • Wer Objekte exportieren oder importieren will, die nicht zum eigenen Schema gehören, benötigt die Rollen datapump_export_full_database und / oder datapump_import_full_database.
  • Das Exportieren oder Importieren sollte nie als SYSDBA erfolgen, es sei denn, dass der Oracle Support um einen derartigen Export oder Import bittet.
Export Beispiel

Der Benutzer Scott soll Objekte seines Schemas exportieren. Zuvor ist, wie oben beschrieben, für ihn ein Verzeichnis anzulegen. Das geschieht mit folgenden Befehlen, die das Privileg CREATE ANY DIRECTORY voraussetzen. 
CREATE OR REPLACE DIRECTORY expdir AS '/home/oracle'
/
GRANT read, write ON DIRECTORY expdir TO scott
/
Nun kann Scott interaktiv mit expdp arbeiten oder die Angaben zum Export in einer Parameterdatei ablegen. Hier soll mit einer Parameterdatei mit dem Namen repex.par gearbeitet werden. Sie enthält folgende Einträge: 
SCHEMAS=scott
EXCLUDE=TABLE:"like 'SAL%'"
QUERY=emp:"WHERE deptno < 30"
PARALLEL=2
JOB_NAME=repex
VERSION=10.1
DUMPFILE=expdir:expscott%U.dmp
FILESIZE=500K
LOGFILE=expdir:expscott.log
Die Parameterdatei legt fest, dass das Schema SCOTT zu exportieren ist. Im Fall der Tabellen sollen alle Tabellen ausgeschlossen werden, die mit der Zeichenfolge SAL beginnen. Die Tabelle SALGRADE wird also nicht exportiert. Bei der Tabelle EMP werden nur Sätze exportiert, bei denen der Eintrag in der Spalte DEPTNO < 30 ist. Die Möglichkeit zu parallelisieren besteht nur, wenn die Enterprise Edition der Datenbank im Einsatz ist. Im Beispiel wird mit 2 parallelen Prozessen gearbeitet. Die allgemeine Empfehlung zum Grad der Parallelisierung lautet, nicht mehr als 2 Prozesse pro vorhandener CPU einzuplanen. Der zu vergebende Job Name ist REPEX. Der Export erfolgt so, dass der anschließende Import in eine Datenbank der Version 10.1 möglich ist - Objekte mit Eigenschaften, die in 10.1 nicht unterstützt werden, werden schlicht nicht exportiert. Ohne den Parameter VERSION werden alle spezifizierten Objekte exportiert, und es wird davon ausgegangen, dass der anschließende Import in eine Datenbank erfolgt, die den gleichen Versionsstand hat wie die Datenbank, aus der exportiert wird. Es folgen die Angaben dazu, wo die zu schreibenden Dateien abgelegt werden. Dabei werden die Dateien mit den Benutzerdaten maximal 500K groß. Die Größenangabe könnte auch in MByte oder GByte erfolgen. An dem %U im Dateinamen erkennt das System, dass es fortlaufende Nummern für die in ihrer Größe limitierten Dateien vergeben muss.

In Abbildung 2 ist zu erkennen, dass der Verlauf des Exports planmäßig ist:



Abbildung 2: Export mit Oracle Data Pump

Interessant ist vielleicht noch die Rückmeldung "Estimate in progress". Sie verweist darauf, dass es möglich ist, vor dem eigentlichen Export vom System zu erfragen, wie groß der Platzbedarf für den Export ist - und zwar ohne den Export wirklich durchzuführen.

Weitere besondere Möglichkeiten beim Exportieren sind das Komprimieren und das Verschlüsseln der exportierten Daten. Dazu müssen jedoch die Advanced Compression Option bzw. die Advanced Security Option lizenziert und installiert sein.

Sehr interessant ist auch die Möglichkeit, während der Export Job läuft, in den sogenannten Interaktiven Modus wechseln zu können. Dies erreicht man, indem man nach Anlaufen des Exports einfach die Tastenkombination CTRL-C betätigt. Nun lässt sich der Status des Jobs abfragen, der Job anhalten usw. Es ist auch möglich, den Grad der Parallelisierung zu ändern oder weitere Dateien für die Benutzerdaten anlegen zu lassen - wenn man z.B. darauf verzichtet hat, das System mit der Erzeugung nummerierter Dateien zu beauftragen. Abbildung 3 deutet an, wie das am Bildschirm aussieht: Ein vollständiger Export (FULL=Y) ist angelaufen. Der Name des dazu erzeugten Jobs lautet FULLEX. Nun führt das Betätigen der Tastenkombination CTRL-C zum Meldungsprompt Export>. Nach einem Kommando (hier Anhalten des Jobs mit STOP_JOB) oder mit dem Befehl EXIT_CLIENT gelangt man auf das Betriebssystem. Der anschließende Aufruf von Data Pump Export mit dem Befehl ATTACH=FULLEX führt den Anwender mit einer Reihe von Statusinformationen zurück auf den Prompt Export> zur Steuerung des Jobs im Export Client (in der Abbildung nicht mehr zu sehen).



Abbildung 3: Job Steuerung im Interaktiven Modus

Import Beispiel

Erwartungsgemäß unterscheidet sich das Arbeiten mit Data Pump Import nicht grundsätzlich vom Arbeiten mit Data Pump Export. Selbstverständlich gibt es einige Import spezifische Parameter. Mit ihnen können beispielsweise Tabellen oder Tablespaces während des Imports umbenannt werden (Parameter REMAP_xxx und TRANSFORM), und es kann festgelegt werden, wie das System sich verhalten soll, falls eine zu importierende Tabelle bereits existiert (Parameter TABLE_EXISTS_OPTION). Sehr praktisch ist auch die Möglichkeit, sich durch den Import eine editierbare ASCII Datei erzeugen zu lassen, die nur die DDL Befehle enthält, die beim Import ausgeführt würden.

Dennoch soll anhand eines kleinen Beispiels eine interessante Variante des Imports vorgestellt werden, nämlich den Import über einen Datenbanklink. Das Besondere an dieser Variante ist, dass sie ohne den eigentlichen Export in Dump Dateien abläuft, was z.B. bei Speicherplatzproblemen auf dem nicht lokalen Datenbankserver hilfreich sein kann. Die Daten werden über das Netzwerk direkt in die zu ladende Datenbank geholt. Einige Hinweise sind angebracht:
  • Current User Datenbank Links sind nicht unterstützt.
  • Einige Datentypen, z.B. LONG oder SecureFiles, werden nicht unterstützt.
  • Vertrauliche Daten sollten nie über eine unverschlüsselte Leitung transportiert werden.
  • Die Netzwerkbelastung vor allem bei großen Datenmengen ist unbedingt zu beachten.
Der Aufruf von Data Pump Import soll in diesem Fall beispielhaft nicht mit einer Parameterdatei, sondern auf der Kommandozeile erfolgen. Es soll hier auch genügen, nur die zuvor in der lokalen Datenbank mit DROP gelöschte Tabelle EMP über das Netzwerk zu importieren und so wieder lokal verfügbar zu machen. Die Verwendung des Parameters DIRECTORY ist nötig, weil ein Speicherort für die Log Datei anzugeben ist. Der verwendete database link communitylink ist mit dem Befehl CREATE DATABASE LINK zuvor angelegt worden (aus Sicherheitsgründen ist Scott dazu zunächst das Recht CREATE DATABASE LINK erteilt und nach Anlegen des Links wieder entzogen worden). 
impdp scott DIRECTORY=expdir TABLES=emp NETWORK_LINK=communitylink
Abbildung 4 zeigt den Verlauf.



Abbildung 4: Netzwerkimport

Ergänzendes Monitoring

Neben den Möglichkeiten über den Interaktiven Modus einen laufenden Data Pump Job im Auge zu behalten, kann auch die View V$SESSION_LONGOPS Auskunft über die wichtigsten Informationen zum Job geben, beispielsweise über die bisher verarbeitete und die noch zu verarbeitende Datenmenge (Spalten SOFAR und TOTALWORK). Auch die Alert Datei kann bei Problemen zurate gezogen werden. Dort sucht man am einfachsten nach dem Job Namen. Falls man den Eindruck hat, dass Data Pump die Gesamtperformance der Datenbank negativ beeinflusst - Ursache kann z.B. die Wahl einer zu hohen Parallelisierung sein - bietet sich auch ein Blick in den Enterprise Manager unter dem Menupunkt TOP CONSUMERS an.

Zurück zur Community-Seite