今天遇到一个很奇怪的情况，发现一个会话异常，这个会话只是在执行一个简单的存储过程，里面使用了链接服务器（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线程）），但是重启数据库是一个很麻烦的事情。 所以这个僵尸会话就一直存在数据库里面,对于我这个有强迫症的人,看着它的存在,总想干掉它. 确实是个折磨人的事情.
