項目中存在一部分數據遷移的工作，說白了就是從老的系統中將數據倒換的新的系統模型中，老系統的數據來源比較復雜多樣，新的自然是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的，先謝了。
