我们可以使用同义词在SQL Server 2005下连接Oracle来实时访问Oracle数据库，但是如果Oracle中的表数据流较大则会影响应用系统的性能，于是应采用数据库作业每天定时执行：

drop table abc–删除旧表  　　go  　　select * into abc

　　from aaa–aaa为同义词这样就可以把Oracle中的数据同步到本地的SQL Server数据库中。从而解决跨实例查询的性能问题。

　　使用这样的方式半年了都没有发现有什么问题，可是最近却发现了一个现象，在Oracle中有一个表aaa，其中一个字段BILL NUMBER类型(未指定精度和小数数据位)，对于这种类型，SQL Server2005中同步的表abc中却被定义为nvarchar(384)的类型!?明明是一个数字类型为什么SQL Server会将其转换为字符串类型呢?

　　若只是数据类型改变了倒没有什么，我应用程序在处理时转换一下就是了，但是更奇怪的是其中某些数据在Oracle中查出来是12.34567，但是在SQL Server 2005中查出来却成了12.345670543574563452346547546234234543656434…，后面是几十位的小数，简直神奇了!有一行数据在Oracle中是1，而在SQL Server中查出来是0.99999999999999999999999999999999…但是这种数据也很少发生，在数万条数据中可以找到2-3条这种几十位小数的数据。

　　正是这种数据的存在使得应用程序有时算出来的结果和Oracle那边的系统算出来的结果无法匹配。

　　经测试，如果Oracle中指定了NUMBER类型的精度和小数位数比如NUMBER(15)这样SQL Server将可以自动将其转换为numeric(15,0)类型。

　　由于NUMBER类型可以表示1.0 * 10(-130) —— 9.9…9 * 10(125) {38个9后边带88个0} 之间的数据，精确度可以达到小数点后38位小数，由于SQL Server中没有如此高精度的数据类型，所以在没有指定NUMBER精度和小数位的情况下SQL Server会将其转换为字符串类型以满足长度和精度的需要。

　　解决办法就是将SQL Server中同步表的nvarchar(384)类型修改为decimal类型或numeric类型，同步时不删除表，只是清除表内容，然后插入数据。同步SQL为：

truncate TABLE abc–清除表abc内容  　　go  　　insert into abc–将同义词aaa中的数据插入abc表  　　select *