SQL 2005的SSIS與Oracle的遷移效能(轉)

SQL 2005的SSIS與Oracle的遷移效能(轉)[@more@]　　專案中存在一部分資料遷移的工作，說白了就是從老的系統中將資料倒換的新的系統模型中，老系統的資料來源比較複雜多樣，新的自然是Oracle9.2。

　　本來這也就是一次性工作，用SQL自然是最快的方式，不論是開發還是資料傳輸的速度。可是甲方偏偏要看到介面，希望這是一個成型的工具，沒辦法，甲方就是上帝。

　　公司原來也有一個遷移工具，可是隻能適用於表對錶的倒換，複雜一些無能為力，而且資料還巨慢，用過的人都是對它無語。

　　從新開發，不說花費和效果，光是時間也不行。沒辦法，只好看看現在流行的ETL的工具。

　　市場前列毋庸置疑，肯定是Informatia 和 DataStage.

　　Informatia沒有，只好看看DataStage是否能適應現在的功能要求。不想，雖然是圖形介面，可使用起來一點也不容易，而且安裝後，Windows下居然不能脫離域環境，而且不是Server版本的Windows還不能執行Paralle Job。鬱悶無比。

　　試了兩天後，暫時放下。Microsoft的易用性比功能強大更吸引我。試試SQL Server 2005中的SSIS，號稱企業級的ETL。

　　一用之後呢，沒想還真有點喜歡上了它，從介紹的和介面上看一點也不比DataStage的功能少，效能，哈，下面就是我要說得了。

　　ETL工具最慢的部分都是L這一部分，按照一般的說法能佔到總體時間的五分之四，所以這是關鍵。

　　測試也不算複雜，就是同樣的資料抽取、轉化、然後載入用不同的驅動分別跑一遍，目的庫已經確定是Oracle，所以也沒有太大的餘地了。

　　在SSIS中，有兩個驅動可以連線Oracle資料庫，一個是Microsoft OLEDB Provider for Oracle，另外一個是Oracle Provider for OLEDB

　　不測不知道，還真長了不少見識。

　　同一機器，同一資料來源，同一結果，兩者間還真有不少區別。

　　首先是速度（連續三次）： Microsoft OLEDB Provider for Oracle 1分37 1分32 1分30

　　Oracle Provider for OLEDB 1分10 1分07 1分02

　　在速度上 Oracle Provider for OLEDB 基本符合 1分3萬條左右，而Microsoft OLEDB Provider for Oracle 1分鐘只有2萬條左右。

　　照這樣看，答案似乎也就出來了，Oracle Provider for OLEDB也就成了不二選擇。

　　且慢，我還沒有說明為什麼選擇25萬條記錄而不是別的數量的資料呢。

　　這就不得不說說記憶體的使用：未啟動資料遷移時即停留在VS.Net設計介面時，記憶體已使用了790M左右，而我機器的實體記憶體也就896M。

　　執行開始後，25萬條記錄下Microsoft OLEDB Provider for Oracle 平均在1G左右，而Oracle Provider for OLEDB乖乖得不得了，鐵定在1.25G以上，一次還在1.3G。更離譜的是，原資料表中共有近100萬條記錄，Microsoft OLEDB Provider for Oracle在記憶體峰值1.5G左右可以順利完成，而Oracle Provider for OLEDB在記憶體使用一旦突破1.3G往上一些，就開始不停提示記憶體不足，不在安心的遷移資料了，或者乾脆顯示為紅色，報一些莫名的錯誤。

　　這就讓人兩難了，一個速度快了那麼50%，可確是一個記憶體消耗大戶，有沒有止境，我這破機器也無從得知。

　　另外一個速度慢，可卻節儉持家，窮人也照顧到了，哈。感覺好這有點像Oracle和MS的企業風格，一個走高階，為了需要的指標可以不計成本，窮人靠邊；另一個呢，還不錯，雖然也越來越來不鳥沒錢的人，可還做得不太顯眼。

　　最後了，同樣的資料來源（Microsoft OLEDB Provider for Oracle驅動），將目的庫換成SQL Server 2005,驅動為SQL Native Client,同樣的資料資料轉換，98.9萬條記錄中11.1萬條入庫，靠1分12完事，開啟FastLoad，58秒搞定。而且都只是第一次執行，相信如果多執行幾次後，結果應該更好。別說，自家孩子真就不一樣，別人的家的沒法比。

　　由於資料庫驅動接觸並不多，希望那個大蝦指點一下，能幫忙給找一個Windows下Oracle驅動可以媲美與SQL Native Client的，先謝了。