SQL2005的SSIS与Oracle的迁移性能

项目中有一部分是数据迁移。说白了，在新的系统模型中，旧系统的数据源复杂多样，新的自然是Oracle9.2。
本来，这是一次性的工作。自然，无论是开发速度还是数据传输，使用SQL都是最快的方式。但是，甲方只是想看看界面，希望是成型工具。没办法，甲方是神。
本来是有迁移工具的，但是只能用于表间切换。很复杂你也无能为力，数据还是那么慢，用过的人都无语了。
重新开发，不说成本和效果，不仅仅是时间。忍不住看看现在流行的ETL工具。
毫无疑问，Informatia和DataStage走在了市场的前列。
Informatia没有，所以我们要看看DataStage是否能满足目前的功能需求。不会，虽然是图形界面，但是不好用，而且安装后离不开Windows下的域环境，也不是服务器版的Windows不能运行Paralejob。很郁闷。
试了两天，暂时放下。微软的易用性比它强大的功能更吸引我。试试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基本符合每分钟3万篇左右，而Microsoft OleDB Provider for Oracle考试。大提示每分钟只有2万篇左右。
就这样，答案似乎出来了，Oracle Provider for OLEDB成为了最佳选择。
等一下，我还没解释为什么选择25万条记录而不是其他数据。
不得不说一下内存的使用问题:我们在数据迁移开始前停留在VS.Net的设计界面时，内存已经使用了790M左右，而我的机器物理内存只有896M。
运营开始后，25万条记录显示，微软OleDB Provider for Oracle平均1G左右，而Oracle Provider for OLEDB表现极为出色，肯定在1.25G以上，而且一度还是1.3G。更离谱的是，原始数据表中有近100万条记录。微软OleDB Provider for Oracle在内存峰值在1.5g左右时可以顺利完成任务，但是一旦Oracle Provider for OLEDB的内存使用量超过1.3G，就开始不断提示内存不足，迁移数据不再安全，或者干脆显示为红色并报告一些莫名其妙的错误。
左右为难。快了50%的机器真的是内存消耗大户。到底有没有尽头，我这个破机器也无从得知。
另一个慢，但是节俭，穷人也管，哈。嗯，感觉有点像甲骨文和MS的企业风格，一个走高端，为了要求的指标可以忽略成本，穷人靠边站；另一个，还不错，不太显眼，虽然对没钱的人越来越冷漠。
最后，同样的数据源(由Microsoft OleDB Provider for Oracle驱动)，目的库改为SQL Server 2005，驱动为SQL Native Client。同样的数据转换，989，000条记录中的111，000条记录入库，需要1分12秒才能完成。开启FastLoad，58秒搞定。而且才第一次跑。相信多跑几次，效果应该会更好。别说，自己的孩子真的不一样，别人家没法比。
由于对数据库驱动接触不多，希望大虾给点意见，帮我找一个Windows下可以媲美SQL Native Client的Oracle驱动。提前感谢。