1.首先是EXP的常規路徑導出：
exp zhejiang/zhejiang file=/data1/zj_regular.dmp buffer=20480000
常規EXP導出方式執行了1小時24分鐘。
2.直接路徑導出方式：
exp zhejiang/zhejiang file=/data1/zj_direct.dmp buffer=20480000
recordlength=65535 direct=y
直接路徑導入用時18分鐘，比常規路徑導出速度有一個明顯的提高。
3.數據泵的導出速度。
expdp zhejiang/zhejiang dumpfile=zj_datapump.dp directory=d_test schemas=zhejiang
數據泵的導出時間僅用了14分鐘，比直接路徑導入方式還快了20%多。而且觀察三個導出文件的大小可以發現，導出速度越快對應的文件也越小，其中數據泵的導出方式得到的文件要比EXP方式小將近1.5G。
IMP和IMPDP導入性能對比
1.IMP的導入速度：
imp zhejiang/zhejiang file=/data1/zj_regular.dmp full=y buffer=20480000 log=/data1/zj_regular.log
IMP導入花費了3小時17分鐘，
2.IMPdp的導入速度：
impdp zhejiang/zhejiang DUMPFILE=zj_datapump.dp DIRECTORY=d_test FULL=y LOGFILE=zj_datapump.log
數據泵的導入(parallel參數)操作居然花了3個小時8分鐘的時間，和IMP的導入速度十分接近，看來並非所有情況下都像Oracle描述的那樣，數據泵的導入比普通導入效率有大幅度的提高。
上面一篇文章的測試中發現IMPDP的導入速度和IMP導入速度相差無幾。而Oracle在介紹數據泵的時候，提到IMPDP的導入速度最高是IMP的10倍。不過好在IMPDP還是可以優化調整的，那就是通過設置PARALLEL來提高IMPDP的並行度。
首先還是看一下CPU的數量：
SQL> show parameter cpu
由於數據庫服務器的CPU個數爲2，下面嘗試設置PARALLEL爲2來進行導入
impdp zhejiang/zhejiang DUMPFILE=zj_datapump.dp DIRECTORY=d_test FULL=y LOGFILE=zj_datapump.log parallel=2
採用並行度爲2的導入方式，發現速度果然提高了很多。並行度爲1的導入速度是3小時8分鐘，而現在用了不到2個半小時。
由於並行度設置不應該超過CPU數的2倍，因此嘗試平行度3和4的導入，導入時間和並行度2十分接近。看來已經無法再使用通過提高並行度的方法來提高性能了。
1.先看直接導出的性能：
$ expdp zhejiang/zhejiang directory=d_test dumpfile=zhejiang.dp
整個導出操作大概用了14分半，
2.嘗試使用並行度2進行導出，這時仍然設置一個導出的數據文件：
$ expdp zhejiang/zhejiang directory=d_test dumpfile=zhejiang_p2_1file.dp parallel=2
整個導入過程不到14分鐘，不過這個性能的提升實在不是很明顯。不過這是有原因的，由於設置了並行度，兩個進程在同時執行導出操作，但是二者要將導出的數據寫入同一個數據文件中，因此必然會導致資源的爭用
3.仍然使用並行度2，但是同時設置兩個數據文件再次檢查導出性能：
$ expdp zhejiang/zhejiang directory=d_test dumpfile=zhejiang_p2_2file1.dp,zhejiang_p2_2file2.dp parallel=2
這次導出僅僅用了10分半，導出的效率大大的提高。
4.測試一下並行度4，分別導出到4個數據文件中：
用了9分鐘整導出完成，設置成並行度4仍然可以獲得一定的性能提升，但是並不明顯了，這主要是由於整個性能的瓶頸已經不是單個進程的處理能力，多半性能的瓶頸已經變成了磁盤IO瓶頸，此時單單靠增加並行度已經無法明顯提升性能了。