的与的牛

保障了奥运期间的络信息安全。 照这样看，答案似乎也就出来了，Oracle Provider for OLEDB也就成了不二选择。 且慢，我还没有说明为什么选择25万条记录而不是别的数量的数据呢。 这就不得不说说内存的使用：未启动数据迁移时即停留在设计界面时，内存已使用了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的，先谢了。