Logo Oracle Deutschland   DBA Community  -  September 2013
Data Pump in 12c - Logging, Views, PDB, Datenbank Transport und weitere Features
von Ulrike Schwinn, Oracle Deutschland B.V. & Co. KG

Das Werkzeug Data Pump ist mittlerweile weit verbreitet. Jeder Datenbank Administrator kennt und verwendet es. In jedem neuen Datenbank Release gibt es zudem einige wichtige Neuerungen, die die Data Pump betreffen. Es ist also an der Zeit, im aktuellen Tipp einige ausgewählte 12c Features der Data Pump zu behandeln. Es handelt sich dabei um Features, die die Performance erhöhen, die Handhabung vereinfachen oder einfach nur mehr Funktionalität bieten. Im Detail handelt es sich dabei um folgende Neuerungen:

Möchte man sich unabhängig von 12c mit weiteren Eigenschaften der Data Pump beschäftigen, bieten sich folgende Veröffentlichungen in der DBA Community zur weiteren Lektüre an: Views als Tabelle
Im ersten Beispiel wird die View ORDERS_VIEW aus dem Demo Schema OE verwendet. Die View ORDERS_VIEW soll beim Export als Tabelle mit den gleichen Spalten wie die View angelegt und mit den zugehörigen Zeilen gefüllt werden. Dazu wird beim Aufruf des Data Pump Exports der neue Ausdruck VIEWS_AS_TABLES=[schema_name.]view_name[:table_name],.. verwendet. Es handelt sich dabei um einen Tabellenexport. Folgendes Beispiel illustriert das Vorgehen. 
expdp directory=home VIEWS_AS_TABLES=oe.orders_view dumpfile=view.dmp
Um die Tabellen Metadaten zu erzeugen, ist temporär eine Hilfstabelle erforderlich, die automatisch im gleichen Schema erzeugt und nach Beendigung des Exports wieder gelöscht wird. Eine parallele Abfrage auf USER_TABLES oder USER_TAB_COMMENTS liefert den Beweis dazu (siehe Code Beispiel unten). Die Verwendung von VIEWS_AS_TABLES ist trotzdem auch in READ ONLY Datenbanken möglich durch die zusätzliche Angabe (siehe Syntax Erweiterung mit table_name) einer Tabelle im gleichen Schema mit entsprechender Struktur. 
SQL> SELECT * FROM user_tab_comments WHERE table_name LIKE 'KU$VAT%'

OWNER TABLE_NAME    TABLE_TYPE
----- ------------- ------------------------------------------------------------
COMMENTS
--------------------------------------------------------------------------------
OE    KU$VAT_92911  TABLE
Data Pump Metadata Template Tabelle for view "OE".ORDERS_VIEW
Um das Ergebnis ohne einen weiteren Daten Import zu verifizieren, erzeugen wir ein SQL Skript und können damit das erzeugte DDL einsehen. 
impdp SQLFILE=i.sql dumpfile=view.dmp directory=home
-- Die Ergebnisdatei i.sql zeigt folgendes Resultat:
... 
-- new object type path: TABLE_EXPORT/VIEWS_AS_TABLES/TABLE
CREATE TABLE "OE"."ORDERS_VIEW"
   (    "ORDER_ID" NUMBER(12,0),
        "ORDER_DATE" DATE,
        "ORDER_MODE" VARCHAR2(8 BYTE),
        "CUSTOMER_ID" NUMBER(6,0) NOT NULL ENABLE,
        "ORDER_STATUS" NUMBER(2,0),
        "ORDER_TOTAL" NUMBER(8,2),
        "SALES_REP_ID" NUMBER(6,0),
        "PROMOTION_ID" NUMBER(6,0)
   ) SEGMENT CREATION DEFERRED
  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
NOCOMPRESS NOLOGGING TABLESPACE "EXAMPLE" ;
...
Wer dem Ergebnis nicht traut, kann natürlich einen vollständigen Daten Import vornehmen.

Import ohne Archive Logging
Um die Import Performance bei eingeschaltetem Archive Logging zu erhöhen, gibt es jetzt die Möglichkeit das Archive Logging für die entsprechende Tabellen und Indizes während des Imports auszuschalten. Die neue Syntax lautet TRANSFORM=DISABLE_ARCHIVE_LOGGING:[Y | N]. Das Flag Y schaltet dabei das Feature ein. Das Flag N ist die Defaulteinstellung. Diese Option ist auch verwendbar über das Package DBMS_DATAPUMP.

Die Einstellung der Datenbank sollte dabei nicht FORCE LOGGING sein, da dieses Feature dann überschrieben wird. Da wir einen Import in den Tablespace USERS machen werden, wird im nächsten Beispiel die FORCE_LOGGING Einstellungen für die Tablespaces überprüft. FORCE LOGGING ist für den Tablespace USERS nicht aktiviert. 
SQL> SELECT tablespace_name, force_logging, compress_for 
     FROM dba_tablespaces;

TABLESPACE_NAME                FOR COMPRESS_FOR
------------------------------ --- ---------------
SYSTEM                         YES
SYSAUX                         YES
UNDOTBS1                       NO
TEMP                           NO
USERS                          NO
EXAMPLE                        NO
Mit folgendem Aufruf werden die Schemaobjekte des Users SH ohne Archive Logging für Tabellen und Indizes importiert. 
impdp TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y dumpfile=sh.dmp directory=home 
remap_schema=sh:test
Um den Unterschied festzustellen, wird der Import noch einmal mit der Option DISABLE_ARCHIVE_LOGGING:N durchgeführt. Die Überwachung der Archive Logs in beiden Fällen zeigt, dass beim ersten Versuch (siehe Code Beispiel oben) weniger Archive Logs - in unserem Beispiel keine weiteren Archive Logs - erzeugt werden.

Änderung an Komprimierung und LOB- Einstellungen
Wie kann man beim Import die Komprimierungseigenschaften einer Tabelle ändern? Wie können die Eigenschaften von LOBs (SecureFiles oder BasicFiles) beim Import geändert werden? Auch hierbei kann die Import Option TRANSFORM, die übrigens schon in älteren Versionen der Datenbank (Beispiel Deferred Segment Creation) eingesetzt wird, verwendet werden.

Im Fall der Tabelleneinstellung Komprimierung wird dazu folgende Syntax verwendet: TRANSFORM=TABLE_COMPRESSION_CLAUSE:[NONE | compression_clause]. Die Idee ist, unabhängig von der Komprimierungseigenschaft der Tabelle im Export bzw. des Ziel Tablespaces den Import durchzuführen. Um dies zu illustrieren, verwenden wir im nächsten Beispiel die Tabelle CUST_COPY, die unkomprimiert exportiert wurde. Diese soll im Zielsystem komprimiert - mit COMPRESS BASIC - abgespeichert werden. Die Tablespaces (siehe SELECT auf DBA_TABLESPACES oben) besitzen dabei keine Komprimierungseigenschaften. 
impdp dumpfile=sh.dmp directory=home tables=sh.cust_copy 
TRANSFORM = TABLE_COMPRESSION_CLAUSE:\"COMPRESS BASIC\"
Folgende Abfrage zeigt das Ergebnis. Die Tabelle CUST_COPY hat die Eigenschaft COMPRESS BASIC. 
SQL> SELECT table_name, compression, compress_for 
     FROM dba_tables
     WHERE table_name LIKE 'CUST%' AND owner='SH';

TABLE_NAME           COMPRESS COMPRESS_FOR
-------------------- -------- ------------------------------
CUST2                DISABLED
CUST_COPY            ENABLED  BASIC
CUST_COPY_READ       DISABLED
CUSTOMERS            DISABLED
Die Änderung von BasicFile nach SecureFile funktioniert ganz analog. Hier wird die Syntax TRANSFORM=LOB_STORAGE:[SECUREFILE | BASICFILE | DEFAULT | NO_CHANGE] verwendet. Das Schlüsselwort DEFAULT bedeutet übrigens, dass die Eigenschaft BASICFILE bzw. SECUREFILE des exportierten LOBs ignoriert wird und nur die Default Einstellung des Zielsystems über den Initialisierungsparameter DB_SECUREFILE die Speicherart vorgibt.

Auditing mit Unified Auditing
Unified Auditing ist ein neues Security Feature in 12c. Es erlaubt Audit Aufzeichnungen verschiedener Werkzeuge und Schnittstellen einheitlich zu speichern und abzufragen. Dazu gehören auch RMAN, SQL*Loader, Database Vault und Data Pump Aktionen um nur einige Beispiele zu nennen. Das genaue Setup und alle Konfigurationsmöglichkeiten werden wir dann ausführlich in einem weiteren Artikel erläutern. Hier soll nur in Kürze die Informationen beschrieben werden, die die Data Pump betreffen. Zuerst überprüfen wir, ob das Unified Auditing eingeschaltet ist. 
SQL> SELECT parameter, value 
     FROM v$option WHERE parameter LIKE 'Uni%'
PARAMETER            VALUE
-------------------- ----------
Unified Auditing     TRUE
Zur Aktivierung sind sogenannte Audit Policies nötig. Zusätzlich ist ein Audit Kommando erforderlich, das das Auditing für bestimmte oder für alle User einschaltet. Unser Setup sieht folgendermaßen aus: 
-- Audit Policy für Export Operationen
CREATE AUDIT POLICY exp_policy 
ACTIONS COMPONENT=DATAPUMP EXPORT;
Audit policy created.

-- Audit Policy für Import Operationen
CREATE AUDIT POLICY imp_policy 
ACTIONS COMPONENT=DATAPUMP IMPORT;
Audit policy created.


-- Export Auditing für den User SYSTEM
AUDIT POLICY exp_policy by system;
Audit succeeded.

-- Import Auditing für alle
AUDIT POLICY imp_policy;
Audit succeeded.
Nach einigen Export und Import Aktionen, kann die View UNIFIED_AUDIT_TRAIL abgefragt werden. Die zwei Spalten mit Präfix "DB_" listen dann die Data Pump spezifische Eigenschaften auf. Um nur die Data Pump Einträge einzusehen, kann auf den Audit Typ "Datapump" gefiltert werden. 
SQL> SELECT dp_boolean_parameters1, dp_text_parameters1, event_timestamp, dbusername 
     FROM unified_audit_trail WHERE audit_type = 'Datapump';

DP_BOOLEAN_PARAMETERS1
--------------------------------------------------------------------------------
DP_TEXT_PARAMETERS1
--------------------------------------------------------------------------------
EVENT_TIMESTAMP
---------------------------------------------------------------------------
DBUSERNAME
------------------------------
...
MASTER_ONLY: FALSE, DATA_ONLY: FALSE, METADATA_ONLY: FALSE, DUMPFILE_PRESENT: TR
UE, JOB_RESTARTED: FALSE
MASTER TABLE:  "SYSTEM"."SYS_EXPORT_SCHEMA_01" , JOB_TYPE: EXPORT, METADATA_JOB_
MODE: SCHEMA_EXPORT, JOB VERSION: 12.1.0.0.0, ACCESS METHOD: AUTOMATIC, DATA OPT
IONS: 0, DUMPER DIRECTORY: NULL  REMOTE LINK: NULL, TABLE EXISTS: NULL, PARTITIO
N OPTIONS: NONE
21-AUG-13 06.00.19.986532 PM
SYSTEM
...
Die Multitenant Architektur
Wie verhält sich die Data Pump beim Import in eine Multitenant Database Architektur? Gibt es Einschränkungen oder gar neue Syntax zu beachten? Im Prinzip gibt es keine Änderungen bis auf einige Hinweise, die im Database Utilities Handbuch nachzulesen sind. Die Nutzung der Data Pump ist generell in allen Architekturen identisch verwendbar - egal ob mit einer CDB oder Non-CDB gearbeitet wird. Die Data Pump kann beispielsweise verwendet werden, um Daten aus einer Non-CBD in eine PDB zu importieren oder Daten von einer PDB in eine andere PDB gleicher oder unterschiedlicher CDBs zu transportieren. Natürlich funktioniert auch der umgekehrte Weg von einer PDB in eine Non-CDB. Wichtiges Hilfsmittel ist, wie wir schon im Tipp zu Services in der Datenbank angesprochen haben, die Verwendung von Services bei der Connection.

Um ein Beispiel zu geben, wird im Folgenden der Import von sh.dmp (die Quelldatenbank war eine Non-CDB) in eine PDB durchgeführt. Daher überprüfen wir im ersten Schritt die Services und das Vorhandensein des Directories in der entsprechenden PDB. 
SQL> SELECT name, pdb FROM v$services;
NAME                    PDB
----------------------- --------------------
pdb1.de.oracle.com      PDB1
pdborcl.de.oracle.com   PDBORCL
orclXDB                 CDB$ROOT
...

SQL> ALTER SESSION SET container=pdb1;
Statement processed.

SQL> SELECT directory_name, directory_path FROM all_directories;
DIRECTORY_NAME DIRECTORY_PATH
-------------- ----------------
HOME           /home/oracle
...
Nun kann der Import über die Verbindung mit PDB1 durchgeführt werden. 
impdp system@pdb1 dumpfile=sh.dmp directory=home
Import: Release 12.1.0.1.0 - Production on Wed Aug 21 16:12:24 2013

Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.
Password:
Transport der gesamten Datenbank
Die Transportable Tablespace Technologie ist eine seit langem bewährte Technologie. Sie stellt eine gute Alternative dar, um Daten schnell zu bewegen, da die meisten Operationen bis auf die Kopie der Datendateien sehr schnell durchgeführt werden können. Währenddessen stehen die beiden Systeme nahezu uneingeschränkt zur Verfügung bis auf die Zeitspanne, in der die zu transportierenden Tablespaces READ ONLY gesetzt sind. Nachzulesen ist die Funktionsweise auch im Tipp Transportable Tablespaces: Grundlagen und Einsatz am Beispiel.

Einziger Wermutstropfen bestand in der Tatsache, dass alle Informationen ausser die Dictionary Informationen - Informationen aus dem SYSTEM Tablespace - transportiert werden konnten. Die fehlenden Data Dictionary Informationen mussten in einem separaten Import ohne zusätzliche Dateninformationen und dann noch mit zusätzlichen Skripten hinzugefügt werden.

Diese Einschränkung ist in 12c aufgehoben. Es gibt nun einen Transport für die gesamte Datenbank. Das Vorgehen ähnelt bis auf einige syntaktische Unterschiede fast vollständig dem Transport einzelner Tablespaces. Statt eine Liste der Tablespaces über TRANSPORTABLE_TABLESPACES beim Export anzugeben, wird nun der Parameter TRANSPORTABLE=ALWAYS verwendet und zusätzlich die Option FULL=Y eingesetzt. Auch hier müssen wie im Falle des Transports einzelner Tablespaces alle User-definierten Tablespaces vorher READ ONLY gesetzt werden. Übrigens funktioniert der Export auch ab Version 11.2.0.3. Der Import wird allerdings erst mit Oracle Database Version 12c unterstützt. Folgendes Beispiel zeigt die Operation in einer 11.2.0.3 Umgebung. 
expdp system full=y dumpfile=expdatfull.dmp directory=home 
TRANSPORTABLE=ALWAYS VERSION=12 logfile=exportfull.log
Hinweis: Der Parameter VERSION=12 ist nur erforderlich, da mit einer Datenbank der Version 11.2.0.3 gearbeitet wird. Ab 12c ist dies natürlich nicht mehr nötig. Die Prozedur für den Import verläuft analog zu der Prozedur des Transports einzelner Tablespaces. Möchte man eine detaillierte Auflistung der Schritte nachlesen, kann man sich im Handbuch in Kapitel 15 informieren.

Zurück zur Community-Seite