Colleagues reflect IMPDP when the Schema_report/type/type_spec step stuck, 1 hours later also did not respond,
Check the v$session:
Select Program,sid, event,blocking_session from gv$session where program like '%dw% ';
The result is:
Dw01,98,library Cache lock,213
Dw03,13,library Cache lock,213
Dw02,36,library Cache lock,213
Dw00,213,library Cache lock,213
All DW processes are waiting for the library cache lock to see the previous IMPDP parameters:
IMPDP u/p dumpfile=f.dmp schemas=a remap_schema=a:b remap_tablespace=a:b table_exists_action=replace transform=oid:n
It turns out that there was a IMPDP when it was terminated halfway, so the option to use Table_exists_action=replace when IMPDP again, but the problem is that when you create a type,
CREATE OR REPLACE TYPE "O_indo" as OBJECT
(
code_id VARCHAR2 (400)
);
The other type o_indo_table relies on this o_indo, so it is impossible to replace the O_indo, all the DW sessions are waiting for the library cache lock, and the session blocks itself, forming a deadlock.
Workaround:
Drop schema B and re-execute IMPDP.
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
IMPDP when stuck, DW waits for library cache lock
