oracle expdp 06512,ORACLE的EXPDP与ORA-39125、ORA-01555、ORA-06512

近期，联通的增值网管系统，在执行EXPDP导出时，频频报ORA-39125、ORA-01555、ORA-06512，导致数据库的EXPDP备份被强制终止。

ORA-39125、ORA-01555、ORA-06512的具体信息如下：

Export: Release 10.2.0.4.0 - 64bit Production on 星期六, 17 1月, 2015 22:30:00

Copyright (c) 2003, 2007, Oracle.  All rights reserved.

;;;

连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

启动 "SYSTEM"."SYS_EXPORT_SCHEMA_47":  system/******** schemas=****** directory=backup_expdp dumpfile=expnms_201501171.dmp,exp_201501172.dmp,exp_201501173.dmp,exp_201501174.dmp filesize=40g exclude=statistics parallel=4 logfile=exp_20150117.log

正在使用 BLOCKS 方法进行估计...

处理对象类型 SCHEMA_EXPORT/TABLE/TABLE_DATA

ORA-39125: 在 KUPW$WORKER.GET_TABLE_DATA_OBJECTS 中 Worker 发生意外的致命错误 (在调用 DBMS_METADATA.FETCH_XML_CLOB [TABLE_DATA:"*******"."UC_COMPLETENESS_KPI_CHECK":"P_20130101000000"] 时)

ORA-01555: 快照过旧: 回退段号 30 (名称为 "_SYSSMU30$") 过小

ORA-06512: 在 "SYS.DBMS_SYS_ERROR", line 105

ORA-06512: 在 "SYS.KUPW$WORKER", line 6313

----- PL/SQL Call Stack -----

object      line  object

handle    number  name

41ac01c40     15032  package body SYS.KUPW$WORKER

41ac01c40      6372  package body SYS.KUPW$WORKER

41ac01c40      9206  package body SYS.KUPW$WORKER

41ac01c40      1936  package body SYS.KUPW$WORKER

41ac01c40      6944  package body SYS.KUPW$WORKER

41ac01c40      1314  package body SYS.KUPW$WORKER

44180d828         2  anonymous block

作业 "SYSTEM"."SYS_EXPORT_SCHEMA_47" 因致命错误于 00:16:44 停止

与大家一样，看到ORA-01555，都想到是undo_retention太小了，看了下undo_retention大小如下：

SQL> show parameter undo

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

undo_management                      string      AUTO

undo_retention                       integer     900

undo_tablespace                      string      UNDOTBS1

于是，尝试调整undo_retention参数，使undo段中的数据保留的时间长一点，调整undo_retention为3600：

SQL> show parameter undo

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

undo_management                      string      AUTO

undo_retention                       integer     3600

undo_tablespace                      string      UNDOTBS1

但是，经过观察发现，之前的EXPDP备份失败依然发生，并且失败的频率相比之前并没有任何变化。

通过观察数据库告警日志，发现该库EXPDP备份有时失败如上边提到的失败信息，有时候EXPDP会成功，如下：

. . 导出了 "*******"."STATUSNONPROPAGATE"             11.42 KB      81 行

已成功加载/卸载了主表 "SYSTEM"."SYS_EXPORT_SCHEMA_55"

******************************************************************************

SYSTEM.SYS_EXPORT_SCHEMA_55 的转储文件集为:

/opt/ZBNMSDB_BK/backup/exp_201501311.dmp

/opt/ZBNMSDB_BK/backup/exp_201501312.dmp

/opt/ZBNMSDB_BK/backup/exp_201501313.dmp

/opt/ZBNMSDB_BK/backup/exp_201501314.dmp

作业 "SYSTEM"."SYS_EXPORT_SCHEMA_55" 已于 02:21:41 成功完成

因此，该数据库的EXPDP备份失败是没有规律的，并且单独调整undo_retention是没有作用的；另外，他们备份也排除了统计信息导出，与统计信息也是没有关系的。

后来，仔细观察分析数据库报错信息，ORA-01555报错涉及的SQL语句如下：

SELECT /*+rule*/ SYS_XMLGEN(VALUE(KU$),

XMLFORMAT.createFormat2('TABLE_DATA_T', '7')), 0 ,

KU$.BASE_OBJ.NAME ,

KU$.BASE_OBJ.OWNER_NAME , 'TABLE' ,

to_char(KU$.BYTES_ALLOC) ,

to_char(KU$.ET_PARALLEL) , KU$.FGAC ,

KU$.NONSCOPED_REF , KU$.XMLSCHEMACOLS ,

KU$.NAME , KU$.NAME , 'TABLE_DATA' , KU$.PART_NAME

, KU$.PARTTYPE ,

KU$.PROPERTY , KU$.REFPAR_LEVEL ,

KU$.SCHEMA_OBJ.OWNER_NAME , KU$.TS_NAME ,

KU$.TRIGFLAG , decode(KU$.SCHEMA_OBJ.TYPE_NUM, 2,

decode(bitand(KU$.PROPERTY,

8192), 8192, 'NESTED TABLE', 'TABLE'), 19,

'PARTITION', 20, 'PARTITION',

'SUBPARTITION') , to_char(KU$.UNLOAD_METHOD) ,

KU$.XMLTYPE_FMTS FROM

SYS.KU$_TABLE_DATA_VIEW KU$ WHERE NOT

BITAND(KU$.BASE_OBJ.FLAGS, 128)!=0 AND

NOT (BITAND (KU$.BASE_OBJ.FLAGS, 16)=16) AND NOT

XML_OUTOFLINE='Y' AND

KU$.BASE_OBJ.OBJ_NUM IN (SELECT * FROM

TABLE(DBMS_METADATA.FETCH_OBJNUMS(100001)))

该SQL语句是获取方案分区表的分区信息的，由于查询表分区信息异常，消耗时间超过undo_retention限制而报ORA-01555。通过ORACLE官方metalink查询，具体的诱因是ORACLE的一个BUG 7362589。官方给出的建议是打补丁，但是数据库服务器操作系统是solaris、数据库版本是10.2.0.4的，官方没有相关可用的PATCH。另外，metalink未经发布的解决方法是：在expdp备份命令中加入版本兼容号version=10.2.0.1。

导致备份终止的是确定方案下的分区表UC_COMPLETENESS_KPI_CHECK，然后就尝试使用EXPDP备份加入版本兼容号version=10.2.0.1与不加版本兼容号做对比，单独备份导出失败的表，当加版本兼容号时，EXPDP竟然1分钟不到成功导出了；不加版本兼容号时，经过3次尝试，2次因ORA-01555退出而失败，1次备份成功却花费了20多分钟(但是所要备份的分区表有12个分区，一个分区才1M，正常情况下，备份20多分钟也是不正常的)。通过与系统维护人员协商，暂时尝试添加expdp备份版本兼容号来绕过oracle bug 7362589。

EXPDP备份修改前的命令

expdp system/Dnm%9001 schemas=****** directory=backup_expdp dumpfile=exp_20`date +%y%m%d`1.dmp,exp_20`date+%y%m%d`2.dmp,exp_20`date

+%y%m%d`3.dmp,exp_20`date +%y%m%d`4.dmp filesize=40gexclude=statistics

parallel=4  logfile=exp_20`date

+%y%m%d`.log

EXPDP备份修改后的命令

expdp system/Dnm%9001 schemas=****** directory=backup_expdp dumpfile=exp_20`date +%y%m%d`1.dmp,exp_20`date+%y%m%d`2.dmp,expnms_20`date

+%y%m%d`3.dmp,exp_20`date +%y%m%d`4.dmp filesize=40g  VERSION=10.2.0.2exclude=statistics

parallel=4  logfile=exp_20`date

+%y%m%d`.log

目前，该数据库备份恢复正常了。