Table of Contents
Ziel
Dieser Artikel soll Aufschluss darüber geben, wie sich Trigger bei einem Export / Import mit DataPump verhalten. Es sollen die folgenden Fragen beantwortet werden.
- Werden bei einem DataPump Import Trigger ausgelöst?
- Wenn ja, unter welchen Voraussetzungen werden die Trigger ausgelöst?
Voraussetzung
Als Testumgebung habe ich eine Oracle Real Application Cluster 10g Release 2 Installation verwendet. Für die Durchführung dieses Artikel kann jede Umgebung mit Oracle ab Version 10g verwendet werden.
Vorbereitung
Für den Export und Import werde ich zunächst ein paar Datenbankobjekte anlegen.
Als erstes lege ich ein physikalische Dateisystemverzeichnis an. In diesem werden später die Dumpfiles und Logfiles abgelegt.
[oracle@rac1 ~]$ mkdir /home/oracle/dmp
Anschließend wird ein Directory Objekt, das auf das zuvor erstellte Verzeichnis verweist, angelegt.
[oracle@rac1 ~]$ sqlplus / as sysdba SQL> create or replace directory dpdir as '/home/oracle/dmp';
Im nächsten Schritt wird ein neues Schema angelegt.
SQL> create user dp identified by dp; SQL> grant connect, resource to dp;
Für den Export / Import werde ich nun zwei Tabellen und einen Trigger anlegen.
SQL> create table prod (id number primary key, year number, description varchar2(100); SQL> create table prod_log (id number primary key, year number, description varchar2(100), inserted_on date); SQL> create or replace trigger prod_trg after insert on prod for each row begin insert into prod_log values(:new.id, :new.year, :new.description, sysdate); end prod_trg; /
Die Tabelle PROD stellt unsere Daten Tabelle dar. Auf dieser Tabelle wird ein Trigger angelegt, der bei einem Insert ausgelöst wird. Dieser Trigger loggt den neuen Eintrag in der Tabelle PROD_LOG.
Zum Abschluss der Vorbereitung werden ein paar Testdaten eingefügt.
[oracle@rac1 ~]$ sqlplus dp/dp SQL> insert into prod values(1, 2009, 'Planung DBA-Blog'); SQL> insert into prod values(2, 2010, 'Start DBA-Blog'); SQL> insert into prod values(3, 2010, 'Erster Beitrag'); SQL> insert into prod values(4, 2010, 'Verknüpfung mit Facebook'); SQL> commit;
Überprüfung der Logtabelle.
SQL> set linesize 250 SQL> select * from prod_log ID YEAR DESCRIPTION INSERTED ------- ---- --------------------------- -------- 1 2009 Planung DBA-Blog 13.01.11 2 2010 Start DBA-Blog 13.01.11 3 2010 Erster Beitrag 13.01.11 4 2010 Verkn?pfung mit Facebook 13.01.11
Der Test verlief erfolgreich.
Export erstellen
Für die Import Tests wird nun das neu angelegte Schema exportiert. Die Logtabelle wird zuvor bereingt.
SQL> truncate table prod_log;
Anschließend kann der DataPump Export mithilfe von expdp durchgeführt werden. Es wird nur das Schema DP exportiert – man spricht hier von einem Schema Export.
[oracle@rac1 ~]$ expdp system/oracle directory=dpdir dumpfile=exp_dp_schema.dmp logfile=exp_db_schema.log schemas=dp Export: Release 10.2.0.4.0 - Production on Thursday, 13 January, 2011 20:36:07 Copyright (c) 2003, 2007, Oracle. All rights reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production With the Partitioning, Real Application Clusters, OLAP, Data Mining and Real Application Testing options FLASHBACK automatisch aktiviert, um Datenbankintegritat aufrechtzuerhalten. "SYSTEM"."SYS_EXPORT_SCHEMA_01": system/******** directory=dpdir dumpfile=exp_dp_schema.dmp logfile=exp_db_schema.log schemas=dp wird gestartet Schatzung erfolgt mit Methode BLOCKS... Objekttyp SCHEMA_EXPORT/TABLE/TABLE_DATA wird verarbeitet Gesamte Schatzung mit BLOCKS Methode: 64 KB Objekttyp SCHEMA_EXPORT/USER wird verarbeitet Objekttyp SCHEMA_EXPORT/SYSTEM_GRANT wird verarbeitet Objekttyp SCHEMA_EXPORT/ROLE_GRANT wird verarbeitet Objekttyp SCHEMA_EXPORT/DEFAULT_ROLE wird verarbeitet Objekttyp SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA wird verarbeitet Objekttyp SCHEMA_EXPORT/TABLE/TABLE wird verarbeitet Objekttyp SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT wird verarbeitet Objekttyp SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS wird verarbeitet Objekttyp SCHEMA_EXPORT/TABLE/TRIGGER wird verarbeitet Objekttyp SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS wird verarbeitet . . "DP"."PROD" 5.632 KB 4 Zeilen exportiert . . "DP"."PROD_LOG" 0 KB 0 Zeilen exportiert Master-Tabelle "SYSTEM"."SYS_EXPORT_SCHEMA_01" erfolgreich geladen/entladen ****************************************************************************** Fur SYSTEM.SYS_EXPORT_SCHEMA_01 festgelegte Dump-Datei ist: /home/oracle/dmp/exp_dp_schema.dmp Job "SYSTEM"."SYS_EXPORT_SCHEMA_01" erfolgreich um 20:36:56 abgeschlossen
Szenario 1: Schema Import
Im ersten Test wird das komplette Schema importiert. die bestehenden Tabellen werden dabei überschrieben. Dafür sorgt der Parameter TABLE_EXISTS_ACTION mit dem Wert REPLACE. Ohne Angabe dieses Parameters würden die Tabellen übersprungen werden.
[oracle@rac1 ~]$ impdp system/oracle directory=dpdir dumpfile=exp_dp_schema.dmp logfile=imp_dp_schema.log schemas=dp table_exists_action=replace Import: Release 10.2.0.4.0 - Production on Thursday, 13 January, 2011 20:38:45 Copyright (c) 2003, 2007, Oracle. All rights reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production With the Partitioning, Real Application Clusters, OLAP, Data Mining and Real Application Testing options Master-Tabelle "SYSTEM"."SYS_IMPORT_SCHEMA_01" erfolgreich geladen/entladen "SYSTEM"."SYS_IMPORT_SCHEMA_01": system/******** directory=dpdir dumpfile=exp_dp_schema.dmp logfile=imp_dp_schema.log schemas=dp table_exists_action=replace wird gestartet Objekttyp SCHEMA_EXPORT/USER wird verarbeitet ORA-31684: Objekttyp USER:"DP" ist schon vorhanden Objekttyp SCHEMA_EXPORT/SYSTEM_GRANT wird verarbeitet Objekttyp SCHEMA_EXPORT/ROLE_GRANT wird verarbeitet Objekttyp SCHEMA_EXPORT/DEFAULT_ROLE wird verarbeitet Objekttyp SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA wird verarbeitet Objekttyp SCHEMA_EXPORT/TABLE/TABLE wird verarbeitet Objekttyp SCHEMA_EXPORT/TABLE/TABLE_DATA wird verarbeitet . . "DP"."PROD" 5.632 KB 4 Zeilen importiert . . "DP"."PROD_LOG" 0 KB 0 Zeilen importiert Objekttyp SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT wird verarbeitet Objekttyp SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS wird verarbeitet Objekttyp SCHEMA_EXPORT/TABLE/TRIGGER wird verarbeitet Objekttyp SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS wird verarbeitet Job "SYSTEM"."SYS_IMPORT_SCHEMA_01" mit 1 Fehler(n) um 20:38:55 abgeschlossen
Da ich das DP Schema vorher nicht gelöscht habe, wird ein Fehler während des Imports gemeldet. Dieser kann ignoriert werden.
Nun wird die Logtabelle überprüft. Sollte es Einträge geben, würden bei einem Schema Import die Trigger ausgelöst werden.
[oracle@rac1 ~]$ sqlplus dp/dp SQL> set linesize 250 SQL> select * from prod_log; Es wurden keine Zeilen ausgewahlt
Wie die Ausgabe zeigt wurde die Tabelle nicht gefüllt – der Trigger wurde nicht ausgelöst.
Szenario 2: Getrennter Import der Metainformationen und der Tabellendaten
Bei diesem Szenario werden zwei Imports durchgeführt. Im ersten Schritt werden nur die Metadaten (Data Dictionary Informationen) importiert. Bei dieser Importart werden nur die Schema Objekte angelegt – es werden keine Tabellenzeilen importiert.
In diesem Fall werde ich zunächst das Schema DP löschen.
[oracle@rac1 ~]$ sqlplus / as sysdba SQL> drop user dp cascade;
Der DataPump Import wird mit der folgenden Anweisung gestartet.
[oracle@rac1 ~]$ impdp system/oracle directory=dpdir dumpfile=exp_dp_schema.dmp logfile=imp_dp_schema_md.log schemas=dp content=metadata_only Import: Release 10.2.0.4.0 - Production on Thursday, 13 January, 2011 20:46:25 Copyright (c) 2003, 2007, Oracle. All rights reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production With the Partitioning, Real Application Clusters, OLAP, Data Mining and Real Application Testing options Master-Tabelle "SYSTEM"."SYS_IMPORT_SCHEMA_01" erfolgreich geladen/entladen "SYSTEM"."SYS_IMPORT_SCHEMA_01": system/******** directory=dpdir dumpfile=exp_dp_schema.dmp logfile=imp_dp_schema_md.log schemas=dp content=metadata_only wird gestartet Objekttyp SCHEMA_EXPORT/USER wird verarbeitet Objekttyp SCHEMA_EXPORT/SYSTEM_GRANT wird verarbeitet Objekttyp SCHEMA_EXPORT/ROLE_GRANT wird verarbeitet Objekttyp SCHEMA_EXPORT/DEFAULT_ROLE wird verarbeitet Objekttyp SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA wird verarbeitet Objekttyp SCHEMA_EXPORT/TABLE/TABLE wird verarbeitet Objekttyp SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT wird verarbeitet Objekttyp SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS wird verarbeitet Objekttyp SCHEMA_EXPORT/TABLE/TRIGGER wird verarbeitet Objekttyp SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS wird verarbeitet Job "SYSTEM"."SYS_IMPORT_SCHEMA_01" erfolgreich um 20:46:31 abgeschlossen
Nachdem der Import der Metadaten abgeschlossen ist, können nun die Tabellenzeilen importiert werden.
[oracle@rac1 ~]$ impdp system/oracle directory=dpdir dumpfile=exp_dp_schema.dmp logfile=imp_dp_schema_md.log schemas=dp content=data_only Import: Release 10.2.0.4.0 - Production on Thursday, 13 January, 2011 20:47:36 Copyright (c) 2003, 2007, Oracle. All rights reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production With the Partitioning, Real Application Clusters, OLAP, Data Mining and Real Application Testing options Master-Tabelle "SYSTEM"."SYS_IMPORT_SCHEMA_01" erfolgreich geladen/entladen "SYSTEM"."SYS_IMPORT_SCHEMA_01": system/******** directory=dpdir dumpfile=exp_dp_schema.dmp logfile=imp_dp_schema_md.log schemas=dp content=data_only wird gestartet Objekttyp SCHEMA_EXPORT/TABLE/TABLE_DATA wird verarbeitet . . "DP"."PROD" 5.632 KB 4 Zeilen importiert . . "DP"."PROD_LOG" 0 KB 0 Zeilen importiert Job "SYSTEM"."SYS_IMPORT_SCHEMA_01" erfolgreich um 20:47:43 abgeschlossen
Die Ausgabe zeigt, dass keine Zeilen in die Tabelle PROD_LOG importiert wurden. Nun muss überprüft werden, ob sich tatsächlich keine Zeilen in der Tabelle befinden.
[oracle@rac1 ~]$ sqlplus dp/dp SQL> set linesize 250 SQL> select * from prod_log; ID YEAR DESCRIPTION INSERTED ------- ---- ---------------------------- -------- 1 2009 Planung DBA-Blog 13.01.11 2 2010 Start DBA-Blog 13.01.11 3 2010 Erster Beitrag 13.01.11 4 2010 Verkn?pfung mit Facebook 13.01.11
Tatsächlich aber befinden sich Zeilen in der Logtabelle. Das belegt, dass bei einem reinen Datenimport (CONTENT=DATA_ONLY) die vorhandenen und aktivierten Trigger ausgelöst werden.
Dies kann zu Problemen führen. In solch einem Fall sollten die Trigger nach dem Import der Metadaten deaktiviert werden. Nach dem Import der Daten können diese dann wieder aktiviert werden. Ein Trigger kann mit dem folgenden SQL Statement deaktiviert werden.
SQL> alter trigger prod_trg disable;
Die Aktivierung eines Trigger erfolgt dann wiederum mit einer ALTER TRIGGER Anweisung.
SQL> alter trigger prod_trg enable;
Zusammenfassung
Bei Verwendung bestimmter Parameter kann es passieren, dass Trigger während des Imports ausgelöst werden. Dies passiert zum Beispiel bei einem reinen Import der Tabellendaten (ohne Metadaten).