參考部落格 

日前接到一個case，使用者反映一個表匯出時間特別長，因為擔心影響第二天業務，不得不放棄繼續匯出，但是另外一個表比這個問題表數量更大，但是反而順利匯出，使用者在相同版本測試環境上也能順利匯出，當然測試環境和生產環境還是有差異的，客戶說那個環境是用兩個月前的備份恢復而成的，但是資料量差距並不十分明顯，但是匯出時間卻天壤之別，於是讓客戶對expdp進行trace，因為匯出時間特別長，所以只做了30min的，通過tkprof 檢視，時間基本都是io操作，但是因為另外一個表比這個資料量還大卻能順利匯出，所以可以排除是IO瓶頸問題，於是檢視原始trace檔案，大量的db file sequential read，統計了一下，數量非常之多，接近了blocks數量，隨便查找了一個block#，居然發現有多條記錄，例如下面的block#=1985 WAIT #140339720797184: nam='db file sequential read' ela= 4 file#=14 block#=1985 blocks=1 obj#=110002 tim=1458371261234480  WAIT #140339720797184: nam='db file sequential read' ela= 7 file#=13 block#=1989 blocks=1 obj#=110002 tim=1458371261234585  <skiping>...... WAIT #140339720797184: nam='db file sequential read' ela= 3 file#=14 block#=1985 blocks=1 obj#=110002 tim=1458371261234500 WAIT #140339720797184: nam='db file sequential read' ela= 8 file#=11 block#=1993 blocks=1 obj#=110002 tim=1458371261235086 WAIT #140339720797184: nam='db file sequential read' ela= 4 file#=8 block#=2385 blocks=1 obj#=110002 tim=1458371261234521 WAIT #140339720797184: nam='db file sequential read' ela= 4 file#=12 block#=2481 blocks=1 obj#=110002 tim=1458371261234541 為啥相同block要讀取多遍呢，難道是遇到了bug？客戶環境是10.2.0.5，expdp方面的bug應該是相當少的，突然想到應該是有行遷移或行連結造成的，於是讓使用者進行表分析，並檢視CHAIN_CNT果然數值非常高，但是測試環境和另外一個數據更大的表卻不是，所以解決辦法是找個時間對錶進行重建就行了。

參考部落格

set lines 150 pages 100 numwidth 7 col program for a38 col username for a10 col spid for a7 select 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; PROGRAM SID STATUS USERNAME JOB_NAME SPID SERIAL# PID -------------------------------------- ------- -------- ---------- ------------------------------ ------- ------- ------- [email protected] (DW04) 2235 ACTIVE SYS SYS_EXPORT_TABLE_01 5417 59 190 [email protected] (DW03) 2165 ACTIVE SYS SYS_EXPORT_TABLE_01 5415 469 188 [email protected] (DW02) 2091 ACTIVE SYS SYS_EXPORT_TABLE_01 5375 1443 186 [email protected] (DW01) 2199 ACTIVE SYS SYS_EXPORT_TABLE_01 5267 169 189 [email protected] (DW00) 1840 ACTIVE SYS SYS_EXPORT_TABLE_01 65409 233 179 [email protected] (DM00) 1408 ACTIVE SYS SYS_EXPORT_TABLE_01 63477 3517 39 [email protected] (TNS V1-V3) 3 ACTIVE SYS SYS_EXPORT_TABLE_01 62550 103 192 7 rows selected. 開啟trace檔案日誌跟蹤，等待10分鐘 execute sys.dbms_system.set_ev(2199,169,10046,8,''); 關閉trace檔案日誌跟蹤 execute sys.dbms_system.set_ev(2199,169,10046,0,''); 找到trace檔案 sypmjt2_dw01_5267.trc 可以看到 WAIT #140365092251440: nam='db file sequential read' ela= 6275 file#=27 block#=3137332 blocks=1 obj#=75841554 tim=1470634155505446
WAIT #140365092251440: nam='db file sequential read' ela= 14319 file#=29 block#=3340314 blocks=1 obj#=75841554 tim=1470634155519872
oracle 進行表分析，並檢視CHAIN_CNT數值 SQL> analyze table USER.TABLE compute statistics; Table analyzed. SQL> select table_name,chain_cnt from dba_tables where table_name='TABLE'; TABLE_NAME CHAIN_CNT ------------------------------ ---------- TABLE 17 注意，chain_cnt記錄的是行遷移和行連線的數量，不要以為這個值大於0就發生了行遷移，也可能是行連線，此時要分析表的結構，檢視到底是行連線或者是行遷移