背景介紹

11g資料庫在進行IMPDP資料恢復的時候，有時候恢復操作一直卡這不動，這時候可以查詢下該恢復會話的等待事件，如果看到等待事件是“wait for unread message on broadcast channel”，透過以下思路解決。

原因分析

一般造成該問題的原因有兩種：出現可能是假死或者匯入物件為大物件，造成表象為卡頓的現象。首先觀察資料庫告警日誌，發現告警日誌中顯示正常，並未提示表空間無法擴充，不足的情況；

針對程式進行分析，檢查是否有其他程式阻塞了IMPDP程式；

 SQL> select * from dba_datapump_jobs;

 OWNER_NAME JOB_NAME OPERATION JOB_MODE STATE DEGREE ATTACHED_SESSIONS DATAPUMP_SESSIONS

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

 SYSTEM NEW1 IMPORT TABLE EXECUTING 4 1 3

 SYSTEM SYS_IMPORT_FULL_01 IMPORT FULL NOT RUNNING 0 0 0

 執行上述命令後，發現還存在一個未在執行的資料庫impdp程式，造成該問題的原因可能是我前期停止了一個impdp程式的關係。

 此時查詢該JOB涉及的物件：

 SQL> SELECT a.object_id, a.object_type, a.owner, a.object_name, a.status

 FROM dba_objects a, dba_datapump_jobs j

 WHERE a.owner=j.owner_name AND a.object_name=j.job_name

 and j.job_name='SYS_IMPORT_FULL_01';

 OBJECT_ID OBJECT_TYPE OWNER OBJECT_NAME STATUS

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

 984119 TABLE SYSTEM SYS_IMPORT_FULL_01 VALID

 查詢的結果顯示：是一個系統在匯入時生成的表：

 SQL> select owner,object_name,subobject_name, object_type,last_ddl_time from dba_objects where object_id=984119

 /

 查詢最後更改的資訊，避免刪除錯誤：

 OWNER OBJECT_NAME SUBOBJECT_NAME OBJECT_TYPE LAST_DDL_TIME

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

 SYSTEM SYS_IMPORT_FULL_01 TABLE 13-03-2015 19:59:50

處理過程

 確定問題所在，接下來我們只需要刪除IMPDP時產生的表：

 SQL> drop table SYSTEM.SYS_IMPORT_FULL_01;

 Table dropped.

 此時再次檢查我們的IMPDP程式發現恢復正常。

 SQL> select * from dba_datapump_jobs;

 OWNER_NAME JOB_NAME OPERATION JOB_MODE STATE DEGREE ATTACHED_SESSIONS DATAPUMP_SESSIONS

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

 SYSTEM NEW1 IMPORT TABLE EXECUTING 4 1 6

關鍵知識點

1.資料泵操作是後臺作業模式，即使前端結束，後臺也會持續的執行。

2.資料泵執行過程中，會產生臨時資料記錄執行的狀態和過程，執行結束後，臨時資料會被刪除。