合 使用隐含Trace参数诊断Oracle Data Pump（expdp）故障

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

后续精彩内容已被站长无情隐藏，请输入验证码解锁本文！

验证码：

获取验证码： 请先关注本站微信公众号，然后回复“验证码”，获取验证码。在微信里搜索“AiDBA”或者“dbaup6”或者微信扫描右侧二维码都可以关注本站微信公众号。