項(xiàng)目中存在一部分?jǐn)?shù)據(jù)遷移的工作，說(shuō)白了就是從老的系統(tǒng)中將數(shù)據(jù)倒換的新的系統(tǒng)模型中，老系統(tǒng)的數(shù)據(jù)來(lái)源比較復(fù)雜多樣，新的自然是OracleArray.2。

　　本來(lái)這也就是一次性工作，用SQL自然是最快的方式，不論是開(kāi)發(fā)還是數(shù)據(jù)傳輸?shù)乃俣??？墒羌追狡吹浇缑妫Ｍ@是一個(gè)成型的工具，沒(méi)辦法，甲方就是上帝。

　　公司原來(lái)也有一個(gè)遷移工具，可是只能適用于表對(duì)表的倒換，復(fù)雜一些無(wú)能為力，而且數(shù)據(jù)還巨慢，用過(guò)的人都是對(duì)它無(wú)語(yǔ)。

　　從新開(kāi)發(fā)，不說(shuō)花費(fèi)和效果，光是時(shí)間也不行。沒(méi)辦法，只好看看現(xiàn)在流行的ETL的工具。

　　市場(chǎng)前列毋庸置疑，肯定是Informatia 和 DataStage.

　　Informatia沒(méi)有，只好看看DataStage是否能適應(yīng)現(xiàn)在的功能要求。不想，雖然是圖形界面，可使用起來(lái)一點(diǎn)也不容易，而且安裝后，Windows下居然不能脫離域環(huán)境，而且不是Server版本的Windows還不能運(yùn)行Paralle Job。郁悶無(wú)比。

　　試了兩天后，暫時(shí)放下。Microsoft的易用性比功能強(qiáng)大更吸引我。試試SQL Server 2005中的SSIS，號(hào)稱企業(yè)級(jí)的ETL。

　　一用之后呢，沒(méi)想還真有點(diǎn)喜歡上了它，從介紹的和界面上看一點(diǎn)也不比DataStage的功能少，性能，哈，下面就是我要說(shuō)得了。

　　ETL工具最慢的部分都是L這一部分，按照一般的說(shuō)法能占到總體時(shí)間的五分之四，所以這是關(guān)鍵。

　　測(cè)試也不算復(fù)雜，就是同樣的數(shù)據(jù)抽取、轉(zhuǎn)化、然后加載用不同的驅(qū)動(dòng)分別跑一遍，目的庫(kù)已經(jīng)確定是Oracle，所以也沒(méi)有太大的余地了。

　　在SSIS中，有兩個(gè)驅(qū)動(dòng)可以連接Oracle數(shù)據(jù)庫(kù)，一個(gè)是Microsoft OLEDB Provider for Oracle，另外一個(gè)是Oracle Provider for OLEDB

　　不測(cè)不知道，還真長(zhǎng)了不少見(jiàn)識(shí)。

　　

　　同一機(jī)器，同一數(shù)據(jù)源，同一結(jié)果，兩者間還真有不少區(qū)別。

　　首先是速度（連續(xù)三次）： 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萬(wàn)條左右，而Microsoft OLEDB Provider for Oracle 1分鐘只有2萬(wàn)條左右。

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

　　且慢，我還沒(méi)有說(shuō)明為什么選擇25萬(wàn)條記錄而不是別的數(shù)量的數(shù)據(jù)呢。

　　這就不得不說(shuō)說(shuō)內(nèi)存的使用：未啟動(dòng)數(shù)據(jù)遷移時(shí)即停留在VS.Net設(shè)計(jì)界面時(shí)，內(nèi)存已使用了7Array0M左右，而我機(jī)器的物理內(nèi)存也就8Array6M。

　　運(yùn)行開(kāi)始后，25萬(wàn)條記錄下Microsoft OLEDB Provider for Oracle 平均在1G左右，而Oracle Provider for OLEDB乖乖得不得了，鐵定在1.25G以上，一次還在1.3G。更離譜的是，原數(shù)據(jù)表中共有近100萬(wàn)條記錄，Microsoft OLEDB Provider for Oracle在內(nèi)存峰值1.5G左右可以順利完成，而Oracle Provider for OLEDB在內(nèi)存使用一旦突破1.3G往上一些，就開(kāi)始不停提示內(nèi)存不足，不在安心的遷移數(shù)據(jù)了，或者干脆顯示為紅色，報(bào)一些莫名的錯(cuò)誤。

　　這就讓人兩難了，一個(gè)速度快了那么50%，可確是一個(gè)內(nèi)存消耗大戶，有沒(méi)有止境，我這破機(jī)器也無(wú)從得知。

　　另外一個(gè)速度慢，可卻節(jié)儉持家，窮人也照顧到了，哈。感覺(jué)好這有點(diǎn)像Oracle和MS的企業(yè)風(fēng)格，一個(gè)走高端，為了需要的指標(biāo)可以不計(jì)成本，窮人靠邊；另一個(gè)呢，還不錯(cuò)，雖然也越來(lái)越來(lái)不鳥(niǎo)沒(méi)錢的人，可還做得不太顯眼。

　　最后了，同樣的數(shù)據(jù)源（Microsoft OLEDB Provider for Oracle驅(qū)動(dòng)），將目的庫(kù)換成SQL Server 2005,驅(qū)動(dòng)為SQL Native Client,同樣的數(shù)據(jù)數(shù)據(jù)轉(zhuǎn)換，Array8.Array萬(wàn)條記錄中11.1萬(wàn)條入庫(kù)，靠1分12完事，打開(kāi)FastLoad，58秒搞定。而且都只是第一次運(yùn)行，相信如果多運(yùn)行幾次后，結(jié)果應(yīng)該更好。別說(shuō)，自家孩子真就不一樣，別人的家的沒(méi)法比。

　　由于數(shù)據(jù)庫(kù)驅(qū)動(dòng)接觸并不多，希望那個(gè)大蝦指點(diǎn)一下，能幫忙給找一個(gè)Windows下Oracle驅(qū)動(dòng)可以媲美與SQL Native Client的，先謝了。