SQL Server 2019 CU13中sys.sp_reset_connection运行过长致链接服务器超时

1. 连通性报错根因 #

你遇到的连接报错本质是SQL1实例连接池耗尽导致的连接拒绝：
sys.sp_reset_connection是连接池复用连接时触发的系统存储过程，用于重置会话上下文。当该存储过程执行时间长达数分钟时，已经被客户端释放回连接池的连接实际仍处于占用状态，连接池可用连接被快速耗尽。后续来自SQL100~SQL200的链接服务器连接请求无法获取可用连接，等待超时后SQL1的TCP网络层主动重置未完成的连接握手，就会返回你遇到的两条报错。

2. sys.sp_reset_connection运行时间过长的常见原因 #

• 存在长时间未提交/回滚的大事务：sp_reset_connection需要回滚当前连接残留的未完成事务，事务越大、涉及修改的数据量越多，回滚耗时越长
• tempdb资源争用：sp_reset_connection需要清理当前会话在tempdb中创建的临时表、表变量、临时存储过程等对象，当tempdb数据文件配置不合理、存在大量IO瓶颈或临时对象堆积时，清理步骤会出现长时间阻塞
• 实例级锁等待：sp_reset_connection执行时需要获取的元数据锁、事务锁被其他长时间运行的查询/未提交事务持有，导致执行阻塞
• 2019 CU13版本已知缺陷：该版本存在特定场景下连接复用触发的sp_reset_connection死锁、统计信息更新阻塞问题，该问题在后续CU补丁中已被修复
• 分布式上下文残留：如果复用的连接之前执行过跨实例的分布式查询，未清理的分布式事务上下文会大幅提升sp_reset_connection的重置工作量

3. 优化方案 #

• 先清理异常活跃事务：执行DBCC OPENTRAN()查询实例上最久的活跃事务，定位到异常会话后手动终止，快速释放占用的连接资源
• 优化tempdb配置：按照逻辑CPU个数配置tempdb数据文件（逻辑CPU≤8时数据文件个数等于CPU数，超过8个后每新增4个逻辑CPU新增1个数据文件，上限不超过24个），所有数据文件设置相同初始大小、相同固定步长的自动增长（禁用百分比增长，建议单次增长1~2GB），将tempdb部署在SSD存储上降低IO延迟
• 修复版本缺陷：将SQL Server 2019升级到最新CU补丁，微软在后续补丁中已修复所有已知的sp_reset_connection异常卡顿问题
• 调整链接服务器配置：在SQL1的链接服务器属性中开启「支持分布式事务升级」选项，同时将连接超时参数从默认15s调整为30s，避免短时间频繁重试加剧连接池耗尽问题
• 调整连接池配置：如果上层应用使用ADO.NET等框架的连接池，可将最大连接数上调20%，保持默认开启的Connection Reset参数即可，不要手动关闭该参数，否则会出现会话上下文污染的问题

关联报错信息：
TCP Provider: An existing connection was forcibly closed by the remote host.
OLE DB provider "SQLNCLI11" for linked server "SQL1" returned message "Client unable to establish connection"

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