ORACLE的EXPDP與ORA-31626、ORA-31637、ORA-06512、ORA-31635

    2015年4月24日，上地的增值業務綜合網管系統ORACLE的EXPDP又出錯了，系統負責人反映從4月20開始到現在該系統的expdp沒有備份檔案，相關的處理過程如下。
    環境：
    作業系統：sun solaris
    資料庫版本：10.2.0.4
    故障描述：執行備份時報錯如下
ORA-31626: 作業不存在
ORA-31637: 無法建立作業 SYS_EXPORT_TABLE_01 (使用者 SYSTEM)
ORA-06512: 在 "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: 在 "SYS.KUPV$FT_INT", line 600
ORA-31635: 無法建立作業資源同步

     處理過程：
    檢視資料庫資料泵備份作業狀態
    select * from dba_datapump_jobs;--sql1
   透過sql1查詢到84條記錄，其中只有第一條的狀態是executing狀態，由於業務敏感性，這裡不貼出來了，接下來按照資料泵備份程式僵死處理
   一、考慮透過登入指定的備份作業進行終止，方式如下：
   Expdp scott/tiger ATTACH=scott.export_job
    --可參考的執行命令
   Export> status               --檢視當前JOB的狀態及相關資訊
   Export> stop_job             --暫停JOB（暫停job後會退出expor模式）
   Export> start_job            --開啟暫停的JOB（並未開始重新執行）
   Export> continue_client      --透過此命令重新啟動 "LTTFM"."MY_JOB":
   Export> kill_job             --取消當前的JOB並釋放相關客戶會話（將job刪除同時刪除dmp檔案）
   Export> exit_client          --透過此命令退出export模式（透過4）可再進入export模式下）
  嘗試後失敗，資料庫expdp一致hang死在：
Export: Release 10.2.0.4.0 - 64bit Production on 星期五, 24 4月, 2015 9:18:43
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
    二、考慮清理資料庫中expdp備份作業表，並殺死作業系統中expdp的備份程式
    使用如下SQL2指令碼生成要刪除的備份作業表
SELECT 'drop table '|| o.owner||'.'||object_name ||'  purge ;'
FROM dba_objects o, dba_datapump_jobs j 
WHERE o.owner=j.owner_name AND o.object_name=j.job_name 
AND j.job_name NOT LIKE 'BIN$%'; --2
   處理完後，從作業系統查詢expdp備份的主程式，可以發現，有一個dm00程式從4月19號一直到現在還在後臺執行，跟系統負責人反映的時間一致。
-bash-3.00$ ps -ef|grep oracle|grep dm
  oracle  3310     1   0   4月 19 ?           8:30 ora_dm00_nms
  oracle  2463 13979   0 09:14:54 pts/13      0:00 grep dm
    使用kill -9 spid命令處理dm00並驗證dm00被殺死：
-bash-3.00$ kill -9 3310
-bash-3.00$ ps -ef|grep oracle|grep dm
  oracle 18710 13979   0 09:18:15 pts/13      0:00 grep dm
    測試重新發起expdp備份作業能否成功執行，因為是生產庫，資料庫很大，又因為排查故障時，使用scott方案做過expdp測試（結果是expdp備份hang死）；
現在，使用scott按方案匯出，如果匯出成功說明該資料庫的expdp備份可以正常進行，測試結果如下：
-bash-3.00$ expdp system/*****  directory=backup_expdp schemas=scott dumpfile=expnms_20`date +%y%m%d`1.dmp,expnms_20`date +%y%m%d`2.dmp,expnms_20`date +%y%m%d`3.dmp,exp_nms20`date +%y%m%d`4_scott.dmp filesize=100M VERSION=10.2.0.2 exclude=statistics parallel=4  logfile=exp_20`date +%y%m%d`_scott.log
Export: Release 10.2.0.4.0 - 64bit Production on 星期五, 24 4月, 2015 9:28:54
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_01":  system/******** directory=backup_expdp schemas=scott dumpfile=expnms_201504241.dmp,expnms_201504242.dmp,expnms_201504243.dmp,exp_nms201504244_scott.dmp filesize=100M VERSION=10.2.0.2 exclude=statistics parallel=4 logfile=exp_20150424_scott.log 
正在使用 BLOCKS 方法進行估計...
處理物件型別 SCHEMA_EXPORT/TABLE/TABLE_DATA
使用 BLOCKS 方法的總估計: 192 KB
處理物件型別 SCHEMA_EXPORT/USER
. . 匯出了 "SCOTT"."DEPT"                              5.648 KB       4 行
處理物件型別 SCHEMA_EXPORT/SYSTEM_GRANT
. . 匯出了 "SCOTT"."EMP"                               7.812 KB      14 行
處理物件型別 SCHEMA_EXPORT/ROLE_GRANT
. . 匯出了 "SCOTT"."SALGRADE"                          5.578 KB       5 行
. . 匯出了 "SCOTT"."BONUS"                                 0 KB       0 行
處理物件型別 SCHEMA_EXPORT/DEFAULT_ROLE
處理物件型別 SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
處理物件型別 SCHEMA_EXPORT/TABLE/TABLE
處理物件型別 SCHEMA_EXPORT/TABLE/INDEX/INDEX
處理物件型別 SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
處理物件型別 SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
已成功載入/解除安裝了主表 "SYSTEM"."SYS_EXPORT_SCHEMA_01" 
******************************************************************************
SYSTEM.SYS_EXPORT_SCHEMA_01 的轉儲檔案集為:
  /opt/ZBNMSDB_BK/backup/expnms_201504241.dmp
  /opt/ZBNMSDB_BK/backup/expnms_201504242.dmp
  /opt/ZBNMSDB_BK/backup/expnms_201504243.dmp
作業 "SYSTEM"."SYS_EXPORT_SCHEMA_01" 已於 09:30:44 成功完成
    透過測試，可以確定資料庫的expdp備份可以正常執行了。隔天詢問系統管理員，其反應資料庫的expdp備份已經正常，沒有收到相關的告警了。
   總結：本次的expdp備份失敗故障處理，是由於資料庫的備份程式dm00掛起導致的，結束掉該程式，清理資料庫的expdp備份主作業表即可，資料庫的expdp備份就能恢復；
dm00掛起的具體原因，在metalink上沒有查到相關的資料。