This content has been marked as final. Show 7 replies
You can type a CTRL-c and you will get to an:
prompt. At this prompt, you can type status to see what is being done. Maybe it is an index, maybe it is something else. Look at the worker status rows to see what the workers are doing. Typing the ctrl-c will not stop the job. It just stops printing the status to the x-term. You can get back to the regular window by typing continue.
Hope this helps.
You can also run this query to see what data is left to import:
select sum(dump_orig_length), processing_state
from "SYSTEM"."SYS_IMPORT_FULL_01“ -- < your master table /job name goes here
where process_order > 0 and duplicate = 0 and
object_type = 'TABLE_DATA‘
group by processing_state;
13408128 W -- already imported
2525400 R -- to be imported
24944 X -- excluded
Rows with the 'W' state have already been imported.
Rows with the 'R' state still need to be imported.
Rows with the 'X' state have been excluded from the job (through filters and other things)
Hope this helps.
try tracing when it's 99% and see what's happening behind..
-- Syntax: DBMS_SYSTEM.SET_EV([SID],[SERIAL#],[EVENT],[LEVEL],'')
set lines 150 pages 100 numwidth 7
col program for a38
col username for a10
col spid for a7
select to_char(sysdate,'YYYY-MM-DD HH24:MI:SS') "DATE", s.program, s.sid,
s.status, s.username, d.job_name, p.spid, s.serial#, p.pid
from v$session s, v$process p, dba_datapump_sessions d
where p.addr=s.paddr and s.saddr=d.saddr;
Edited by: khallas301 on Nov 30, 2012 1:56 PM
Thank you for the ideas. I did use a level 8 trace only to find that although I was doing a DATA_ONLY load the index objects tied to the tables rebuilt before the impdp process would 'let go' and complete. So while the data load itself did not call to rebuild/instantiate the other objects, because they existed they had to complete. It is running slow, but it is running.