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状态的的会话对应是事务才会被回滚。从而解除上面的阻塞。

 

 

总结

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

 

posted @ 2017-03-03 09:55  owen zeng  阅读(1001)  评论(5编辑  收藏  举报