SQL SERVER 数据库链接服务器总结
因此在SQL SERVER 数据库服务器上建立到Oracle远程链接服务器。下面就在不同版本中的SQL SERVER上建立连接服务器的经验作一小结，希望对各位有用。
1、SQL SERVER 2000
SQL SERVER 2000下连接服务器在“安全性”节点下。右键点击“链接服务器”——新建，打开连接服务器属性框。
在链接服务器编辑框填写链接服务器的名称，这是远程数据库到本地SQL Server的映射。
服务器类型选择其它数据库（SQL SERVER 不做阐述）。到Oracle数据库的链接提供程序有两种：Microsoft OLE DB Provider for Oracle; Oracle Provider for OLE DB.这两种提供者有不同的特点，表现在数据链接速度上也不同，在此先选择前者。
产品名称是作为链接服务器添加的 OLE DB数据源，可自己定义。
数据源是Oracle 数据库的别名，必须与Oracle数据库中的数据库名称相同。
安全性——选择用此安全上下文进行：远程登录名是登录Oracle数据库的登录名。注意一点，Oracle数据库中区分大小写，切记！
密码当然前些Oracle数据库的登录密码啦！
至此 SQL SERVER 2000下的链接服务器已经配置完毕！
SQL SERVER 2000下点击链接服务器可以看到数据表的映射。
检验一下：打开查询分析器： Select * from AAA..BBB.TABLE NAME
AAA为连接服务器的名称 BBB为登录名。
注意：各个部分最好使用大写
查询执行成功（当然您必须已经安装了Oracle 的客户端）。
2、SQL SERVER 2005
连接服务器在服务器对象——链接服务器下。
设置同在SQL SERVER 2000下差不多，配置好链接服务器后，您将得不到数据表的映射。但您可以使用SQL语句进行查询。
两种提供者的不同：
//以下摘自巧巧读书网（http://www.qqread.com/sqlserver/2006/11/f257985.html）
同一机器，同一数据源，同一结果，两者间还真有不少区别。
首先是速度（连续三次）：
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秒搞定。而且都只是第一次运行，相信如果多运行几次后，结果应该更好。别说，自家孩子真就不一样，别人的家的没法比。 同一机器，同一数据源，同一结果，两者间还真有不少区别。
首先是速度（连续三次）：
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秒搞定。而且都只是第一次运行，相信如果多运行几次后，结果应该更好。别说，自家孩子真就不一样，别人的家的没法比。