Sleeping会话导致阻塞原理（下）

背景

最近给客户做优化时，有几个客户都存在.SLEEPING 会话中开启了事务，导致的大量阻塞，从而产生严重的性能问题。虽然在之前的文章我分享了Sleeping会话导致阻塞原理（上） 。说明了什么是Sleeping会话，以及他可能导致的问题。但是对如何解决问题，给出的方案，还是太简单了，没有给出解决的细节。本文将对这些细节进行说明。希望大家面对类似问题时更容易下手

下面分享2个案例，分别针对针对问题来着存储过程 和 程序 中的情况。

存储过程

以下是某医药公司的案例截图：

从图中可以看到，230 处于SLEEPING 状态并且产生了大量的阻塞。查看子语句可以知道230运行的是一个存储过程。

问题就在于：在这个存储过程中，开启事务（如下图所示），并且运行到后面某个语句时出错了（可能是超时，或者其他错误）。但是开启的事务并没有回滚.如下图

有的同学，可能知道，在存储过程中 加入tray catch ，出错时回滚事务。这个解决办法并不彻底。对应有些错误是无法捕捉，对应这种情况，，我们可以在存储过程中直接加上：SET XACT_ABORT ON 。当存储过程执行时发生问题时，会自动回滚所有事务，从而避免了阻塞。

程序

这是某制造行业的财务的案例截图：

查看子语句，和父语句都是单独的一个查询，说明3185 开启的事务来着 程序0

对应这种情况，只能修改程序。因为客户的代码不好分享，下面是我自己写的测试程序代码：

在修改时有几个细节需要注意：

1.在代码中加入TRY CATCH。

2.在CATHC 中必须使用close，dispose 来关闭连接，当然使用了using也是可以的
3.程序建立了新的连接，并执行了查询。此时会出现 sp_reset_connection事件，此时，事务会被回滚。注意 。两次建立连接的connectsting.就是连接字符串必须完全一致。多个；都不可以。

只有满足上面3个条件，，sleeping状态的的会话对应是事务才会被回滚。从而解除上面的阻塞。

总结

在解决实际问题时，在知道解决办法后，还有很多技术细节，这是我们必须要关注的