同事反映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.