SQL Server会话KILL不掉，一直处于KILLED /ROLLBACK状态情形浅析[转]

本文将为您描述SQL Server会话KILL不掉，一直处于KILLED /ROLLBACK状态情形浅析,教程操做方法:

今天遇到一个很奇怪的状况，发现一个会话异常，这个会话只是在执行一个简单的存储过程，里面使用了连接服务器（Linked Server）查询另一台服务器数据（存储过程里面没有任何显性事务、UPDATE、DELETE操做，只有几个简单的SELECT查询，其中有两个查询使用了连接服务器Linked Server，因为生产环境，很差贴出SQL语句），在DPA监控工具里面，发现该会话引发了很是长的OLEDB等待时间，手工执行测试，发现并不耗费很长时间，KILL该会话后， 回滚状态已完成一直是0%， 估计剩余时间也一直是0秒。以下截图所示：

?

code

1	KILL 129 WITH STATUSONLY;

?

code

1

?

code

1	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线程）），可是重启数据库是一个很麻烦的事情。 因此这个僵尸会话就一直存在数据库里面,对于我这个有强迫症的人,看着它的存在,总想干掉它. 确实是个折磨人的事情.这篇SQL Server教程是否对您有用呢?