为什么sleeping的会话会造成阻塞(2)
背景
客户反馈系统突然从11:10开始运行非常缓慢，在SQL专家云中看到大量的产生阻塞的活动会话，KILL掉阻塞的源头马上又出现新的源头，实在没有办法只能重启应用程序断开所有数据库连接才解决，请我们协助分析根本的原因。
现象
登录SQL专家云，进入趋势分析页面，下钻到11点钟内一个小时的数据，看到从11:12开始出现阻塞，越来越严重。
分析
状态为sleeping代表当前会话没有执行SQL请求，之所以造成阻塞是因为会话以前开启了一个或多个事务， 在事务中修改了一个或多个表的数据，会话对这些修改的数据行持有排他锁，从而阻塞其他会话对该表的操作。如果这种状态持续很长时间，很有可能是前端应用程序出现了异常，并且没有健壮的异常处理机制，出错后没有回滚以前打开的事务并关闭连接，导致阻塞一直存在。 前端应用程序出错原因主要有两种，一种是执行SQL语句时被阻塞等原因导致执行时间长并产生超时；一种是执行非数据库访问逻辑时因为某些原因出错了，例如转换数据类型失败、接收数据量太大导致内存溢出、访问别的接口报错等。
本着这个经验，对这些sleeping的会话进行回溯，发现这些会话在sleeping之前，都曾经被阻塞过很长时间，根据慢语句的特征判断是执行超时了。
而且这些会话都存在打开的事务，事务开始时间都在执行语句超时的时间之前。
通过对存储过程进行分析，发现里面在用TRY CATCH的方式处理事务，因此推断该方式无法捕获应用程序端的超时错误，导致事务和连接的泄露，因为存储过程比较复杂，下面用一个测试来模拟。
测试
首先创建一个存储过程，逻辑为先开始事务，然后依次对两个表进行UPDATE，通过TRY CATCH的方法处理事务。
CREATE PROCEDURE dbo.usp_test AS BEGIN TRAN BEGIN TRY UPDATE dbo.Table_2 WITH(ROWLOCK) SET a = 'wang' UPDATE dbo.Table_1 WITH(ROWLOCK) SET a = 'wang' END TRY BEGIN CATCH IF @@ERROR = 0 BEGIN GOTO succeed END ELSE BEGIN GOTO error END END CATCH succeed: COMMIT TRAN RETURN 1 error: ROLLBACK TRAN RETURN 0
新建一个查询，开始一个事务，然后执行UPDATE Table_1，不提交或者回滚事务，对表Table_1的排他锁一直存在， 用来模拟对表Table_1的锁定。
新建另一个查询，注意，执行超时值设置为30秒（默认是0，代表永不超时）。这个新建立的会话ID是56。
执行存储过程usp_test。updat dbo.Table_2很快执行完，在执行updat dbo.Table_1时产生阻塞，等待30秒后出现超时的报错。
新建一个查询，查看会话56的事务信息，可以看到存在一个打开的事务。
再通过sys.dm_tran_locks可以看到会话56还保持着对表Table_2和Table_1的意向排他锁以及Table_2上更改的两行数据的排他锁。此时在其他会话中对Table_2执行查询和修改，都被会话56阻塞。
总结：“超时”错误是应用程序端的异常，数据库驱动程序执行SQL语句时等待服务器端的响应，等待时间达到设置的阈值后发送一个终止执行的信号给服务器端并向上层应用程序抛出异常。服务器端接收到该信号后终止语句的执行，并不会报错，TRY CATCH是无法捕获的，因此无法执行到SUCCEED处的COMMIT或者ERROR处的ROLLBACK，导致了事务的泄露，该事务中的对表Table_2的排他锁一直持有，其他会话对表Table_2的操作会被阻塞，直到杀掉该会话。
解决
对于这类问题，根本的解决方法是修改应用程序，增加对于执行异常的捕获，检查是否存在事务并回滚，然后关闭数据库连接。
但是很多客户是购买软件厂商的产品，修改程序不容易实现或者周期很长。因此只能在数据库端进行补偿性的措施，就是配置一个自动查杀会话的作业，根据sleeping会话的特征定期KILL掉。也可以在SQL专家云中启用自动查杀会话的功能。
