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上没有查到相关的资料。
环境：
操作系统：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上没有查到相关的资料。
