Gunther Oracle APEX und Datenbank Wiki

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
===== Oracle Data Pump Schema Export und Import =====



==== Übersicht ====

siehe über Slideshare:

[slideshare id=56210681&doc=03-datapump11g12cgpi2015-151216164539]


----

==== Beispiele ====
Aufgabe:

Export aller Daten einer Entwicklungsumgebung  und Import der Content Schemata in eine ähnliche Entwicklungsdatenbank.


Ablauf:
  * Quelle und Ziel : Tablespace Strukturen vergleichen
  * Quelle : Export Directory kontrollieren
  * Quelle : SCN für konsistenten Export ermitteln
  * Quelle : Daten exportieren
  * Ziel   : Zu ersetzende Schemata "leeren"
  * Ziel   : Audit Log / Recycle Bin bei Bedarf leeren
  * Ziel   : Daten der Schemata einfügen
  * Ziel und Quelle  : Vergleichen ob alles (Rechte/Objektanzahl) importiert wurde 
  * Ziel   : Statistiken im Schema neu aufbauen


Ale SQL Befehle und der Import / Export werden das SYS User durchgeführt.

===Quelle und Ziel :Tablespace Strukturen vergleichen===

Mit entsprechenden Skript [[https://orapowershell.codeplex.com/SourceControl/latest#sql/dbfiles.sql|dbfiles.sql]] prüfen, das die gleiche Tablespace Struktur wie im Ziel auch in der Quelle gegeben ist. 

===Quelle : Export Directory kontrollieren===

Directories anzeigen lassen:
<code sql>

select owner
      ,directory_name
      ,directory_path
  from dba_directories
 order by 1
         ,2
/
</code>

Siehe auch passendes Script unter: [[https://orapowershell.codeplex.com/SourceControl/latest#sql/directory.sql|directory.sql]]

Passendes Directory wie DATA_PUMP_DIR auswählen, Dateipfad prüfen, auf ausreichend Plattenplatz achten.


===Quelle : SCN für konsistenten Export ermitteln===

Für einen konsistenten Export (Alle Daten entsprechen logisch dem gleichen Lesezeitpunkt in der Datenbank) wird der Parameter FLASHBACK_SCN gesetzt.

Ermitteln mit:
<code sql>
 select name
     , to_char(sysdate,'dd.mm.yyyy hh24:mi')
     , current_scn 
    from v$database
 /   
NAME      TO_CHAR(SYSDATE, CURRENT_SCN
--------- ---------------- -----------
GPIDB1    08.08.2013 19:49   582159018
</code>



===Quelle : Daten exportieren===

Parfile für den Export anlegen:

<code bash>
vi ~/full_export_GPIDB1.dpctl

DIRECTORY=DATA_PUMP_DIR 
LOGFILE=expdp_08-08-2013_19_49_GPIDB1.log
DUMPFILE=expdp_08-08-2013_19_49_GPIDB1%u.dmp
FILESIZE=20G 
REUSE_DUMPFILES=Y 
COMPRESSION=ALL 
FULL=Y 
FLASHBACK_SCN=582159018
JOB_NAME=EXPDP_582159018

</code>

Nach 20GB die Datei aufsplitten, damit das nicht zu groß für das Dateisystem ist.

Oder mit "FLASHBACK_TIME=SYSTIMESTAMP" auf das aktuelle Datum setzen!

Alternativ eine festen Zeitpunkt setzen mit FLASHBACK_TIME, für einen Aufruf in der Kommando Zeile entsprechend escapen:

<code bash>
TIMESTAMP_EXPORT=`date "+%Y%m%d-%H%M%S"`
expdp  …  FLASHBACK_TIME=\"to_timestamp\(\'$TIMESTAMP_EXPORT\',\'yyyymmdd-hh24miss\'\)\"    …
</code>

Da eine EE Edition zur Verfügung steht kann mit Compression gearbeitet werden.\\
Der Job Name hilft bei Unterbrechungen und Problemen den Job wieder kontrolliert auf zunehmen.


Export aufrufen:
<code bash>
$ORACLE_HOME/bin/expdp "'/ as SYSDBA'" parfile=~/full_export_GPIDB1.dpctl
</code>

Logfile auf Fehler prüfen, dmp zusätzlich mit "gzip" einpacken und auf die Ziel Maschine kopieren.

===Ziel   : Zu ersetzende Schemata "leeren"===

Das einige Anhängigkeiten zu anderen Schemas in der Datenbank bestehen, wurde auf die Option das Schema mit "drop user xxxx cascade;" zu löschen und neu mit Data Pump anzulegen verzichtet.

Alle Objekte in den zu importierenden Schemata werden gelöscht.

Das Lösch Script erstellt mit Hilfe des Data Dictionary die entsprechenden  Drop Befehl:
  * Advanced Queue's entfernen
  * XMLDB XSD's entfernen
  * Tabellen FK Constraints löschen, um keine Problem beim Löschen der Tabellen zu bekommen
  * Schema Objekte in der Reihenfolge der Objektabhängigkeit löschen

Siehe folgendes Script: [[https://orapowershell.codeplex.com/SourceControl/latest#sql/clean_user.sql|clean_user.sql]]

Vor dem Aufruf des erzeugten Delete Skripts sollte auf jeden Fall der Recycle Bin des Schemas geleert werden, da zum Teil DB Objekte wie ein "Type" sich nicht löschen lassen, wenn Objekte im Recycle Bin diese verwenden.


===Ziel   : Audit Log / Recycle Bin bei Bedarf leeren===

Vor dem Import bei Bedarf das Audit Log der DB und den gesamten Recyle Bin leeren und prüfen ob die Recovery Area nicht vollläuft.

<code sql>
truncate table aud$;

PURGE DBA_RECYCLEBIN;

achive log list

</code>

Recovery Area prüfen mit: [[https://orapowershell.codeplex.com/SourceControl/latest#sql/reco.sql|reco.sql]] , ungültige Objekte übersetzen und mit [[https://orapowershell.codeplex.com/SourceControl/latest#sql/invalid.sql|invalid.sql]] kontrollieren, dass auch alle Object in der DB gültig sind.

<code sql>
@reco.sql

@?/rdbms/admin/utlrp

@invalid.sql
</code>


===Ziel   : Daten der Schemata importieren===

Prüfen ob das Directory für den Import auf der Quelle auf das richtige Verzeichnis zeigt
(siehe ersten Schritt weiter oben).

ParFile für den Import erstellen:
<code bash>
vi ~/import_GPIDB1_DATA.dpctl

DIRECTORY=DATA_PUMP_DIR 
LOGFILE=impdp_08-08-2013_20_20_GPIDB1.log
DUMPFILE=expdp_08-08-2013_19_49_GPIDB1.dmp 
JOB_NAME=IMP_GPIDATA_v1
SCHEMAS=GPDATA,WEB_DATA,ETL_CONFIG

</code>

Sollen die Daten von einen Schema in ein anders übertragen werden, wird diese über die "REMAP_SCHEMA" Anweisung definiert, muss auch noch der Tablespace angepasst werden hilft "REMAP_TABLESPACE" in der Steuerdatei:
<code bash>

SCHEMAS=USER1
REMAP_SCHEMA=USER1:USER2
REMAP_TABLESPACE=DEV_DATA:USER_DATA

</code>

Aufruf:
<code bash>
 $ORACLE_HOME/bin/impdp "'/ as SYSDBA'" parfile=~/import_GPIDB1_DATA.dpctl
</code>

Log file auf Fehler prüfen.

Der Job Name ist sehr wichtig um bei Bedarf wieder die Data Pump Console zu starten mit:
<code bash>

$ORACLE_HOME/bin/impdp "'/ as SYSDBA'" attach=IMP_GPIDATA_v1

</code>

===Ziel und Quelle  : Vergleichen ob alles (Rechte/Objektanzahl) importiert wurde ===


Auf Ziel und Quelle Objektanzahl und Rechte vergleichen:
<code sql>
SET linesize 130 pagesize 30 recsep OFF


select owner
      ,obj_type
      ,obj_count 
from (
    select count(*) as obj_count, object_type as obj_type, owner   
      from dba_objects 
     group by object_type,owner	
 ) 
where owner not in ('SYS','MDSYS','SI_INFORMTN_SCHEMA','ORDPLUGINS','ORDDATA','ORDSYS','EXFSYS','XS$NULL','XDB','CTXSYS','WMSYS','APPQOSSYS','DBSNMP','ORACLE_OCM','DIP','OUTLN','SYSTEM','FLOWS_FILES','PUBLIC','SYSMAN','OLAPSYS','OWBSYS','OWBSYS_AUDIT')
group by owner,obj_type,obj_count
order by owner,obj_type
/



column grantee format a25
column GRANTOR format a25
column PRIVILEGE format a25
column cnt format 9999



select GRANTOR
     , grantee
     , PRIVILEGE  
     , count(*) as cnt
 from DBA_TAB_PRIVS 
where owner not in ('SYS','MDSYS','SI_INFORMTN_SCHEMA','ORDPLUGINS','ORDDATA','ORDSYS','EXFSYS','XS$NULL','XDB','CTXSYS','WMSYS','APPQOSSYS','DBSNMP','ORACLE_OCM','DIP','OUTLN','SYSTEM','FLOWS_FILES','PUBLIC','SYSMAN','OLAPSYS','OWBSYS','OWBSYS_AUDIT')
group by owner,grantee,GRANTOR,PRIVILEGE
order by 1,2,3
/

</code>

===Ziel : Statisiken neu aufbauen ===



<code sql>

exec DBMS_STATS.GATHER_SCHEMA_STATS ('GPI')

</code>


----


----

===== Nur die Größe eines Export ermitteln====

Mit dem Parameter "estimate_only=y" läßt sich ermittlen wie groß ein Export ungefähr werden wird.

<code bash>
expdp "'/ as sysdba'" ESTIMATE_ONLY=YES FULL=Y DIRECTORY=FULL_DB_EXPORT JOB_NAME=EXP_SPACE_V01 LOGFILE=estimate_export.log

...
Total estimation using BLOCKS method: 108.7 GB
Job "SYS"."EXP_SPACE_V01" successfully completed at Mon Nov 5 18:30:57 2018 elapsed 0 00:01:28

... 
</code>



----

===== Anwendungsfall Dump files validieren ===== 

Mit Hife eines extracts allem SQL's läßt sich auch verifizieren ob ein Dump einer Datenbank komplett ist, zum Beispiel wenn der Dump mit %U exportiert wurde und aus vielen Dateien besteht.

<code sql>
impdp "'/ as sysdba'" directory=TEST_DUMP dumpfile=GPI_%U.dmp logfile=check_GPI.log sqlfile=GPI_check.sql JOB_NAME=GPI_CHECK
</code>


===== Anwendungsfall SQL extrahieren ===== 


Mit dem Parameter SQLFILE läßt sich das SQL aus dem Export extrahieren (liegt dann im directory exp_dir):

<code>
 impdp scott/tiger directory=exp_dir dumpfile=scott.dmp sqlfile=script.sql
</code>


Dies ist recht hilfreich um zum Beispiel all Object Grants wieder herzustellen:

<code>

impdp  scott/tiger directory=exp_dir dumpfile=scott.dmp sqlfile=grant_obj.sql content=metadata_only include=OBJECT_GRANT remap_schema=scott:gpi 

#SQL File bereinigen falls notwendig:

sed -i -e 's/gpi/gpi_prod/g' grant_obj.sql


# und grants einspielen:

sqlplus / as sysdba @grant_obj.sql


</code>

Oder zum Beispiel die Tablespaces und die User und Rollen vor dem Import anzulegen mit **"include=TABLESPACE,USER,ROLE"**





----

----


===== Anwendungsfall - Nur bestimmte Tabellen exportieren und importieren ===== 

==== Export ==== 

Anlegen eines Parameter Datei und aufrufen mit "expdp "'/ as sysdba'" parfile=export.dpctl"

=== Mit Angabe des Schemas und der Tabellen=== 

<code>
DIRECTORY=DATA_PUMP_DIR
TABLES=GPI."EMP",GPI."DEPT"
TABLES=GPI."HIBERNATE_UNIQUE_KEY",GPI."USER_ADDRESSES"
</code>

Falls viele Tabellen exportiert werden sollen, in mehre Zeilen aufzählen damit der Input Wert nicht zu lang wird.


=== Über eine Steuertabelle und mit Angabe des Zeitpunktes ===

Im zu exportierenden Schema wird eine Tabelle angelegt, die alle Tabellenname enthält die exportiert werden sollen. Auf diese Tabelle wird dann referenziert.

<code>
SCHEMAS=GPI
INCLUDE=TABLE:"IN (SELECT table_name FROM GPI_EXP_TAB)" 
FLASHBACK_TIME="to_timestamp('20140820-112640','yyyymmdd-hh24miss')" 
CONTENT=ALL 
</code>


=== Mit Hilfe der Include Anweisung=== 

Nur Tabellen
<code>
DIRECTORY=DATA_PUMP_DIR
SCHEMAS=GPI
INCLUDE=TABLE
</code>

Für den richtigen Include Parameter für die jeweiligen Objekte die folgenden Views abfragen:
  * DATABASE_EXPORT_OBJECTS for Full mode
  * SCHEMA_EXPORT_OBJECTS for schema mode
  * TABLE_EXPORT_OBJECTS for table and tablespace mode



Filter auf nur bestimmte Tabellen

<code>
DIRECTORY=DATA_PUMP_DIR
DUMPFILE=tab_gpi_users.dmp
SCHEMAS=GPI
INCLUDE=TABLE:"like 'USER%'"
</code>


=== Mit Angabe eines Tablespaces=== 

Leider kann Schema und Tablespace nicht gemischt werden!

<code>
DIRECTORY=DATA_PUMP_DIR
DUMPFILE=tablespace_users.dmp
TABLESPACES=USERS
</code>


==== Import ==== 


Anlegen eines Parameter Datei und aufrufen mit "imdp "'/ as sysdba'" parfile=export.dpctl"


=== Nur neue User aus dem DUMP ===

<code bash>
impdp "'/ as sysdba'" full=y 'exclude=SCHEMA:"IN(select username from all_users)"'
</code>

=== Nur eine Tabelle === 

<code>
DIRECTORY=DATA_PUMP_DIR
DUMPFILE=tablespace_users.dmp
TABLES=GPI.EMP
</code>


<code>
DIRECTORY=DATA_PUMP_DIR
DUMPFILE=tab_gpi_users.dmp
SCHEMAS=GPI
INCLUDE=TABLE:"like 'USER%'"
</code>

siehe für Include Anweisung auch : http://docs.oracle.com/cd/E11882_01/server.112/e22490/dp_import.htm#SUTIL3145 


Regel was passieren soll falls die Tabelle bereits exisiert:

<code>
TABLE_EXISTS_ACTION=REPLACE
</code>

Regeln
  * REPLACE   - ersetzen - Tabelle löschen und neu anlegen
  * SKIP      - überspringen - default!
  * APPEND    - anhängen - Daten einfügen
  * TRUNCATE  - Tabelle zuvor leeren und dann Daten einfügen


=== Import Fehler === 

<code>

Parameter:

SCHEMAS=GPI
INCLUDE=TABLE:"like 'EMP%'"

#Fehler

ORA-31655: no data or metadata objects selected for job
ORA-39039: Schema expression " IN ('GPI')" contains no valid schemas.
</code>

Fehler: **Export wurde im Tablespace Mode durchgeführt, dann kann bei einem Import nicht mit Schema gefiltert werden!**



----

====Segement Storage Parameter beim Import ignorieren bzw .anpassen ====




Mit "transform=segment_attributes" können die Storage parameter beim Anlegen eines Objects ingnoriert werden.

**Syntax : TRANSFORM = transform_name:value[:object_type]**


  * SEGMENT_ATTRIBUTES - Wenn N , dann werden die segment attributes (physical attributes, storage attributes, tablespaces, and logging) ignoriert
  * STORAGE - Wenn N, wird die storage clauses ignoriert
  * SEGMENT_CREATION  - Wenn auf N und DB Paramter , dann werden die intial Segements  nur angelegt wenn es dafür auch Daten gibt - Ab 11.2.0.2!
  * OID - Wenn N neue OIDs werden angelegt
  * PCTSPACE - Percentage multiplier für alter extent allocations und die Größe der daten Dateien


Beispiele SEGMENT_ATTRIBUTES:

Auf allen Objekten ignorieren und anderen Tablespace als den Default verwenden:
<code bash>
impdp gpi/gpi transform=segment_attributes:n remap_tablespace=PROD_DATA:GPI_DATA
</code>


Nur auf Tabellen ignorieren:
<code bash>
impdp gpi/gpi transform=segment_attributes:n:TABLE
</code>

Beispiele STORAGE:


<code bash>
impdp gpi/gpi transform=storage:n
</code>

see: http://docs.oracle.com/cd/E11882_01/server.112/e16536/dp_import.htm#SUTIL939 ( seach for TRANSFORM) 


----


====  Datapump per PL/SQL Aufrufen ==== 

siehe auch [[dba:datapump_oracle_export_plsql|Wie kann eine Datapump Export über SQL*Plus gestartet werden?]]

----

==== Exclude Hint===

  * http://www.acehints.com/2011/06/data-pump-expdp-how-to-exclude-table.html

Wie:
<code bash>
EXCLUDE=TABLE:"IN ('ORDER')"
</code>

----

==== Bestimmte DB Objekte NICHT exportieren wie DBMS_SCHEDULER Jobs ====


Sollen bei einem Export bestimmte Objekte nicht exportiert werden, kann mit der **EXCLUDE** Anweisung gearbeitet werden, diese kann dann auch direkt auf die Objekt ID's der nicht gewünschten Objekte abgestimmt werden.


Mit diesem Parfile werden:
<code bash>
exclude=procobj:"IN (SELECT NAME FROM sys.OBJ$ WHERE TYPE# IN (47,48,66,67,68,69,71,72,74))"
</code>

Quelle siehe => https://mikedietrichde.com/2011/12/04/exclude-dbms_scheduler-jobs-from-expdp/


----

==== Datapump Import über das Netz ====

Über einen DB Link aus dem Zielsystem das Quellsystem abfragen und dort die Daten einfügen:
<code>
 |-------|                    |-----|
 | PROD  |    <==== DB Link   | TST |
 |-------|                    |-----|
  source                    destination  
</code>

Der Export erfolgt von der "source database" in die "destination database", d.h. der DB Link wird in der "destination database" angelegt!.

Ablauf:
  * SOURCE DB      => User für den Export der Daten anlegen ( oder wie in meinen Fall den SYSTEM user verwenden)
  * DESTINATION DB => DB Directory anlegen 
  * DESTINATION DB => DB Link auf die SourceDB anlegen  
  * DESTINATION DB => Tabellespace Definition erzeugen
  * DESTINATION DB => Object Grants / User / Rollen erzeugen
  * DESTINATION DB => Tablespaces anlegen in der destination DB TST
  * DESTINATION DB => Full import über DB Link starten, über den lokal angemeldeten User 
  * DESTINATION DB => Grants nochmal nachziehen und recompile


DB Directory und Link auf der DESTINATION DB  TST:

<code sql>

-- DB Link
create database link DP_TRANSFER connect to system identified by hugo1oguh using 'gpi_db1';

-- DB Directory
create or replace directory import_dir as '/opt/oracle/import/GPIDB';

-- pürfen ob es auch die richtige DB ist:

select global_name from global_name@DP_TRANSFER;

</code>

Tablespace SQL und Grants holen:
<code bash>
impdp  "'/ as sysdba'" directory=import_dir network_link=DP_TRANSFER sqlfile=tablespaces_gpidb.sql content=metadata_only include=TABLESPACE full=Y

impdp  "'/ as sysdba'" directory=import_dir network_link=DP_TRANSFER sqlfile=users_gpidb.sql content=metadata_only include=USER full=Y

impdp  "'/ as sysdba'" directory=import_dir network_link=DP_TRANSFER sqlfile=roles_gpidb.sql content=metadata_only include=ROLE full=Y

impdp  "'/ as sysdba'" directory=import_dir network_link=DP_TRANSFER sqlfile=object_grants_gpidb.sql content=metadata_only include=OBJECT_GRANT full=Y

</code>

Vor dem eigentlichen Import die Tablespaces vorbereiten ( gleich wie Prod, in meine Fall werden mehr als 400GB übertragen und es muss entsprechend viel Platz vorgehalten werden!)


Full import durchführen in der DESTINATION DB:
<code bash>
# in meinen Fall lasse ich eine sehr große Tabelle erstmal weg um Transactional zu importieren
vi import_gpidb.ctl

DIRECTORY=IMPORT_DIR
LOGFILE=impdp_09-04-2016_08_48_GPIDB.log
network_link=DP_TRANSFER 
JOB_NAME=IMP_GPIDB_V1
FLASHBACK_SCN=8237536
EXCLUDE=TABLE:"IN ('DOKU')"
FULL=Y


#importieren

$ORACLE_HOME/bin/impdp "'/ as SYSDBA'" parfile=import_gpidb.ctl


#Und nun die fehlende Tabelle:

DIRECTORY=BACKUP
LOGFILE=impdp_12-05-2018_11_45_GPIDDBPRD_mediatab.log
network_link=DP_TRANSFER
JOB_NAME=IMP_GPIDB_MEDIATAB
TABLES=GPIMEDIA."DOKU"


</code>


Kann plötzlich der DB Link TNS Name nicht mehr in einer Cluster Umgebung aufgelöst werden, kann es daran liegen das zwar im Cluster erst in der Grid tnsnames gesucht wird und dann im Oracle Home der Datenbank, gelgentlich aber wieder um andersherum, je nach dem in welchen Context die DB wohl ursprünglich gestartet wurde.

Setzte daher die TNS_ADMIN auf die Grid Umgebung und verlink aus der Oracle DB Home Umgebung auf diese tnsnames.ora. Dann gibt es nur eine Datei und wo was gepflegt werden muss, ist gelöst!



Nacharbeiten:
<code sql>
-- Object Grant Script laufen lassen
-- auf ungültige Objecte prüfen
-- alte User wieder entfernen
drop user OLAPSYS cascade;
drop user MDDATA cascade;
drop user SCOTT cascade;

-- synonyme die auf nichts zeigen entfernen
@invalid_synoyms.sql

-- alles ungültige neu übersetuen
@?/rdbms/admin/utlrp

-- Directories prüfen und bei Bedarf anpassen
@directory

</code>
Die Scripte finden Sie in meiner Script Library [[https://orapowershell.codeplex.com/SourceControl/latest#README.txt|OraPowerShell]]


<fc #800000>Einschränkungen - ORA-31679:</fc>

Es können keine Tabelle mit LONG Spalten übertragen werden!
Fehler:
<code sql>
ORA-31679: Table data object "GPI"."VERY_OLD_TABLE" has long columns, and longs can not be loaded/unloaded using a network link
</code>
Diese Tabelle muss nun einzeln aus der Quelle extrahiert werden ....


----

----

===== Problembehandlung =====


===Job bricht ab und kann nicht wieder gestartet werden===

siehe Metalink Node "How To Cleanup Orphaned DataPump Jobs In DBA_DATAPUMP_JOBS ? (Doc ID 336014.1)".



===An job wieder anknüpfen und diesen dann entfernen===

<code bash>
expdp / attach=job_name_as_definied_in_start_of_the_export

Export> KILL_JOB

</code>

=== Datapump Export sehr langsam ===

siehe Metalink Node:

  * Finding Out The Current SQL Statement A Data Pump Process Is Executing (Doc ID 1528301.1)
  * Checklist For Slow Performance Of DataPump Export (expdp) And Import (impdp) (Doc ID 453895.1)
  * DataPump Export (EXPDP) Is Hanging While Exporting A Table With LONG Column (Doc ID 813396.1)
  * Export/Import DataPump Parameter ACCESS_METHOD - How to Enforce a Method of Loading and Unloading Data ? (Doc ID 552424.1)

=== Verbesserung kann erreicht werden mit ===

Statistiken der DB zuvor optimeren:

<code sql>
exec DBMS_STATS.gather_fixed_objects_stats;
exec DBMS_STATS.GATHER_DICTIONARY_STATS (estimate_percent  => 100, degree  => 8,options  => 'GATHER')
</code>

Export mit "EXCLUDE=STATISTICS" (keine Statistiken mit exportieren) testen



=== Datapump Fehler suchen ===

  * Export/Import DataPump Parameter TRACE - How to Diagnose Oracle Data Pump (Doc ID 286496.1)


=== Zeichensatz Problem mit WE8ISO8859P1 nach AL32UTF8 ===

Leider werden bei einem DataPump Import die nls_length_semantics='CHAR' Einstellungen ignoriert, es wird die Zieltabelle 1zu1 zum Quellsystem angelegt.

Am einfachsten VOR dem Export der Daten im Quellsystem die Varchar2 Spalten auf CHAR anpassen, 
Siehe dazu auch die Metalink Note: "SCRIPT: Changing columns to CHAR length semantics ( NLS_LENGTH_SEMANTICS ) (Doc ID 313175.1)".

Oder erst die Meta Daten importieren "content=metadata_only", dann alle Tabellen anpassen und dann die Daten mit "content=data_only" nachladen.

=== Trigger werden für das falsche Schema angelegt ===

Fehler:
<code sql>
ORA-39083: Object type TRIGGER failed to create with error:
ORA-00942: table or view does not exist 
</code>

Siehe =>
  * IMPDP Reports ORA-942 and ORA-39083 During Importing Schema Objects (Doc ID 750783.1)
  * https://odenysenko.wordpress.com/2016/08/12/impdb-with-schema_remap-may-createimport-trigger-on-table-in-wrong-schema/

=== ORA-01555: snapshot too old ===

Undo einstellungen kontrollieren =>https://github.com/gpipperr/OraPowerShell/blob/master/Ora_SQLPlus_SQLcL_sql_scripts/undo_stat.sql und https://github.com/gpipperr/OraPowerShell/blob/master/Ora_SQLPlus_SQLcL_sql_scripts/undo.sql

Optmieren (ersmal nur im Speicher und auf beiden Instancen wenn RAC!) :
<code sql>
alter system set undo_retention=4800 scope=memory sid='*';

# Für RAC, tablespace auch optimieren, falls auf NOGUARANTEE!
# Tablespace beobachten ! damit kann der Tablespace recht voll laufen, falls sich viel im System ändert!

# 36000 = 10h
ALTER TABLESPACE UNDOTBS01 RETENTION GUARANTEE;
ALTER system SET undo_retention=36000 scope=memory sid='GPIDB1';

ALTER TABLESPACE UNDOTBS02 RETENTION GUARANTEE;
ALTER system SET undo_retention=36000 scope=memory sid='GPIDB2';

</code>



Parameter im Detail siehe https://docs.oracle.com/en/database/oracle/oracle-database/18/refrn/UNDO_RETENTION.html#GUID-D238E854-A2C5-463E-A146-31F61300124E



===ORA-39370: remap value  is too long ===

In der Kommandozeile kann das nicht so einfach übergeben werden:

<code bash>
impdp "'/ as sysdba'" directory=DATA_PUMP_DIR dumpfile=expdp_10-11-2018_23_31_INTERSHOP_LIVE_ISORCL7%u.dmp    REMAP_TABLESPACE=IS_EDIT_INDX:IS_LIVE_INDX:IS_EDIT_INDX_CTX:IS_LIVE_INDX_CTX:IS_EDIT_USERS:IS_LIVE_USERS     sqlfile=INTERSHOP_LIVE_sql_script.sql
</code>

Lösung: Parameter Datei anlegen:

<code bash>
directory=DATA_PUMP_DIR
dumpfile=expdp_10-11-2018_23_31_INTERSHOP_LIVE_ISORCL7%u.dmp
REMAP_TABLESPACE=IS_EDIT_INDX:IS_LIVE_INDX
REMAP_TABLESPACE=IS_EDIT_INDX_CTX:IS_LIVE_INDX_CTX
REMAP_TABLESPACE=IS_EDIT_USERS:IS_LIVE_USERS
sqlfile=INTERSHOP_LIVE_sql_script.sql

</code>

Aber! Die Tablespace Clause (ctxsys.driimp.set_value('P_TABLE_CLAUSE','TABLESPACE IS_EDIT_INDX_CTX'); ) von Oracle Text Indexen wird nicht beachtet!

Teste gerade in einer 12c R1, der Bug ist dort noch nicht gefixt => Bug 6969504 : IMPDP REMAP_TABLESPACE PARAMETER NOT APPLIED FOR SPATIAL INDEXES


D.h. hier muss manuell nachgebessert werden.

=== Import über Datenbank Link mit Database Global Name mit einen "-" Zeichen===

Import über einen Datenbank Link schlägt fehl:

<fc #800000>**Fehler:**</fc>
<code sql>
Release 19.0.0.0.0 - Production on Thu Feb 4 12:02:18 2021
Version 19.9.0.0.0

Copyright (c) 1982, 2020, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
ORA-39004: invalid state
ORA-39091: unable to determine logical standby and streams status
ORA-06550: line 1, column 54:
PLS-00103: Encountered the symbol "-" when expecting one of the following:
</code>

**<fc #008000>Lösung:</fc>** Datenbank Link ohne - anlegen wie z.B. "gpi.world" !


=== Debuggen ===

Siehe diesen Eintrag:https://juliandontcheff.wordpress.com/2011/12/20/on-4-undocumented-datapump-parameters/

Für alles:
<code bash>
TRACE=1FF0300
</code>

----

===== Quellen =====

Web:
  * http://www.pipperr.de/knowhow/datapump/datapump.html
  * http://www.appsdba.info/docs/DBA/DATAPUMP/Data_Pump_examples.pdf
  * http://www.oracle-base.com/articles/10g/oracle-data-pump-10g.php
  * http://home.earthlink.net/~prassinos/sitebuildercontent/sitebuilderfiles/s281230_prassinos.pdf
  * https://www.doag.org/formes/pubfiles/6464524/2014-DB-Marco_Patzwahl-DataPump_Tipps_Tricks_Reloaded-Praesentation.pdf


Oracle:
  * http://docs.oracle.com/cd/E11882_01/server.112/e22490/dp_overview.htm
  * http://www.oracle.com/technetwork/issue-archive/2009/09-jul/datapump11g2009-quickstart-128718.pdf

Oracle Support:

  * Master Note for Data Pump:             MOS Note:1264715.1
  * For Compatibility and version changes: MOS Note:553337.1



**12c**

  * http://www.oracle.com//technetwork/database/upgrade/overview/what-new-datapump-12c-2197042.pdf