impdp時卡住,DW等待library cache lock
阿新 • • 發佈：2019-01-16
同事反映impdp時在SCHEMA_REPORT/TYPE/TYPE_SPEC步驟卡住，1個多小時後也沒有響應，
查下v$session：
select program,sid, event,blocking_session from gv$session where program like '%DW%';
結果為：
DW01,98,library cache lock,213
DW03,13,library cache lock,213
DW02,36,library cache lock,213
DW00,213,library cache lock,213
所有的DW程序都在等待library cache lock，看了下之前的impdp引數：
impdp u/p dumpfile=f.dmp schemas=a remap_schema=a:b remap_tablespace=a:b TABLE_EXISTS_ACTION=REPLACE transform=oid:n
原來是之前有一次impdp時中途終止，所以再次impdp時使用了TABLE_EXISTS_ACTION=REPLACE的選項，但問題在於建立一個TYPE時，
CREATE OR REPLACE TYPE "O_INDO" as OBJECT
(
CODE_ID varchar2(400)
);
而另一個TYPE O_INDO_TABLE依賴於這個O_INDO，所以導致無法replace這個O_INDO，所有的DW會話都在等待library cache lock，並且session阻塞了自身，形成了一個死鎖。
解決辦法：
DROP掉SCHEMA B，並重新執行impdp.
查下v$session：
select program,sid, event,blocking_session from gv$session where program like '%DW%';
結果為：
DW01,98,library cache lock,213
DW03,13,library cache lock,213
DW02,36,library cache lock,213
DW00,213,library cache lock,213
所有的DW程序都在等待library cache lock，看了下之前的impdp引數：
impdp u/p dumpfile=f.dmp schemas=a remap_schema=a:b remap_tablespace=a:b TABLE_EXISTS_ACTION=REPLACE transform=oid:n
原來是之前有一次impdp時中途終止，所以再次impdp時使用了TABLE_EXISTS_ACTION=REPLACE的選項，但問題在於建立一個TYPE時，
CREATE OR REPLACE TYPE "O_INDO" as OBJECT
(
CODE_ID varchar2(400)
);
而另一個TYPE O_INDO_TABLE依賴於這個O_INDO，所以導致無法replace這個O_INDO，所有的DW會話都在等待library cache lock，並且session阻塞了自身，形成了一個死鎖。
解決辦法：
DROP掉SCHEMA B，並重新執行impdp.