今天在重构数据库时(将表空间中的表、索引转移到其它表空间)时,发现有两个奇怪的对象SYS_EXPORT_FULL_01、SYS_EXPORT_FULL_02搜索了一下,发现这个可能是EXPDP导出异常时遗留下的对象,但是搜到的资料不多,不能确认其具体用途以及该表是否删除。后来同事在metalink搜索到How To Cleanup Orphaned DataPump Jobs In DBA_DATAPUMP_JOBS ? (文档 ID 336014.1)这篇文章。了解到这些表的相关详细信息。

如下所示,SYS_EXPORT_FULL_01、SYS_EXPORT_FULL_02是一个完整的数据库导出作业,状态是NOT RUNNING,意味着作业是暂时的停止,实际上作业失败了也是NOT RUNNING状态。

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;

COL owner.object for a50;

 

-- locate Data Pump jobs: 

SELECT owner_name, job_name, rtrim(operation) "OPERATION", 

    rtrim(job_mode) "JOB_MODE", state, attached_sessions

FROM dba_datapump_jobs

 WHERE job_name NOT LIKE 'BIN$%'

 ORDER BY 1,2; 

-- locate Data Pump master tables: 

 

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;

这表示以前(可能是很久以前)停止的作业,当然这些作业不可能重新启动,完全可以删除这些master表.

DROP TABLE ADMIN.SYS_EXPORT_FULL_01;

DROP TABLE ADMIN.SYS_EXPORT_FULL_02;

How To Cleanup Orphaned DataPump Jobs In DBA_DATAPUMP_JOBS ? (文档 ID 336014.1) 中的详细内容介绍如下所示:

The jobs used in this example:
- Export job SCOTT.EXPDP_20051121 is a schema level export that is running
- Export job SCOTT.SYS_EXPORT_TABLE_01 is an orphaned table level export job
- Export job SCOTT.SYS_EXPORT_TABLE_02 is a table level export job that was stopped
- Export job SYSTEM.SYS_EXPORT_FULL_01 is a full database export job that is temporary stopped

Step 1. Determine in SQL*Plus which Data Pump jobs exist in the database:

%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
COL owner.object for a50
-- locate Data Pump jobs:
SELECT owner_name, job_name, rtrim(operation) "OPERATION",
       rtrim(job_mode) "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

Step 2. Ensure that the listed jobs in dba_datapump_jobs are not export/import Data Pump jobs that are active: status should be 'NOT RUNNING'.
Step 3. Check with the job owner that the job with status 'NOT RUNNING' in dba_datapump_jobs is not an export/import Data Pump job that has been temporary stopped, but is actually a job that failed. (E.g. the full database export job by SYSTEM is not a job that failed, but was deliberately paused with STOP_JOB).

Step 4. Determine in SQL*Plus the related master tables:

-- locate Data Pump master tables:
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

Step 5. For jobs that were stopped in the past and won't be restarted anymore, delete the master table. E.g.:

DROP TABLE scott.sys_export_table_02;
-- For systems with recycle bin additionally run:
purge dba_recyclebin;

NOTE:
In case the table name is mixed case, you can get errors on the drop, e.g.:

SQL> drop table SYSTEM.impdp_schema_STGMDM_10202014_0;
drop table SYSTEM.impdp_schema_STGMDM_10202014_0
                *
ERROR at line 1:
ORA-00942: table or view does not exist

Because the table has a mixed case, try using these statements with double quotes around the table name, for instance:

drop table SYSTEM."impdp_SCHEMA_STGMDM_04102015_1";
drop table SYSTEM."impdp_schema_STGMDM_10202014_0";

Step 6. Re-run the query on dba_datapump_jobs and dba_objects (step 1 and 4). If there are still jobs listed in dba_datapump_jobs, and these jobs do not have a master table anymore, cleanup the job while connected as the job owner. E.g.:

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;
/

Note that after the call to the STOP_JOB procedure, it may take some time for the job to be removed. Query the view user_datapump_jobs to check whether the job has been removed:

CONNECT scott/tiger
SELECT * FROM user_datapump_jobs;

Step 7. Confirm that the job has been removed:

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 
COL owner.object for a50
-- locate Data Pump jobs: 
SELECT owner_name, job_name, rtrim(operation) "OPERATION",
       rtrim(job_mode) "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
-- locate Data Pump master tables:
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

Remarks:
1. Orphaned Data Pump jobs do not have an impact on new Data Pump jobs. The view dba_datapump_jobs is a view, based on gv$datapump_job, obj$, com$, and user$. The view shows the Data Pump jobs that are still running, or jobs for which the master table was kept in the database, or in case of an abnormal end of the Data Pump job (the orphaned job). If a new Data Pump job is started, a new entry will be created, which has no relation to the old Data Pump jobs.

2. When starting the new Data Pump job and using a system generated name, we check the names of existing Data Pump jobs in the dba_datapump_job in order to obtain a unique new system generated jobname. Naturally, there needs to be enough free space for the new master table to be created in the schema that started the new Data Pump job.

3. A Data Pump job is not the same as a job that is defined with DBMS_JOBS. Jobs created with DBMS_JOBS use there own processes. Data Pump jobs use a master process and worker process(es). In case a Data Pump still is temporary stopped (STOP_JOB while in interactive command mode), the Data Pump job still exists in the database (status: NOT RUNNING), while the master and worker process(es) are stopped and do not exist anymore. The client can attach to the job at a later time, and continue the job execution (START_JOB).

4. The possibility of corruption when the master table of an active Data Pump job is deleted, depends on the Data Pump job.
4.a. If the job is an export job, corruption is unlikely as the drop of the master table will only cause the Data Pump master and worker processes to abort. This situation is similar to aborting an export of the original export client.
4.b. If the job is an import job then the situation is different. When dropping the master table, the Data Pump worker and master processes will abort. This will probably lead to an incomplete import: e.g. not all table data was imported, and/or table was imported incomplete, and indexes, views, etc. are missing. This situation is similar to aborting an import of the original import client.

The drop of the master table itself, does not lead to any data dictionary corruption. If you keep the master table after the job completes (using the undocumented parameter: KEEP_MASTER=Y), then a drop of the master table afterwards, will not cause any corruption.

5. Instead of the status 'NOT RUNNING' the status of a failed job could also be 'DEFINING'. When trying to attach to such a job, this would fail with:

$ expdp system/manager attach=system.sys_export_schema_01
Export: Release 11.2.0.4.0 - Production on Tue Jan 27 10:14:27 2015
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORA-31626: job does not exist
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 79
ORA-06512: at "SYS.KUPV$FT", line 405
ORA-31638: cannot attach to job SYS_EXPORT_SCHEMA_01 for user SYSTEM
ORA-31632: master table "SYSTEM.SYS_EXPORT_SCHEMA_01" not found, invalid, or inaccessible
ORA-00942: table or view does not exist

The steps to cleanup these failed/orphaned jobs are the same as mentioned above.

清理DBA_DATAPUMP_JOBS中的孤立数据泵作业的更多相关文章

  1. 如何清除 DBA_DATAPUMP_JOBS 视图中的异常数据泵作业

    解决方案 用于这个例子中的作业: - 导出作业 SCOTT.EXPDP_20051121 是一个正在运行的 schema 级别的导出作业 - 导出作业 SCOTT.SYS_EXPORT_TABLE_0 ...

  2. oracle中使用impdp数据泵导入数据提示“ORA-31684:对象类型已经存在”错误的解决

    转载请注明出处:http://blog.csdn.net/dongdong9223/article/details/47448751 本文出自[我是干勾鱼的博客] oracle中使用impdp数据泵导 ...

  3. Oracle12c中数据泵新特性之功能增强(expdp, impdp)

    Oracle的数据泵功能在10g中被引进.本文对数据泵在12c中的增强做一个概览. 1.   禁用日志选项(DISABLE_ARCHIVE_LOGGING) Impdp的TRANSFORM参数已经扩展 ...

  4. ORACLE 数据泵 expdp/impdp

    ORACLE 数据泵 expdp/impdp 一.概念 Oracle Database 10g 引入了最新的数据泵(Data Dump)技术,数据泵导出导入 (EXPDP 和 IMPDP)的作用: 1 ...

  5. Oracle数据泵的使用

    几乎所有DBA都熟悉oracle的导出和导入实用程序,它们将数据装载进或卸载出数据库,在oracle  database 10g和11g中,你必须使用更通用更强大的数据泵导出和导入(Data Pump ...

  6. ORACLE数据泵使用详解

    来源于:http://blog.sina.com.cn/s/blog_490a0c990100wh4y.html http://blog.csdn.net/jojo52013145/article/d ...

  7. ORACLE数据泵还原(IMPDP命令)【转】

      Oracle数据库还原IMPDP命令是相对于EXPDP命令的,方向是反向的.即对于数据库备份进行还原操作.一.知晓IMPDP命令 ? C:\>impdp -help Import: Rele ...

  8. oracle数据泵备份(Expdp命令)[转]

      Oracle备份方式主要分为数据泵导出备份.热备份与冷备份三种,今天首先来实践一下数据泵备份与还原.数据泵导出/导入属于逻辑备份,热备份与冷备份都属于物理备份.oracle10g开始推出了数据泵( ...

  9. Oracle基础 数据泵导出/导入Expdp/impdp(转)

    一.EXPDP和IMPDP使用说明 Oracle Database 10g引入了最新的数据泵(Data Dump)技术,数据泵导出导入(EXPDP和IMPDP)的作用 1)实现逻辑备份和逻辑恢复. 2 ...

随机推荐

  1. 【Java每日一题】20161028

    package Oct2016; public class Ques1028 { public static void main(String[] args){ new B().out(); // 输 ...

  2. MySQL: @variable vs. variable. Whats the difference?

    MySQL: @variable vs. variable. Whats the difference?   up vote351down votefavorite 121 In another qu ...

  3. mysql-databaseython 3.4.0 with MySQL database

    Phttp://shttp://stackoverflow.com/questions/23376103/python-3-4-0-with-mysql-databasetackoverflow.co ...

  4. PHP团队编码质量提升之道

    这段文字其实只是标题党. 目前PHP猿的薪资水平普遍较高,但其实绝大多数PHP猿都不是科班出身,你问一个什么是OOP的问题可能都说不清楚. 在团队中,除了费力的去普及编程语言的基础知识,要想提高开发质 ...

  5. Struts2之Struts2-2.5.5 Interceptor

    Struts2-2.5.5版本是目前为止最新的版本了,相对于之前的2.3版本以及再之前的版本而言,新版本改动了很多. 好了,废话不多说,GO CODE! 基本jar包: web.xml核心配置,这里要 ...

  6. 优化JavaScripe 提升首页加载速度的几种方案解析

    优化目的: 1. 减少load量. 2. 优化js,加快页面加载速度. 网站中最影响网站打开速度的是什么?我会告诉是网站中的javascript,简称JS.模板中引用的JS文件越多,打开速度越慢,细读 ...

  7. Java基础复习笔记系列 二

    1.Java中Static的相关用法总结?(静态方法:静态变量:静态代码块) public static void main(String args[])执行的关键,在于有static.有了stati ...

  8. 你可能不需要 jQuery!使用原生 JavaScript 进行开发

    很多的 JavaScript 开发人员,包括我在内,都很喜欢 jQuery.因为它的简单,因为它有很多丰富的插件可供使用,和其它优秀的工具一样,jQuery 让我们开发人员能够更轻松的开发网站和 We ...

  9. javascript --- Function模式

    回调函数 在javascript中,当一个函数A作为另外一个函数B的其中一个参数时,则称A函数为回调函数,即A可以在函数B的运行周期内执行(开始,中间,结束). 举例来说,有一个函数用于生成node. ...

  10. AdaBoost

    一直想写Adaboost来着,但迟迟未能动笔.其算法思想虽然简单"听取多人意见,最后综合决策",但一般书上对其算法的流程描述实在是过于晦涩.昨日11月1日下午,邹博在我组织的机器学 ...