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

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

KILL129WITHSTATUSONLY;

SPID129:正在进行事务回滚。估计回滚已完成:0%。估计剩余时间:0秒。

如下所示，这个会话的start_time(Timestampwhentherequestarrived.Isnotnullable.)为2016-10-1802:17:58.210，到现在2016-10-1916:02:30.173已经有几十个小时了，我kill会话的时间点为2016-10-1912：00:01。







可以看到它的等待类型是OLEDB等待（图一），也就是说等待链接服务器所指的服务器返回结果。另外这个事务的transaction_type为2，意味这只是一个Read-onlytransaction（避免别人误解，这是一个证据），transaction_state为2，表示事务处于活动状态（Thetransactionisactive）。事务出现的这个时间点引起了我的注意，因为链接服务器所指向的这台服务器出现宕机（参考链接VmWare平台WindowsServer2012无响应宕机），刚好是那台服务器虚拟机出现宕机时候，重启的时间点前面一点（那台服务器凌晨1点多宕机，2：22AM的时候重启的）。从DPA监控工具也能看到确实是那个点出现的。如下所示：



这种分布式查询，由于LinkedServer所指的服务器出现异常（例如宕机），这边的会话进程一直在等待其返回结果，但是LinkedServer所指服务器由于异常永远都无法给这个会话进程反馈任何结果，就出现了这种情况，不过有点奇怪的是，这种情况无法通过KILL会话来结束。只能通过重启服务器来解决问题，也不能通过Kill进程解决（因为SQLServer是单进程多线程架构，不像ORACLE那种多进程架构，可以从操作系统层面杀掉进程或线程（Windows平台，Oracle提供了一个工具ORAKILLutility可以Kill线程）），但是重启数据库是一个很麻烦的事情。所以这个僵尸会话就一直存在数据库里面,对于我这个有强迫症的人,看着它的存在,总想干掉它.确实是个折磨人的事情.