資料泵不同工作方式效能比較（六）

根據Oracle的文件的描述，資料泵採用不同的方式匯出匯入，效能也會有明顯的差別，這次正好有機會測試一下，遷移表空間、直接路徑、外部表方式，以及資料庫鏈方式匯出、匯入的效能差異。

資料泵不同工作方式效能比較（一）：http://yangtingkun.itpub.net/post/468/496368

資料泵不同工作方式效能比較（二）：http://yangtingkun.itpub.net/post/468/496396

資料泵不同工作方式效能比較（三）：http://yangtingkun.itpub.net/post/468/496397

資料泵不同工作方式效能比較（四）：http://yangtingkun.itpub.net/post/468/496398

資料泵不同工作方式效能比較（五）：http://yangtingkun.itpub.net/post/468/496399

這篇總結一下資料泵不同工作方式的效能差異。

 

 

之所以寫了這六篇文章，是因為在看Oracle的官方文件工具手冊的時候，Oracle明確的說明了這四種方式的效率，TRANSPORT TABLESPACE > DIRECT > EXTERNAL TABLE > NETWORK LINK。所以打算驗證一下Oracle給出的結論。

首先看看經過前面的測試，目前得到的測試資料：

SQL> SELECT * FROM T_EXPDP_IMPDP_RECORD;

TYPE                 EXPDP_TIME TRANS_TIME IMPDP_TIME OTHER_TIME TOTAL_TIME
-------------------- ---------- ---------- ---------- ---------- ----------
TRANSPORT_TABLESPACE         61       2639        262         58       3020
DIRECT                      289        623        866        150       1928
NETWORK_LINK                  0          0       2076        150       2226
EXTERNAL_TABLE              445        623        952        150       2170

SQL> SELECT TYPE,
  2  TOTAL_TIME,
  3  ROUND(EXPDP_TIME/TOTAL_TIME*100, 2) EXPDP_RATE,
  4  ROUND(TRANS_TIME/TOTAL_TIME*100, 2) TRANS_RATE,
  5  ROUND(IMPDP_TIME/TOTAL_TIME*100, 2) IMPDP_RATE,
  6  ROUND(OTHER_TIME/TOTAL_TIME*100, 2) OTHER_RATE
  7  FROM T_EXPDP_IMPDP_RECORD
  8  ORDER BY 2;

TYPE                 TOTAL_TIME EXPDP_RATE TRANS_RATE IMPDP_RATE OTHER_RATE
-------------------- ---------- ---------- ---------- ---------- ----------
DIRECT                     1928      14.99      32.31      44.92       7.78
EXTERNAL_TABLE             2170      20.51      28.71      43.87       6.91
NETWORK_LINK               2226          0          0      93.26       6.74
TRANSPORT_TABLESPACE       3020       2.02      87.38       8.68       1.92

根據測試的結果，直接路徑用時最短：32分8秒；外部表方式次之：36分10秒；網路直接匯入方式更慢：37分6秒，而傳輸表空間用時反而最多，居然用時50分20秒。

那麼匯出的結論就是直接路徑、外部表和網路方式和Oracle文件描述的一致，而傳輸表空間匯出效率最低。雖然匯出的資料檔案只有將近7個G，與資料檔案的28G相比不算很大，但是當前的環境兩個表空間的佔用超過了80%，這對於大部分環境而言已經算很高的了。看來傳輸表空間並不像Oracle文件描述的效率最高，反而效率是最低的。

其實如果草率的就得出上面的結論，這篇文章就完全沒有必要了。只需要在上面一篇文章的最後，把所有的測試結果一列，就可以結束了。

首先來看傳輸表空間匯出模式，可以看到，整個操作的87%的時間用於網路傳送。而第一篇文章單獨來描述測試的環境其實是有意義的，由於當前環境是百兆網路，所以對於傳送表空間的測試來說，網路效能就是效能的瓶頸所在。如果在一個千兆網中，網路速度提高10倍，則網路傳送的時間將會變為1/10，這時傳送表空間模式總共用時也不到11分鐘，比目前速度最快的直接路徑方式的匯入這一個步驟還要快。因此，Oracle將傳送表空間方式認為是速度最快是有道理的。何況對於有些情況而言，傳輸表空間是不需要網路傳輸的，這時傳輸表空間的效能優勢就更加突出了。

那麼對於百兆的網路而言，傳送表空間是否優勢不明顯呢。其實也不見得，為了測試的方便，在這個例子中並沒有對網路傳輸的物件進行壓縮，如果網路傳輸成為瓶頸，那麼可能壓縮會帶來一定的效能提升。當然壓縮能否帶來效能提升除了與壓縮物件的大小已經網路傳輸速率有關，還與其他硬體的情況，比如CPU、記憶體和磁碟的IO能力有關。

其實從道理上也可以很容易分析，對於傳輸表空間方式，由於不需要邏輯方式處理資料，因此唯一耗時的就是資料檔案的複製。對於當前環境，網路成為效能的瓶頸，那麼傳輸表空間顯然不會有太好的效能表現。舉個極端的例子，如果網路條件是專線，至於10M甚至更少的傳輸速率，那麼這種情況下使用傳輸表空間方式，絕對是噩夢的開始。

對於直接路徑、外部表方式和網路匯出方式而言，得到的結果基本上和預期一致。除了剛才提到的壓縮匯出檔案來提高網路傳送檔案效能外，還可以採用並行的方式來提高匯出和匯入的效能。如果IO處理能力足夠，使用並行能明顯的提高匯出和匯入的速度。

至於外部表方式效率較低其實也不用過於關心，只要可能Oracle會自動使用直接路徑方式進行匯出和匯入，只有條件不滿足直接路徑方式時，才會使用外部表方式。而且即使使用外部表，也不會想這個例子中，對所有表的匯出和匯入都使用外部表，而只是個別不滿足直接路徑條件的才使用外部表，因此不會帶來太大的效能影響。

網路匯出方式的效率最低，但是與其他方式相比，並沒有數量級上的差異。如果只是將網路匯出與直接路徑、外部表匯出做比較，或者將網路匯入，與直接路徑、外部表匯入進行對比，都是不公平的，因為網路匯出還要包括傳送資料的步驟，而網路的匯入不僅包括傳送資料，還包括匯出操作。

不過這篇中採用的對比方式，網路匯入方式其實會佔一定的便宜，因為這種方式不像外部表和直接路徑那樣匯出就是匯出，不會同時進行其他的操作，而是匯出的同時資料就在傳送，資料傳送的同時，就在進行匯入操作，可以認為是匯出、資料傳送和匯入的並行操作。

第二個查詢給出了每種資料庫工作方式的各個步驟所佔總體時間的百分比。透過這個結果可以找到每種類似最花費時間的操作，也就是效能瓶頸。如要進行最佳化，那麼就可以將最大的精力放在花費時間最多的步驟上。以傳輸表空間方式而言，提高匯出和匯入的效率的意義就不大了。

對於提高資料泵的效能，找到最耗費時間的步驟，還要找到效能的瓶頸。一般而言，網路、IO能力是常見的效能瓶頸，如果這兩方面都不是瓶頸，那麼可能Oracle處理能力沒有完全發揮出來，可以利用上面提到的並行方式來更充分的利用資源。

最後還要提一句，除了表中所列的步驟外，還有一些操作是不可避免的，比如傳輸表空間方式，就要進行大量的檢查工作。除了檢查字符集、版本以及BLOCK_SIZE之外，還要檢查表空間的完整性、使用者與表空間直接的關係等等。即使匯出結束後，也要對比是否所有需要的物件都已經匯入到目標資料庫。而對於NETWORK_LINK方式而言，操作可以說是最簡單的，只需要一個命令，匯出、資料傳輸和匯入就全部完成，對於資料量不是很大的情況，操作的複雜程度也是值得考慮的。