一、 環境資訊：
Oracle 11.1.0.7.0 - 64bit，單機，AIX 6.1
二、 EXPDP性能診斷
1、 expdp腳本如下：
cat exp_SCOTT_20180511.par
2、導出整個schema的時間大約為13個小時，資料量133GB：
3、 expdp 導出過程10046 Trace追蹤診斷：
因該庫需要使用expdp按schema導出導入方式進行整庫遷移，按照一個schema導出需要13個小時的速度是接受不了的，雖然該機器配置不是非常的好。接下來導出另外一個schema，并啟用10046 trace追蹤：
同時檢視相關trace檔案的的資訊：
發現這些在等待的這些對象基本都是SYS使用者下：
同時檢視expdp導出日志，是在估算大小：
Total estimation using BLOCKS method:xxx.xx GB
初步診斷為，expdp在導出時，要估算導出大小，需要查詢sys使用者下的基表，很有可能是這些查詢的SQL出現了性能問題。
發現該表統計資訊很久沒有更新，接連查詢其它表的統計資訊，發現都是很久沒有更新統計資訊。于是做了如下操作，先将相關表的統計資訊更新到最新：
然後中斷已經在導出的程序，等統計資訊收集完成後，再執行導出，測試導出速度是否有提升。發現導出速度并沒有明顯提升，看來真正的問題并沒有找到，再次進行trace追蹤。
然後發現如下SQL異常：
查詢該SQL曆史執行的情況：
因為是expdp導出執行的sql，對于這樣的sql有一個好處，就是可以對比相同版本的其它庫的曆史執行計劃。
造成相同執行計劃在不同庫性能差異的這種情況的原因有很多，比如優化器的相關參數設定不同、機器配置不同，庫本身的性能較好或庫本身很空閑等。這裡不對這些原因進行分析，先分析一下該SQL，看看該SQL的執行計劃是否合理：
然後與該trace追蹤到的執行計劃進行對比：
發現該SQL使用的優化器模式是Rule Based Optimizer(簡稱RBO)，是基于資料字典的優化，它根據資料字典查詢有無可用的索引，如果有則使用，否則不使用，不同的通路方法有預定好的優先級，選擇優先級高的執行方法。但在這裡不知道它為什麼沒有選擇走CDEF$的I_CDEF3索引，而是走了全表掃描。這也可以解釋為什麼收集完sys使用者統計資訊之後，執行計劃不變的原因了。那問題來了，是使用CBO做索引掃描的執行效率高，還是現在RBO模式的效率高呢？經測試，使用Cost Based Optimizer(簡稱CBO)的效率高，也就是通過變量資訊産生的真正執行計劃。
既然問題已經找到，接下來就好辦了，使用coe_xfr_sql_profile.sql直接綁定較優的執行計劃。
綁定後的執行計劃效果如下：
綁定之後的提升效果還是很明顯的，單次平均執行時間已經下降到0.002秒，平均邏輯讀也成倍的下降。這裡為什麼說很明顯呢？可能看起來0.081秒的執行效率已經很高了，但是這個sql的是需要很次執行的，在expdp導出schema的過程中，需要查詢整個schema的所有對象。
優化後的導出效果，1個多小時就完成了導出：
三、 總結
1、 對于expdp/impdp的性能影響因素很多，比如庫整體性能，機器配置情況，存儲I/O資源等。
2、 有關expdp/impdp性能診斷請參考：
SRDC - 資料泵導入（IMPDP）性能問題的診斷收集 (Document 2365615.1)
SRDC - 資料泵導出性能問題的診斷收集 (Document 2365568.1)
針對資料泵導出 (expdp) 和導入 (impdp)工具性能降低問題的檢查表 (Document 1549185.1)