SQL Server会话KILL不掉,一直处于KILLED /ROLLBACK状态情形浅析
2016-10-20 17:44 潇湘隐者 阅读(14990) 评论(14) 编辑 收藏 举报今天遇到一个很奇怪的情况,发现一个会话异常,这个会话只是在执行一个简单的存储过程,里面使用了链接服务器(Linked Server)查询另外一台服务器数据(存储过程里面没有任何显性事务、UPDATE、DELETE操作,只有几个简单的SELECT查询,其中有两个查询使用了链接服务器Linked Server,由于生产环境,不好贴出SQL语句),在DPA监控工具里面,发现该会话引起了非常长的OLEDB等待时间,手工执行测试,发现并不耗费很长时间,KILL该会话后, 回滚状态已完成一直是0%, 估计剩余时间也一直是0秒。如下截图所示:
KILL 129 WITH STATUSONLY;
SPID 129: 正在进行事务回滚。估计回滚已完成: 0%。估计剩余时间: 0 秒。
如下所示,这个会话的start_time(Timestamp when the request arrived. Is not nullable.)为2016-10-18 02:17:58.210,到现在2016-10-19 16:02:30.173已经有几十个小时了,我kill会话的时间点为2016-10-19 12:00:01。
可以看到它的等待类型是OLEDB等待(图一),也就是说等待链接服务器所指的服务器返回结果。另外这个事务的transaction_type为2,意味这只是一个Read-only transaction(避免别人误解,这是一个证据),transaction_state为2,表示事务处于活动状态(The transaction is active)。事务出现的这个时间点引起了我的注意,因为链接服务器所指向的这台服务器出现宕机(参考链接VmWare平台Windows Server 2012 无响应宕机),刚好是那台服务器虚拟机出现宕机时候,重启的时间点前面一点(那台服务器凌晨1点多宕机,2:22AM的时候重启的)。从DPA监控工具也能看到确实是那个点出现的。如下所示:
这种分布式查询,由于Linked Server所指的服务器出现异常(例如宕机),这边的会话进程一直在等待其返回结果,但是Linked Server所指服务器由于异常永远都无法给这个会话进程反馈任何结果,就出现了这种情况,不过有点奇怪的是,这种情况无法通过KILL会话来结束。 只能通过重启服务器来解决问题, 也不能通过Kill进程解决(因为SQL Server是单进程多线程架构,不像ORACLE那种多进程架构,可以从操作系统层面杀掉进程或线程(Windows平台,Oracle提供了一个工具ORAKILL utility 可以Kill线程)),但是重启数据库是一个很麻烦的事情。 所以这个僵尸会话就一直存在数据库里面,对于我这个有强迫症的人,看着它的存在,总想干掉它. 确实是个折磨人的事情.

· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· C++代码改造为UTF-8编码问题的总结
· DeepSeek 解答了困扰我五年的技术问题
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 清华大学推出第四讲使用 DeepSeek + DeepResearch 让科研像聊天一样简单!
· 实操Deepseek接入个人知识库
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
2014-10-20 shell脚本执行时报"bad interpreter: Text file busy"的解决方法
2013-10-20 [翻译]当分发数据库增长到25G时如何解决
2009-10-20 设计模式——单例模式