SQL Server 2008 SP3从链接服务器插入200K行时频繁触发严重错误求助

碰到这种问题我太熟悉了，结合你描述的场景——插入200K行几乎必报错、用TOP(10)就正常、关联本地表的SELECT偶尔触发错误，而且已经排除了全量取数和数据库损坏的可能，这大概率和分布式查询的资源瓶颈、执行计划不合理或者链接服务器配置限制有关。给你几个实用的排查和解决方向：

1. 分批插入，别一次性扛太大压力 #

一次性插入200K行很容易把内存、网络或者分布式事务的资源耗干，拆分小批次执行能有效降低风险。试试这个脚本：

DECLARE @BatchSize INT = 10000; -- 可以根据服务器性能调整批次大小
DECLARE @RowCount INT = 1;

WHILE @RowCount > 0
BEGIN
    INSERT INTO 你的本地表(列名1, 列名2, ...)
    SELECT TOP(@BatchSize) 列名1, 列名2, ...
    FROM 链接服务器名.远程数据库.dbo.远程表
    WHERE 主键列 NOT IN (SELECT 主键列 FROM 你的本地表) -- 用主键避免重复插入
    
    SET @RowCount = @@ROWCOUNT;
    WAITFOR DELAY '00:00:01'; -- 给服务器留1秒缓冲，可选
END

小批次操作不仅降低资源占用，就算某一批次出错，也只需要重新跑这一批，不用从头再来。

2. 调整链接服务器的超时和分布式事务配置 #

• 先检查远程查询超时设置：默认的远程查询超时是600秒，大数量数据传输可能不够用。执行下面的命令调大（比如设为3600秒，也就是1小时）：

sp_configure 'remote query timeout', 3600;
RECONFIGURE;

• 另外，关联本地表时SQL Server可能自动启用分布式事务，得确保两台服务器的**MSDTC（分布式事务协调器）**是正常运行的，而且配置允许跨服务器事务。你可以在Windows服务里找到“Distributed Transaction Coordinator”，看看状态是不是“正在运行”，如果远程服务器是其他机器，还要检查防火墙是否开放了MSDTC的端口。

3. 用OPENQUERY强制远程先处理数据 #

有时候SQL Server的优化器会犯傻——把本地表的数据推送到远程服务器去关联，导致大量数据在网络上传输，直接撑爆资源。这时候用OPENQUERY强制远程服务器先执行查询，只返回需要的结果：

INSERT INTO 你的本地表(列名1, 列名2, ...)
SELECT *
FROM OPENQUERY(链接服务器名, 'SELECT 列名1, 列名2, ... FROM 远程数据库.dbo.远程表 WHERE 过滤条件') -- 把能在远程过滤的条件都加上
-- 如果需要关联本地表，尽量把关联逻辑转化为远程过滤后再匹配本地

这样一来，远程服务器先把数据筛选好，再传回来，网络传输量会小很多，出错概率自然就降了。

4. 更新统计信息，检查索引 #

旧的统计信息会让优化器生成糟糕的执行计划，导致资源浪费：

• 更新本地表的统计信息：

UPDATE STATISTICS 你的本地表;

• 如果有权限，让远程数据库的管理员也更新下远程表的统计信息，或者自己执行：

EXEC 链接服务器名.远程数据库.dbo.sp_updatestats;

另外，本地表如果有很多非聚集索引，插入时会额外消耗大量资源。可以先禁用这些索引，插入完成后再重建：

-- 禁用所有非聚集索引
ALTER INDEX ALL ON 你的本地表 DISABLE;

-- 执行插入操作

-- 重建索引
ALTER INDEX ALL ON 你的本地表 REBUILD;

5. 检查网络和驱动版本 #

SQL Server 2008 SP3毕竟是比较老的版本，链接服务器用的ODBC驱动如果太旧，可能存在大数量数据传输的bug。你可以：

• 检查链接服务器用的ODBC驱动版本，尽量更新到对应版本的最新驱动；
• 测试两台服务器之间的网络，看看有没有延迟过高或者丢包的情况——网络不稳定也经常导致这种“严重错误”。

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