使用隐含Trace参数诊断Oracle Data Pump（expdp）故障
Tags： Oracle
Data Pump数据泵是Oracle从10g开始推出的，用于取代传统exp/imp工具的数据备份还原组件。经过若干版本的演进和修改，Data Pump已经非常成熟，逐渐被越来越多的DBA和运维人员接受。
相对于传统的exp/imp，Data Pump有很多优势，也变得更加复杂。数据泵一个最显著的特点就是Server-Side运行。Exp/Imp是运行在客户端上面的小工具，虽然使用方便，但是需要处理数据源端和目标端各自服务器和客户端四个版本的差异兼容问题。这就是为什么网络上很多朋友都在纠结如何处理Exp/Imp的版本差异。而且，运行在客户端上的Exp/Imp受网络影响很大，一旦操作时间较长网络不稳定，操作过程可能就以失败告终。同时，exp/imp还存在很多性能、稳定性和特性支持上的不足。
Data Pump数据泵是运行在服务端，直接就减少了版本问题出现的可能。即使存在版本问题，使用version参数也可以进行有效的控制。此外单独的作业运行，可以避免出现意外中断的情况。
尽管如此，我们还是经常会遇到Data Pump的故障和问题，很多时候仅仅借助提示信息不能做到完全的诊断。这个时候，我们可以考虑使用Data Pump的隐藏参数Trace来生成跟踪文件，逐步排查错误。
1、 Data Pump**工作原理和环境准备**
Data Pump工作原理有两个特点：作业调度，多进程配合协作。在Oracle中，Data Pump是作为一个特定的Job来进行处理的，可以进行Job作业的启动、终止、暂停，而且更重要的是Dump作业的工作过程是独立于外部用户的。也就是说，用户不需要和Exp/Imp一样“死盯着”界面，也不需要使用nohup &后台作业化，就可以实现自动的后台操作。
在工作中，Data Pump是一个多进程配合的工作。我们从工作日志上就可以看到，每个Data Pump作业在创建的时候，会自动创建一个作业表，其中记录操作过程。Job工作的时候有两类Process进程工作，一个是master control process，负责整体过程协调，Work Process池管理，任务分配。实际进行导入导出的是Work process，如果设置了parallel参数，就会有多个Work Process进行数据工作。
对Data Pump的诊断本质上就是对各种Process行为的跟踪。Oracle提供了一个Trace的隐含参数，来帮助我们实现这个目标。
首先，我们准备一下Data Pump工作环境。开始需要准备Directory对象。
[root@SimpleLinux /]# ls -l | grep dumpdata
drwxr-xr-x 2 root root 4096 Sep 11 09:01 dumpdata
[root@SimpleLinux /]# chown -R oracle:oinstall dumpdata/
[root@SimpleLinux /]# ls -l | grep dumpdata
drwxr-xr-x 2 oracle oinstall 4096 Sep 11 09:01 dumpdata
--创建directory对象
SQL> select * from v$version where rownum<2;
BANNER
-----------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Producti
SQL> create directory dumpdir as '/dumpdata';
Directory created
2**、隐含参数Trace**
Trace参数是Data Pump隐含内部使用的一个参数。使用方法和其他数据泵参数相同，但是使用取值需要有一些注意之处。下面是我们实验的Trace命令。
[oracle@SimpleLinux dumpdata]$ expdp \"/ as sysdba\" directory=dumpdir schemas=scott dumpfile=scott_dump.dmp parallel=2 trace=480300
Export: Release 11.2.0.3.0 - Production on Wed Sep 11 09:45:07 2013
Trace并不像其他跟踪过程相同，使用y/n的参数，开启或者关闭。Data Pump的Trace参数是一个7位十六进制组成的数字串。不同的数字串表示不同的跟踪对象方法。7位十六进制数字分为两个部分，前三个数字表示特定的数据泵组件，后四位使用0300就可以。
根据Oracle MOS中提供信息资料，Trace字符遵守如下设置规则：
ü 不要输入超过7位长度；
ü 不需要使用0X指定十六进制字符；
ü 不能将十六进制字符转化为数字取值；
ü 如果7位字符以0开头，可以省略0；
ü 输入字符大小写不敏感；
各个组件分别使用不同的三位十六进制数字代表。如下片段所示：
-- Summary of Data Pump trace levels:
-- ==================================
Trace DM DW ORA Lines
level trc trc trc in
(hex) file file file trace Purpose
10300 x x x SHDW: To trace the Shadow process (API) (expdp/impdp)
20300 x x x KUPV: To trace Fixed table
40300 x x x 'div' To trace Process services
80300 x KUPM: To trace Master Control Process (MCP) (DM)
100300 x x KUPF: To trace File Manager
200300 x x x KUPC: To trace Queue services
400300 x KUPW: To trace Worker process(es) (DW)
800300 x KUPD: To trace Data Package
1000300 x META. To trace Metadata Package
--- +
1FF0300 x x x 'all' To trace all components (full tracing)
如果需要同时跟踪多个组件，需要将目标组件的hex值进行累加，后面四位的300相同。
目标Dump作业生成的Trace文件，同其他Trace文件没有什么本质差异。默认都是在BACKGROUP_DUMP_DEST目录。但是注意，Data Pump的Trace过程，会生成多个Trace文件，而且定位需要知道dm和dw的Process ID信息。
笔者建议的一种方法是，如果系统业务不是非常繁忙，可以将目录上的Trc和trm文件暂时保存在其他的地方。再进行Trace作业，此时生成的文件就可以明显看出是哪些。
对于跟踪的Trace取值，Oracle建议使用480300就可以应对大部分的情况。480300会跟踪Oracle Dump作业的Master Control Process（MCP）和Work Process。作为初始化跟踪的过程，480300基本就够用了。
3**、Expdp Trace**过程
我们先从数据导出Expdp看Trace，导出一个案例。首先清理一下Trace File目录。
[oracle@SimpleLinux trace]$ rm *.trc
[oracle@SimpleLinux trace]$ rm *.trm
[oracle@SimpleLinux trace]$ ls -l
total 92
-rw-r----- 1 oracle oinstall 86384 Sep 11 09:37 alert_ora11g.log
调用命令，以两个并行度的方法进行导出动作。
[oracle@SimpleLinux dumpdata]$ expdp \"/ as sysdba\" directory=dumpdir schemas=scott dumpfile=scott_dump.dmp parallel=2 trace=480300
Export: Release 11.2.0.3.0 - Production on Wed Sep 11 09:45:07 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Starting "SYS"."SYS_EXPORT_SCHEMA_01": "/**** AS SYSDBA" directory=dumpdir schemas=scott dumpfile=scott_dump.dmp parallel=2 trace=480300
Estimate in progress using BLOCKS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 32.18 MB
Processing object type SCHEMA_EXPORT/USER
. . exported "SCOTT"."T_MASTER":"P1" 42.43 KB 982 rows
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
（篇幅原因，有省略……）
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
. . exported "SCOTT"."T_MASTER":"P2" 88.69 KB 1859 rows
. . exported "SCOTT"."T_SLAVE":"P1" 412.2 KB 11268 rows
. . exported "SCOTT"."T_SLAVE":"P2" 975.7 KB 21120 rows
. . exported "SCOTT"."DEPT" 5.929 KB 4 rows
. . exported "SCOTT"."EMP" 8.562 KB 14 rows
. . exported "SCOTT"."SALGRADE" 5.859 KB 5 rows
. . exported "SCOTT"."BONUS" 0 KB 0 rows
Master table "SYS"."SYS_EXPORT_SCHEMA_01" successfully loaded/unloaded
Dump file set for SYS.SYS_EXPORT_SCHEMA_01 is:
/dumpdata/scott_dump.dmp
Job "SYS"."SYS_EXPORT_SCHEMA_01" successfully completed at 09:45:36
我们从日志上能看出Parallel的一点不一样，额外的T_MASTER.P1被提前导出了。
新生成的Trace文件目录。
[oracle@SimpleLinux trace]$ ls -l
total 260
-rw-r----- 1 oracle oinstall 87421 Sep 11 09:45 alert_ora11g.log
-rw-r----- 1 oracle oinstall 40784 Sep 11 09:45 ora11g_dm00_3894.trc
-rw-r----- 1 oracle oinstall 1948 Sep 11 09:45 ora11g_dm00_3894.trm
-rw-r----- 1 oracle oinstall 73971 Sep 11 09:45 ora11g_dw00_3896.trc
-rw-r----- 1 oracle oinstall 1986 Sep 11 09:45 ora11g_dw00_3896.trm
-rw-r----- 1 oracle oinstall 27366 Sep 11 09:45 ora11g_dw01_3898.trc
-rw-r----- 1 oracle oinstall 982 Sep 11 09:45 ora11g_dw01_3898.trm
-rw-r----- 1 oracle oinstall 3016 Sep 11 09:45 ora11g_ora_3890.trc
-rw-r----- 1 oracle oinstall 209 Sep 11 09:45 ora11g_ora_3890.trm
Dm和dw标注的就是MCP和Work Process生成的Trace文件。同时Parallel设置使得dw有00和01两个。
在导出过程中，我们可以看到两个worker的会话信息。
SQL> select * from dba_datapump_sessions;
OWNER_NAME JOB_NAME INST_ID SADDR SESSION_TYPE
SYS SYS_EXPORT_SCHEMA_01 1 35EB0580 DBMS_DATAPUMP
SYS SYS_EXPORT_SCHEMA_01 1 35E95280 MASTER
SYS SYS_EXPORT_SCHEMA_01 1 35E8A480 WORKER
SYS SYS_EXPORT_SCHEMA_01 1 35E84D80 WORKER
此时我们可以从Trace文件中，看到一些Data Pump工作的细节信息。例如：在MCP的Trace文件中，我们看到一系列调用动作过程，如下片段：
--初始化导出动作，整理文件系统；
KUPM:09:45:08.720: ****IN DISPATCH at 35108, request type=1001
KUPM:09:45:08.721: Current user is: SYS
KUPM:09:45:08.721: hand := DBMS_DATAPUMP.OPEN ('EXPORT', 'SCHEMA', '', 'SYS_EXPORT_SCHEMA_01', '', '2');
KUPM:09:45:08.791: Resumable enabled
KUPM:09:45:08.799: Entered state: DEFINING
KUPM:09:45:08.799: initing file system
*** 2013-09-11 09:45:08.893
KUPM:09:45:08.893: ****OUT DISPATCH, request type=1001, response type =2041
--日志写入
KUPM:09:45:12.135: ****IN DISPATCH at 35112, request type=3031
KUPM:09:45:12.135: Current user is: SYS
KUPM:09:45:12.136: Log message received from worker DG,KUPC$C_1_20130911094507,KUPC$A_1_094510040559000,MCP,3,Y
KUPM:09:45:12.136: Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
kwqberlst rqan->lascn_kwqiia > 0 block
kwqberlst rqan->lascn_kwqiia 4
kwqberlst ascn 986758 lascn 0
KUPM:09:45:12.137: ****OUT DISPATCH, request type=3031, response type =2041
在Worker Process中，如下片段看出在导出数据。
KUPW:09:45:12.153: 1:
KUPW:09:45:12.153: 1:
KUPW:09:45:12.153: 1: TABLE
KUPW:09:45:12.153: 1: SCOTT
KUPW:09:45:12.153: 1: DEPT
KUPW:09:45:12.154: 1: In procedure LOCATE_DATA_FILTERS
KUPW:09:45:12.154: 1: In function NEXT_PO_NUMBER
KUPW:09:45:12.161: 1: In procedure DETERMINE_METHOD_PARALLEL
KUPW:09:45:12.161: 1: flags mask: 0
KUPW:09:45:12.161: 1: dapi_possible_meth: 1
KUPW:09:45:12.161: 1: data_size: 65536
KUPW:09:45:12.161: 1: et_parallel: TRUE
KUPW:09:45:12.161: 1: object: TABLE_DATA:"SCOTT"."DEPT"
KUPW:09:45:12.164: 1: l_dapi_bit_mask: 7
KUPW:09:45:12.164: 1: l_client_bit_mask: 7
KUPW:09:45:12.164: 1: TABLE_DATA:"SCOTT"."DEPT" either, parallel: 1
KUPW:09:45:12.164: 1: In function GATHER_PARSE_ITEMS
KUPW:09:45:12.165: 1: In function CHECK_FOR_REMAP_NETWORK
KUPW:09:45:12.165: 1: Nothing to remap
KUPW:09:45:12.165: 1: In procedure BUILD_OBJECT_STRINGS
KUPW:09:45:12.165: 1: In DETERMINE_BASE_OBJECT_INFO
KUPW:09:45:12.165: 1: TABLE_DATA
KUPW:09:45:12.165: 1: SCOTT
KUPW:09:45:12.165: 1: EMP
4**、Impdp**导入过程
在Trace过程中，我们也可以如10046跟踪过程一样，添加SQL跟踪。Data Pump本质上工作还是一系列的SQL语句，很多时候的性能问题根源都是从SQL着手的。
切换到SQL跟踪模式也比较简单，一般是在Trace数值后面添加1。我们使用导入过程进行实验。
--处理之前
[root@SimpleLinux trace]# ls -l
total 4
-rw-r----- 1 oracle oinstall 552 Sep 11 10:49 alert_ora11g.log
[oracle@SimpleLinux dumpdata]$ impdp \"/ as sysdba\" directory=dumpdir dumpfile=scott_dump.dmp remap_schema=scott:test trace=480301 parallel=2
Import: Release 11.2.0.3.0 - Production on Wed Sep 11 10:50:14 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table "SYS"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYS"."SYS_IMPORT_FULL_01": "/**** AS SYSDBA" directory=dumpdir dumpfile=scott_dump.dmp remap_schema=scott:test trace=480301 parallel=2
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
. . imported "TEST"."T_MASTER":"P1" 42.43 KB 982 rows
. . imported "TEST"."T_MASTER":"P2" 88.69 KB 1859 rows
. . imported "TEST"."T_SLAVE":"P1" 412.2 KB 11268 rows
. . imported "TEST"."T_SLAVE":"P2" 975.7 KB 21120 rows
. . imported "TEST"."DEPT" 5.929 KB 4 rows
. . imported "TEST"."EMP" 8.562 KB 14 rows
. . imported "TEST"."SALGRADE" 5.859 KB 5 rows
. . imported "TEST"."BONUS" 0 KB 0 rows
Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
Job "SYS"."SYS_IMPORT_FULL_01" successfully completed at 10:50:24
查看跟踪目录。
[root@SimpleLinux trace]# ls -l
total 7588
-rw-r----- 1 oracle oinstall 739 Sep 11 10:50 alert_ora11g.log
-rw-r----- 1 oracle oinstall 1916394 Sep 11 10:50 ora11g_dm00_4422.trc
-rw-r----- 1 oracle oinstall 9446 Sep 11 10:50 ora11g_dm00_4422.trm
-rw-r----- 1 oracle oinstall 2706475 Sep 11 10:50 ora11g_dw00_4424.trc
-rw-r----- 1 oracle oinstall 15560 Sep 11 10:50 ora11g_dw00_4424.trm
-rw-r----- 1 oracle oinstall 2977812 Sep 11 10:50 ora11g_ora_4420.trc
-rw-r----- 1 oracle oinstall 12266 Sep 11 10:50 ora11g_ora_4420.trm
-rw-r----- 1 oracle oinstall 29795 Sep 11 10:50 ora11g_p000_4426.trc
-rw-r----- 1 oracle oinstall 526 Sep 11 10:50 ora11g_p000_4426.trm
-rw-r----- 1 oracle oinstall 30109 Sep 11 10:50 ora11g_p001_4428.trc
-rw-r----- 1 oracle oinstall 524 Sep 11 10:50 ora11g_p001_4428.trm
-rw-r----- 1 oracle oinstall 8430 Sep 11 10:50 ora11g_p002_4430.trc
-rw-r----- 1 oracle oinstall 184 Sep 11 10:50 ora11g_p002_4430.trm
-rw-r----- 1 oracle oinstall 8432 Sep 11 10:50 ora11g_p003_4432.trc
-rw-r----- 1 oracle oinstall 204 Sep 11 10:50 ora11g_p003_4432.trm
目录生成的Trace文件，都是10046格式的Raw文件。截取片段如下：
=====================
PARSING IN CURSOR #13035136 len=51 dep=2 uid=0 ct=3 lid=0 tim=1378867817703043 hv=1523794037 ad='360b079c' sqlid='b1wc53ddd6h3p'
select audit$,options from procedure$ where obj#=:1
END OF STMT
PARSE #13035136:c=0,e=96,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,plh=1637390370,tim=1378867817703039
EXEC #13035136:c=0,e=79,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,plh=1637390370,tim=1378867817703178
FETCH #13035136:c=0,e=53,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=4,plh=1637390370,tim=1378867817703248
STAT #13035136 id=1 cnt=1 pid=0 pos=1 bj=221 p='TABLE ACCESS BY INDEX ROWID PROCEDURE$ (cr=3 pr=0 pw=0 time=53 us cost=2 size=47 card=1)'
STAT #13035136 id=2 cnt=1 pid=1 pos=1 bj=231 p='INDEX UNIQUE SCAN I_PROCEDURE1 (cr=2 pr=0 pw=0 time=24 us cost=1 size=0 card=1)'
CLOSE #13035136:c=0,e=7,dep=2,type=1,tim=1378867817703387
=====================
5**、结论**
Oracle Data Pump已经非常成熟，也越来越多被人们接受。Trace参数尤其存在的历史背景，相信使用的机会越来越少。不过，作为研究内部机制的用途，还是比较有用的。
Export/Import DataPump Parameter TRACE - How to Diagnose Oracle Data Pump (文档 ID 286496.1)
In this Document
Purpose
Scope
Details
\1. Introduction.
\2. How to create a Data Pump trace file ?? Parameter: TRACE
\3. How to start tracing the Data Pump job ?
\4. How are Data Pump trace files named, and where to find them ?
\5. How to get a detailed status report of a Data Pump job ?? Parameter: STATUS
\6. How to get timing details on processed objects ? Parameter: METRICS
\7. How to get SQL trace files of the Data Pump processes ?
\8. How to get header details of Export Data Pump dumpfiles ?
\9. How to get Data Definition Language (DDL) statements ? Parameter: SQLFILE
\10. How to get the DDL both as SQL statements and as XML data ?
Additional Resources
References
APPLIES TO:
Oracle Database - Enterprise Edition - Version 10.1.0.2 to 11.2.0.3 [Release 10.1 to 11.2]
Information in this document applies to any platform.
PURPOSE
This document describes how to use the TRACE parameter with the Export Data Pump (expdp) and Import Data Pump (impdp) database utilities when diagnosing incorrect behavior and/or troubleshooting Data Pump errors.
SCOPE
The article is intended for users of the database utilities Export Data Pump (expdp) and Import Data Pump (impdp), and who need to troubleshoot the execution of the jobs that are generated by these utilities. These database utilities were introduced with Oracle10g. The article gives detailed information how to use the undocumented parameter TRACE.
DETAILS
1. Introduction.
In Oracle10g, we introduced the new database utilities Export Data Pump and Import Data Pump.
Data Pump jobs use a master table, a master process, and worker processes to perform the work and keep track of the progress. For every Data Pump Export job and Data Pump Import job, a master process is created. The master process controls the entire job, including communicating with the clients, creating and controlling a pool of worker processes, and performing logging operations.
Example output when a full database Export Data Pump is running with parallelism 2:
% expdp system/manager DIRECTORY=my_dir DUMPFILE=expdp_f%U.dmp \
LOGFILE=expdp_f.log FULL=y PARALLEL=2
% ps -ef | grep expdp
oracle 8874 8704 1 07:00 pts/2 00:00:03 expdp DIRECTORY=my_dir ...
% ps -ef | grep ORCL
oracle 8875 8874 4 07:00 ? 00:00:11 oracleORCL (DESCRIPTION=(LOCAL=YES) ...
oracle 8879 1 3 07:00 ? 00:00:08 ora_dm00_ORCL
oracle 8881 1 94 07:00 ? 00:04:17 ora_dw01_ORCL
oracle 8893 1 3 07:00 ? 00:00:09 ora_dw02_ORCL
...
-- Obtain Data Pump process info:
set lines 150 pages 100 numwidth 7
col program for a38
col username for a10
col spid for a7
select to_char(sysdate,'YYYY-MM-DD HH24:MI:SS') "DATE", s.program, s.sid,
s.status, s.username, d.job_name, p.spid, s.serial#, p.pid
from v$session s, v$process p, dba_datapump_sessions d
where p.addr=s.paddr and s.saddr=d.saddr;
DATE PROGRAM SID STATUS
2007-10-19 07:01:03 ude@celclnx7.us.oracle.com (TNS V1-V3) 140 ACTIVE
2007-10-19 07:01:03 oracle@celclnx7.us.oracle.com (DM00) 152 ACTIVE
2007-10-19 07:01:03 oracle@celclnx7.us.oracle.com (DW01) 144 ACTIVE
2007-10-19 07:01:03 oracle@celclnx7.us.oracle.com (DW02) 159 ACTIVE
USERNAME JOB_NAME SPID SERIAL# PID
SYSTEM SYS_EXPORT_FULL_01 8875 8 18
SYSTEM SYS_EXPORT_FULL_01 8879 21 21
SYSTEM SYS_EXPORT_FULL_01 8881 7 22
SYSTEM SYS_EXPORT_FULL_01 8893 26 23
The Data Pump processes will disappear when the Data Pump job completes or is (temporary) stopped.
Improved tracing capabilities have been implemented with these utilities. The tracing can be controlled with the TRACE parameter.
Data Pump is server based and not client based. This means that most Data Pump specific defects will be fixed on the server side (changes in packages in source and target database) and not on the client side (Export or Import Data Pump client). If a Data Pump defect that occurs during an import job is fixed in a later patchset (e.g. 10.2.0.4.0) and the target database is still on the base release (10.2.0.1.0) then the defect will still occur when importing with a 10.2.0.4.0 Import Data Pump client into this 10.2.0.1.0 target database. The same applies to export jobs. It is therefore recommended that both the source database and the target database have the latest patchset installed. For details, see also:
Note:553337.1 "Export/Import DataPump Parameter VERSION - Compatibility of Data Pump Between Different Oracle Versions"
2. How to create a Data Pump trace file ? Parameter: TRACE
Tracing can be enabled by specifying an 7 digit hexadecimal mask in the TRACE parameter of Export DataPump (expdp) or Import DataPump (impdp). The first three digits enable tracing for a specific Data Pump component, while the last four digits are usually: 0300.
Any leading zero's can be omitted, and the value specified for the TRACE parameter is not case sensitive.
Example:
TRACE = 04A0300
-- or:
TRACE=4a0300
Some rules to remember when specifying a value for the TRACE parameter:
- do not specify more than 7 hexadecimal digits;
- do not specify the typical leading 0x hexadecimal specification characters;
- do not convert the hexadecimal value to a decimal value;
- omit any leading zero's (not required though);
- values are not case sensitive.
When using the TRACE parameter, an error may occur if the Data Pump job is run with a non-privileged user, e.g.:
% expdp scott/tiger DIRECTORY=my_dir DUMPFILE=expdp_s.dmp \
LOGFILE=expdp_s.log TABLES=emp TRACE=480300
Export: Release 10.2.0.3.0 - Production on Friday, 19 October, 2007 13:46:33
Copyright (c) 2003, 2005, Oracle. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Data Mining Scoring Engine options
ORA-31631: privileges are required
To resolve this problem: ensure that the user that connects to the database with the Export Data Pump or Import Data Pump utility, is a privileged user (i.e. a user who has the DBA role or the EXP_FULL_DATABASE resp. IMP_FULL_DATABASE role), e.g.:
-- run this Data Pump job with TRACE as a privileged user:
% expdp system/manager DIRECTORY=my_dir DUMPFILE=expdp_s.dmp \
LOGFILE=expdp_s.log TABLES=scott.emp TRACE=480300
-- or:
-- make user SCOTT a privileged user:
CONNECT / AS SYSDBA
GRANT exp_full_database TO scott;
% expdp scott/tiger DIRECTORY=my_dir DUMPFILE=expdp_s.dmp \
LOGFILE=expdp_s.log TABLES=emp TRACE=480300
For details, see also:
Note:351598.1 "Export/Import DataPump: The Minimum Requirements to Use Export DataPump and Import DataPump (System Privileges)"
Also ensure that the init.ora/spfile initialization parameter MAX_DUMP_FILE_SIZE is large enough to capture all the trace information (or set it to unlimited which is the default value), e.g.:
-- Ensure enough trace data can be written to the trace files:
CONNECT / as sysdba
SHOW PARAMETER max_dump
NAME TYPE VALUE
max_dump_file_size string 10M
ALTER SYSTEM SET max_dump_file_size = unlimited SCOPE = both;
SHOW PARAMETER max_dump
NAME TYPE VALUE
max_dump_file_size string UNLIMITED
The majority of errors that occur during a Data Pump job, can be diagnosed by creating a trace file for the Master Control Process (MCP) and the Worker Process(es) only, e.g.:
-- To run a Data Pump job with standard tracing:
-- This results in two trace files in BACKGROUND_DUMP_DEST:
-- Master Process trace file: dm.trc
-- Worker Process trace file: dw.trc
% expdp system/manager DIRECTORY=my_dir DUMPFILE=expdp_s.dmp \
LOGFILE=expdp_s.log SCHEMAS=scott TRACE=480300
Each Data Pump component can be specified explicitly in order to obtain tracing details of that component:
-- Summary of Data Pump trace levels:
-- ==================================
Trace DM DW ORA Lines
level trc trc trc in
(hex) file file file trace Purpose
10300 x x x SHDW: To trace the Shadow process (API) (expdp/impdp)
20300 x x x KUPV: To trace Fixed table
40300 x x x 'div' To trace Process services
80300 x KUPM: To trace Master Control Process (MCP) (DM)
100300 x x KUPF: To trace File Manager
200300 x x x KUPC: To trace Queue services
400300 x KUPW: To trace Worker process(es) (DW)
800300 x KUPD: To trace Data Package
1000300 x META: To trace Metadata Package
------- 'Bit AND'
1FF0300 x x x 'all' To trace all components (full tracing)
Combinations of tracing Data Pump components are possible, e.g.:
-- Example of combination (last 4 digits are usually 0300):
40300 to trace Process services
80300 to trace Master Control Process (MCP)
400300 to trace Worker process(es)
------- 'Bit AND'
4C0300 to trace Process services and Master Control and Worker processes
In order to trace all Data Pump components, level 1FF0300 can be specified:
-- Run a Data Pump job with full tracing:
-- This results in two trace files in BACKGROUND_DUMP_DEST:
-- Master Process trace file: dm.trc
-- Worker Process trace file: dw.trc
-- And one trace file in USER_DUMP_DEST:
-- Shadow Process trace file: ora.trc
% impdp system/manager DIRECTORY=my_dir DUMPFILE=expdp_s.dmp \
LOGFILE=impdp_s.log FULL=y TRACE=1ff0300
Note: For initial Data Pump tracing, the value 480300 is sufficient. When value 480300 is specified, we will trace the Master Control process (MCP) and the Worker process(es). When creating a Data Pump trace file, we recommend to use the value 480300 unless a different trace level is requested by Oracle Support.
3. How to start tracing the Data Pump job ?
Depending on how the Export or Import Data Pump job was started, there are several ways to activate tracing of the Data Pump processes.
3.1. Use the TRACE parameter upon the start of the job.**
Start tracing by specifying the TRACE** parameter and a trace level when the Export Data Pump or Import Data Pump is started. This is the standard way to activate Data Pump tracing.
Example:
% expdp system/manager DIRECTORY=my_dir DUMPFILE=expdp_s.dmp \
LOGFILE=expdp_s.log TABLES=scott.emp TRACE=480300
**3.2. Use the TRACE parameter when restarting a job.**
If an Export or Import Data Pump job was started without the TRACE parameter, it can be temporary stopped, and restarted with the TRACE parameter.
Example:
% expdp system/manager DIRECTORY=my_dir DUMPFILE=expdp_f.dmp \
LOGFILE=expdp_f.log FULL=Y
Export: Release 10.2.0.3.0 - Production on Thursday, 18 October, 2007 17:11:08
Copyright (c) 2003, 2005, Oracle. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Data Mining Scoring Engine options
FLASHBACK automatically enabled to preserve database integrity.
Starting "SYSTEM"."SYS_EXPORT_FULL_01": system/**** DIRECTORY=my_dir
DUMPFILE=expdp_f.dmp LOGFILE=expdp_f.log FULL=y
Estimate in progress using BLOCKS method...
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA-- press Control-C to go to the Interactive Command mode,
-- and temporarystop the job with the STOP_JOB command:
Export> stop
Are you sure you wish to stop this job ([yes]/no): yes
-- use the system generated job-name SYS_EXPORT_FULL_01 to re-attach to the job
-- and specify the TRACE parameter with a tracing level:
% expdp system/manager ATTACH=sys_export_full_01 TRACE=480300
Export: Release 10.2.0.3.0 - Production on Thursday, 18 October, 2007 17:23:48
Copyright (c) 2003, 2005, Oracle. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Data Mining Scoring Engine options
Job: SYS_EXPORT_FULL_01
Owner: SYSTEM
Operation: EXPORT
Creator Privs: FALSE
GUID: F4E6BF997DFA46378D543F998E82653E
Start Time: Thursday, 18 October, 2007 17:23:49
Mode: FULL
Instance: m10203wa
Max Parallelism: 1
EXPORT Job Parameters:
Parameter Name Parameter Value:
CLIENT_COMMAND system/**** DIRECTORY=my_dir DUMPFILE=expdp_f.dmp
LOGFILE=expdp_f.log FULL=y
State: IDLING
Bytes Processed: 0
Current Parallelism: 1
Job Error Count: 0
Dump File: /usr/DataPump/expdp_f.dmp
bytes written: 4,096
Worker 1 Status:
State: UNDEFINED
-- restart the job and change back from Interactive Command mode to Logging mode
-- with CONTINUE_CLIENT (note that tracing with level 480300 is now active):
Export> cont
Restarting "SYSTEM"."SYS_EXPORT_FULL_01": system/**** DIRECTORY=my_dir
DUMPFILE=expdp_f.dmp LOGFILE=expdp_s.log FULL=y
Processing object type DATABASE_EXPORT/TABLESPACE
Processing object type DATABASE_EXPORT/PROFILE
...
**3.3. Use a database init.ora/spfile event to trace Data Pump.**
Data Pump tracing can also be started with a line with EVENT 39089 in the initialization parameter file. This method should only be used to trace the Data Pump calls in an early state, e.g. if details are needed about the DBMS_DATAPUMP.OPEN API call. Trace level 0x300 will trace all Data Pump client processes.
Example when using init.ora initialization parameter file:
- add the following line to init.ora parameter file:
EVENT="39089 trace name context forever,level 0x300"
- Restart the database.
- Start the Export Data Pump or Import Data Pump job.
Example when using spfile initialization parameter file:
-- when using spfile parameter file:
CONNECT / as sysdba
SHOW PARAMETER event
NAME TYPE VALUE
event string
ALTER SYSTEM SET EVENTS = '39089 trace name context forever, level 0x300'
SCOPE = spfile;
