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上没有查到相关的资料。


上一篇:Oracle字符集与ORA-00972


下一篇:大数据量、高并发数据库的高性能、高可用性解决方案