手动清除dba_datapum_jobs中异常的做业

今天群里面有兄弟在问关于dba_datapump_jobs中的not running的做业的清除的方法及not running状态的表明什么意思。

not running状态的做业有两个意思

1，做业被暂停。

2，dw/dm进程crash，可是master table还存在

其实多数状况下是属于2，关于怎么清除至关做业，能够看下面的MOS文件，已经写得至关的好，而且仍是中文的

欢迎你们加入ORACLE超级群：17115662 免费解决各类ORACLE问题,之后BLOG将迁移到http://www.htz.pw

如何清除 DBA_DATAPUMP_JOBS 视图中的异常数据泵做业? (文档 ID 1626201.1)

 

 

文档内容

 

目标

解决方案

其余资源

 

适用于:

Oracle Database - Enterprise Edition - 版本 10.1.0.2 到 11.2.0.3 [发行版 10.1 到 11.2]

本文档所含信息适用于全部平台

目标

如何清除 DBA_DATAPUMP_JOBS 视图中的异常数据泵做业?

解决方案

用于这个例子中的做业:

- 导出做业 SCOTT.EXPDP_20051121 是一个正在运行的 schema 级别的导出做业

- 导出做业 SCOTT.SYS_EXPORT_TABLE_01 是一个表级别的异常导出做业

- 导出做业 SCOTT.SYS_EXPORT_TABLE_02 是一个表级别的中止导出做业

- 导出做业 SYSTEM.SYS_EXPORT_FULL_01 是一个被暂停的全库导出做业

 

第1步. 用 SQL*PLUS 判断在数据库中有哪些数据泵做业

%sqlplus /nolog

CONNECT / as sysdba

SET lines 200

COL owner_name FORMAT a10;

COL job_name FORMAT a20

COL state FORMAT a12

COL operation LIKE state

COL job_mode LIKE state

 

-- 查找数据泵做业:

 

SELECT owner_name, job_name, operation, job_mode,

state, attached_sessions

FROM dba_datapump_jobs

WHERE job_name NOT LIKE 'BIN$%'

ORDER BY 1,2;

 

OWNER_NAME JOB_NAME            OPERATION JOB_MODE  STATE       ATTACHED

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

SCOTT      EXPDP_20051121      EXPORT    SCHEMA    EXECUTING          1

SCOTT      SYS_EXPORT_TABLE_01 EXPORT    TABLE     NOT RUNNING        0

SCOTT      SYS_EXPORT_TABLE_02 EXPORT    TABLE     NOT RUNNING        0

SYSTEM     SYS_EXPORT_FULL_01  EXPORT    FULL      NOT RUNNING        0

第2步. 确保在 dba_datapump_jobs 中列出的做业不是活动的数据泵做业: 状态应该是'NOT RUNNING'。

 

第3步. 同做业属主确认视图 dba_datapump_jobs 中状态为'NOT RUNNING' 的做业不是被暂停，而失败的做业。(例如，SYSTEM 用户的全库导出做业不是一个失败的做业，而是一个被故意暂停的做业)

第4步. 经过 SQL*Plus 找到相关的 master 表：

-- 查找数据泵的 master 表：

 

SELECT o.status, o.object_id, o.object_type,

       o.owner||'.'||object_name "OWNER.OBJECT"

  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$%' ORDER BY 4,2;

 

STATUS   OBJECT_ID OBJECT_TYPE  OWNER.OBJECT

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

VALID        85283 TABLE        SCOTT.EXPDP_20051121

VALID        85215 TABLE        SCOTT.SYS_EXPORT_TABLE_02

VALID        85162 TABLE        SYSTEM.SYS_EXPORT_FULL_01

 

第5步. 对于过去被终止的和根本不会再启动的做业，删除它的 master 表，例如，

DROP TABLE scott.sys_export_table_02;

 

-- 对于启用了 recycle bin 的系统，须要额外运行：

purge dba_recyclebin;

 

第6步. 从新运行第1步和第4步对 dba_datapump_jobs 和 dba_objects 的查询。若是 dba_datapump_jobs 里仍然有做业列出，而且这些做业根本没有 master 表，咱们就能够以做业属主的身份清除它们。例如，

CONNECT scott/tiger

SET serveroutput on

SET lines 100

DECLARE

   h1 NUMBER;

BEGIN

   h1 := DBMS_DATAPUMP.ATTACH('SYS_EXPORT_TABLE_01','SCOTT');

   DBMS_DATAPUMP.STOP_JOB (h1);

END;

/

注意：调用 STOP_JOB 过程之后，可能会花一点时间去清除做业，咱们能够查询 user_datapump_jobs 检查做业是否已经被清除掉：

SELECT * FROM user_datapump_jobs;

第7步. 确认做业已经被清除

CONNECT / as sysdba

SET lines 200 

COL owner_name FORMAT a10; 

COL job_name FORMAT a20 

COL state FORMAT a12 

COL operation LIKE state 

COL job_mode LIKE state 

 

-- 查找数据泵做业:

 

SELECT owner_name, job_name, operation, job_mode, 

state, attached_sessions 

FROM dba_datapump_jobs 

WHERE job_name NOT LIKE 'BIN$%' 

ORDER BY 1,2; 

 

OWNER_NAME JOB_NAME            OPERATION JOB_MODE  STATE       ATTACHED

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

SCOTT      EXPDP_20051121      EXPORT    SCHEMA    EXECUTING          1

SYSTEM     SYS_EXPORT_FULL_01  EXPORT    FULL      NOT RUNNING        0

 

-- 查找数据泵的 master 表:

 

SELECT o.status, o.object_id, o.object_type,

       o.owner||'.'||object_name "OWNER.OBJECT"

  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$%' ORDER BY 4,2;

 

STATUS   OBJECT_ID OBJECT_TYPE  OWNER.OBJECT

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

VALID        85283 TABLE        SCOTT.EXPDP_20051121

VALID        85162 TABLE        SYSTEM.SYS_EXPORT_FULL_01

 

摘要:

1. 异常数据泵做业不会影响新的数据泵做业. dba_datapump_jobs 是基于 gv$datapump_job, obj$, com$, and user$ 的一个视图。 这个视图显示仍在运行的数据泵做业，或者做业的 master 表仍然保留在数据库中，或者不正常结束的做业(异常做业)。若是一个新的数据泵做业启动， 会建立一条新的记录，与旧的数据泵做业无关。

 

2. 当用系统自动生成的做业名启动一个新的数据泵做业时，咱们会检查 dba_datapump_job 中现有的名称以保持唯一性。固然，启动这个做业的用户下须要有足够的空间来建立一个新的 master 表。

 

3. 数据泵做业与用 DBMS_JOBS 包定义的做业不一样， DBMS_JOBS 建立的做业使用它本身的进程。 数据泵做业使用一个 master 进程和一些 worker 进程。若是一个数据泵做业被暂停，数据泵做业会一直存在在数据库中（status: NOT RUNNING），这时，master 和 worker 进程会被中止，或者再也不存在。客户端以后能够再次挂载到这个做业，而且继续做业的执行(START_JOB)。

 

4. 若是活动的数据泵做业相关联的 master 表被删除，可能会致使不一致.

 

4.a. 若是是一个导出做业, 不太可能引发不一致，由于删除 master 表只会致使数据泵的 mater 和 worker 进程停止。这种状况相似于客户端发起的一个意外停止。

 

4.b. 若是这个做业是一个导入做业，那么状况就有所不一样。删除掉 master 表会致使数据泵的 worker 和 mater 进程中断。这有可能会引发不完整的导入。 例如，没有导入表的全部数据，或表，索引，视图等的导入不完整， 这种状况相似于意外中断导入的客户端。删除 master 表自己不会引发任何数据字典的不一致。若是您在做业完成后还保留 master 表（使用非公开的参数：KEEP_MASTER=Y），之后再删除 master表的操做不会形成任何不一致。

 

其余资源

社区：数据库社区