手動清除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表的操做不會形成任何不一致。

 

其餘資源

社區：數據庫社區