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来生成跟踪文件，逐步排查错误。
从10046 Trace RAW File看Cursor
如何通过Trace诊断ORA-00060 Deadlock Type?
ORA-01157: cannot identify/lock data file 6 - see DBWR Trace file ORA-01110: 解决方法
解决autoTrace不显示Predicate Information的问题
Oracle 11g新SQL Trace 10046方法
Oracle SQL Trace 和 10046 事件
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 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基本就够用了。
更多详情见请继续阅读下一页的精彩内容：