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=40g  exclude=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.2 exclude=statistics parallel=4  logfile=exp_20`date +%y%m%d`.log

   目前，該資料庫備份恢復正常了。