这种结果行数不匹配的情况确实挺闹心的——明明是同一段SQL，换个执行方式就出问题，我帮你梳理几个常见的排查方向：

1. 字符集与编码不匹配导致去重异常 #

DISTINCT是最容易因为字符差异出问题的地方：

• 检查Oracle端的NLS_CHARACTERSET和SQL Server数据库的排序规则，确保两者对字符的识别一致。比如Oracle用AL32UTF8，SQL Server却用SQL_Latin1_General_CP1_CI_AS，可能会导致某些特殊字符被误判为相同值。
• 留意字段长度：Oracle的VARCHAR2(n)和SQL Server的VARCHAR(n)定义逻辑不同（前者是字节数，后者是字符数），如果字段值被截断，原本不同的数据会被当成相同值去重，直接影响行数。

2. 执行逻辑的“跨端”差异 #

当用EXECUTE ... AT时，SQL Server可能会把部分查询逻辑拉到本地处理（比如DISTINCT），而不是完全在Oracle端执行。可以试试把这段SQL包装成Oracle的存储过程，再通过链接服务器调用，确保整个查询逻辑都在Oracle端运行：

-- 在Oracle创建存储过程
CREATE OR REPLACE PROCEDURE get_distinct_pidm
AS
BEGIN
  SELECT DISTINCT saradap_pidm AS PIDM, saradap_term_code_... FROM ...;
END;
/

-- 在SQL Server调用
EXECUTE ('BEGIN get_distinct_pidm; END;') AT [LINKEDSERVER];

如果这样结果和Oracle本地一致，说明之前的执行逻辑被SQL Server拆分处理了。

3. 变量类型与SQL拼接问题 #

你用的是varchar(max)存储SQL语句，建议改成nvarchar(max)试试——Oracle对Unicode字符的处理和SQL Server的varchar可能存在隐式转换，导致SQL语句在传递过程中出现细微错误。另外，一定要打印出生成的SQL语句对比：

DECLARE @strSQL nvarchar(max) 
SET @strSQL = N'select distinct saradap_pidm as PIDM ,saradap_term_code_...'
PRINT @strSQL -- 把输出的SQL复制到Oracle直接执行
EXECUTE (@strSQL) AT [LINKEDSERVER]

如果打印的SQL在Oracle跑结果正常，但EXECUTE跑出来不一样，那问题出在链接服务器配置；如果打印的SQL在Oracle跑结果也不对，那就是拼接SQL时出了语法或逻辑错误。

4. 链接服务器的配置与权限问题 #

• 检查链接服务器的RPC和RPC Out是否启用（在SSMS的链接服务器属性→服务器选项里），这会影响跨服务器的执行逻辑。
• 确认链接服务器使用的登录账号，和你直接在Oracle登录的账号拥有完全相同的权限——如果权限不同，能看到的数据范围不一样，行数自然会有差异。
• 查看OLE DB提供者的属性（比如Oracle的OraOLEDB.Oracle），有没有设置FETCHSIZE等参数，可能会影响数据返回的完整性。

内容的提问来源于stack exchange，提问作者user3908206