链接服务器查询导致的阻塞

z_cloud_for_SQL 2023-01-29

453

背景

客户反馈数据库在上午10点时出现严重阻塞，阻塞源头会话在等待OLEDB，没有见过这个等待类型，请我们协助分析。

现象

登录SQL专家云，进入趋势分析，下钻到10点钟的活动会话，看到发生了两次严重的阻塞。

转到活动会话原始数据，看到阻塞的源头是会话331，正在执行UPDATE语句，阻塞了其它会话对表的更新和查询。

该会话执行了4分32秒，阻塞也持续了这么长时间，执行完后阻塞消失。

查看会话331不同时间点的活动会话，看到等待类型都是OLEDB，等待资源都是8.56（链接服务器目标实例）上的会话589。

、

分析

会话331对表执行UPDATE操作，阻塞其它会话对该表的写入和查询，这是正常的，也是好理解的。分析的重点是为什么执行时间这么长，而且全部都是链接服务器的等待（OLEDB）。

下载并打开执行计划，看到各表之间使用嵌套循环来关联。嵌套循环联接也称为嵌套迭代，它将一个联接输入用作外部输入表（显示为图形执行计划中的顶端输入），将另一个联接输入用作内部（底端）输入表。外部循环逐行处理外部输入表。内部循环会针对每个外部行执行，在内部输入表中搜索匹配行。因此推断链接服务器查询循环次数太多导致执行时间长。关于嵌套循环联接和其他的联接方式参考官方文档：https://docs.microsoft.com/zh-cn/sql/relational-databases/performance/joins?view=sql-server-ver16。

在链接服务器的目标端8.56中，查看会话589在不同采集时间点的活动会话，看到该会话的请求开始时间、最后请求开始时间、最后请求结束时间三个数据是变化的，执行的SQL语句是一样的，说明在循环执行同一查询语句。粗略计算执行了3000次左右，从而验证推断是正确的。

解决

修改存储过程，先把链接服务器查询返回结果保存在临时表中，然后在UPDATE语句中关联该临时表，这样只会有一次链接服务器查询，修改完后执行时间从4分30秒下降到4秒。

总结

客户反馈这个语句以前运行的很快，解释是以前的执行计划使用的是合并联接或者哈希联接，这样对链接服务器查询只有一次。随着表数据量、统计信息等指标的变化，执行计划发生了变更，认为使用嵌套循环关联更合理，但是真正执行的时候却适得其反。从根源上说还是SQL语句写法的问题，给了SQL Server多种选择。

链接服务器的查询要跨越网络，响应时间是毫秒甚至是秒级的，如果交互次数太多就会导致执行时间指数级的增加。不能把它当本地查询一样使用，使用时一定要仔细分析执行计划。

北京格瑞趋势科技有限公司是聚焦于数据服务的高新技术企业，成立于2008年，创始团队及核心技术人员来自微软和雅虎。微软数据平台金牌合作伙伴，卫宁健康数据平台战略合作伙伴。通过产品+服务双轮驱动的业务模式，14年间累计服务4000+客户，覆盖互联网、市政、交通、电信、医疗、教育、电力、制造业等各个领域。