最近给客户做优化时,有几个客户都存在.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状态的的会话对应是事务才会被回滚。从而解除上面的阻塞。
在解决实际问题时,在知道解决办法后,还有很多技术细节,这是我们必须要关注的
新闻热点
疑难解答