Oracle至Sql Server用DB Link查询缓慢原因之一

公司系统有一个每日同步进程，从A系统数据库（Oracle 11g）提取B系统数据库（Sql Server 2005）每天新增的数据，实现的方法为：在A数据库中建立物理视图，来通过DBlink引用B数据库中的数据源，A系统每天对该视图中的数据做提取。

进程跑了一年多没出问题，只是执行速度较慢，从最初的半个小时左右，到了最近的1个小时左右，再到最近的频频报错；

开始是认为数据量过大，看到网上有帖说 同样是建了物理视图，随着数据量增大出现了与我同样的错误，解决方法是，重建DBlink，需要注意细节将密码用“”引起来。照做后，第二天依然看到有报错；

于是将B数据库的数据转移，从200多W行清到了10W行，并检查了B中的索引，但无效果，依然很慢且有时报错；

模拟进程执行的代码，我在A中用DBlink查询B的前20条（rownum<=20）用了1.5秒，插入着20条用了10多秒，改成rownum<=60插入60条用时30多秒，基本确定是insert效率低下导致速度慢；同时 我也发现A表的唯一索引与B表不一致，插入条件中有not exists的判断，这也会影响insert效率。将A表索引与B表一致后，想到A数据库的数据量也随着时间增大，有几百W条，果断削掉了一半，又重建了索引。结果依然报错；

联想到之前有取消过进程，并且出现过两个进程同时运行，怀疑是有事务锁影响，经过清理后，正常运行了一两天，再次出现报错；

此时在PL SQL Developer登陆A查B的数据，有个奇怪的现象，前几十行可以较轻松的查出来，但若超过100行，软件都会卡住，偶尔不卡也会报错；但查询B另外一个表，没有卡顿，且几百行数据也可以轻松刷出。

最后经过Google得知这样一个细节，通过gateways创建DBlink到sqlserver,若有varchar(30)类型，getways会将其定义为varchar2(30)，经过转化后长度会变大，可能会超过长度，此时转换肯定也要消耗资源，于是把SQL Server中的varchar(20)改成了nvarchar(20)，一切都正常了。