job掛起處理

expdp/impdp 掛起處理
現象：在執行expdp或者是impdp時，往往會出現導入表成功，但是在Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX或者其他地方掛起
處理方法：
1、檢查alert日誌
2、檢查主機資源 top(內存) + df -h
3、查看錶空間使用率
4、確定等待事件 
select sid,serial#,username,program,sql_id,event,p1,p2,p3 from v$session s, dba_datapump_sessions d where s.saddr = d.saddr;
依據等待事件進一步分析 
常見的等待事件：
1)、statement suspended, wait error to be cleared 
一般是由表空間不足，此時增加datafile，等待事件消失，但是仍然會報錯。
解決方法是:重新導入
2)、Streams AQ: enqueue blocked on low memory 與wait for unread message on broadcast channel等待
通過調整streams_pool_size解決（該參數爲SGA動態調整，但在執行expdp時，未能變化，默認爲0，導致內存不足而掛起）
SQL> show parameter streams
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
streams_pool_size                    big integer 0
SQL> alter system set streams_pool_size=200M scope=memory;


expdp/impdp涉及到一個參數：
SQL> SELECT SESSION_ID, STATUS, TIMEOUT, SUSPEND_TIME, RESUME_TIME, ERROR_NUMBER  from DBA_RESUMABLE;
SESSION_ID STATUS       TIMEOUT SUSPEND_TIME         RESUME_TIME          ERROR_NUMBER
---------- --------- ---------- -------------------- -------------------- ------------
      2140 SUSPENDED       7200 03/06/12 14:07:17                                 1659
      1999 NORMAL          7200                                                      0
查看resumable特性：
在dba_resumable表中可以查詢到resumable_timeout的值
SQL> show parameter timeout 
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
ddl_lock_timeout                     integer     0
distributed_lock_timeout             integer     60
log_checkpoint_timeout               integer     1800
resumable_timeout                    integer     0
雖然查看到timeout=0，但是在視圖中可以看到還是7200
SQL> SELECT SESSION_ID, STATUS, TIMEOUT, SUSPEND_TIME, RESUME_TIME, ERROR_NUMBER  from DBA_RESUMABLE;
SESSION_ID STATUS       TIMEOUT SUSPEND_TIME         RESUME_TIME          ERROR_NUMBER
---------- --------- ---------- -------------------- -------------------- ------------
      2140 NORMAL          7200                      03/06/12 14:15:02               0
      1999 NORMAL          7200 
      
10g導入的時候，有可能造成system表空間不足，Bug發生在導入表的統計信息處，解決bug可能很困難，繞過bug，使用EXCLUDE=TABLE_STATISTICIS


select * from dba_datapump_jobs t where t.owner_name like 'XXXX' and t.state='EXECUTING'；
STATE：正常導入的狀態是executing，而掛起是的狀態是DEFINING


查詢導入導出進程
select dds.owner_name,dds.job_name,dds.saddr,dds.session_type,vs.sid,vs.serial#,vp.spid from dba_datapump_sessions dds,v$session vs,v$process vp  where dds.saddr=vs.saddr and vs.paddr=vp.addr;
如果狀態全爲not running則可以直接drop；如果狀態不爲not running，則需要找出相應的操作系統進程 ，並進行kill；
SQL> drop table SYS_EXPORT_SCHEMA_01 purge;


如果系統還有非LOCAL=NO的連接，且時間都超過幾天了，一般都是異常的進程，建議查清楚後KILL掉
ps -ef | grep oracleprod | grep -v LOCAL=NO  | grep -v grep


查詢對應的sql
select a.username,a.sid,a.serial#,c.piece,c.sql_text
from v$session a,v$sqltext c
where a.sql_address = c.address
and a.sql_hash_value = c.hash_value
and (a.sid,a.serial#) in (select a.sid,a.serial#  from v$session a, v$process b where a.paddr=b.addr and b.spid = &spid )
order by a.sid,a.serial#,c.piece;