SQL Server网络断连后如何重连并监控长时间运行的查询进程

1. 是否可以连接到SQL Server中正在运行的特定进程？ #

SQL Server原生不支持对已断开客户端连接的孤立运行进程（SPID）做附着重连。
会话的执行上下文、游标状态、事务状态是和最初发起请求的连接句柄强绑定的，当你本地客户端收到传输层超时报错、原连接彻底释放后，没有任何官方机制可以将新的客户端连接绑定到这个已经在服务器端运行的SPID上，也就无法恢复原会话的输出、继续接收打印信息或者操控会话内的游标、循环逻辑。你遇到的Msg 121信号量超时是纯客户端-服务器链路的网络故障，只要服务器端会话超时阈值没触发，进程会独立在服务器端继续执行，和原客户端是否在线无关。

2. 若支持重连，可使用哪些客户端工具？ #

不存在能实现该场景下重连接管的官方客户端工具，无论是SSMS、Windows下的sqlcmd、Linux下的mssql-cli/sqlcmd，还是基于JDBC/ODBC驱动编写的自定义代码，都无法接管已经断开原客户端连接的孤立SPID。
要注意区分工具自带的网络闪断重试能力：这类重试仅在原TCP连接未被系统释放、会话句柄还保留在客户端侧时生效，你当前已经收到明确的Level 20传输层错误，原连接已经完全失效，这类重试机制只会建立全新的连接（生成新的SPID），无法关联到已经跑了7天的旧进程。

3. 若无法重连，监控进程执行状态的方法 #

可以通过以下无侵入的方式监控，避免影响正在运行的进程：

• 轮询系统视图跟踪进程存活与运行状态：定期查询sys.dm_exec_sessions、sys.dm_exec_requests和你已经在用的sys.sysprocesses，记录对应SPID的cpu、physical_io、logical_reads计数值：
  • 如果计数值持续稳定增长，说明进程还在正常执行更新逻辑；
  • 如果SPID从系统视图中消失，立刻检查SQL Server错误日志，如果没有事务回滚相关报错，同时你通过脏读观察到的目标表最终数据符合预期，说明进程已经顺利执行完成；如果日志中存在回滚记录，说明进程异常终止触发了回滚。
  • 如果计数值长时间（建议以30分钟为阈值，匹配你每次更新1行的执行速度）不再变化，同时open_tran值保持不变，可查询sys.dm_tran_locks确认进程是否被阻塞。
• 结合业务逻辑做进度校验：因为当前进程已经处理到最后一个参数，每次仅更新1行，你可以定期统计目标表中符合最后一个参数筛选条件、已更新到预期状态的记录数，当记录数达到预期总量且不再变化时，就可以判定内层更新循环已经执行完毕。
• 仅使用DBCC INPUTBUFFER(SPID)查看进程当前执行的语句，不要对该SPID运行其他调试、跟踪类命令，避免引入额外开销干扰执行。

4. 场景处理建议 #

• 优先等待进程自行执行完成：当前进程CPU计数持续增长，且已经到最后一个参数的收尾阶段，贸然执行KILL指令终止进程会触发事务回滚，回滚耗时可能长达数天，之前7天的执行进度会全部作废。
• 你已经通过脏读备份了已生成结果的操作是正确的，后续如果出现进程异常终止的情况，不需要从头跑全量逻辑，仅需要基于备份数据补跑最后一个参数的剩余更新即可。
• 后续执行这类超长周期任务时，不要通过本地客户端直连发起：优先通过SQL Server Agent代理作业执行，作业运行在服务器端，完全不受本地网络中断、本地设备关机的影响，还可以配置日志输出记录每一步的执行进度；如果是Linux环境下的SQL Server，可以在服务器侧通过sqlcmd配合tmux/screen会话执行，避免网络波动影响长任务。
• 长周期任务脚本建议增加独立的进度日志表，每完成一个参数处理、每跑完固定次数的迭代，就往日志表插入一条带时间戳的进度记录，不需要依赖脏读、系统视图猜测执行进度。
• 如果后续监控发现进程长时间无响应、既不推进数据更新也不结束，再考虑终止进程，用之前备份的脏读数据补跑剩余逻辑，避免无意义的资源占用。

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