现象 1

登录SQL专家云，进入趋势分析页面，下钻到11点钟内一个小时的数据，看到从11:12开始出现阻塞，越来越严重。

分析 2

状态为sleeping代表当前会话没有执行SQL请求，之所以造成阻塞是因为会话以前开启了一个或多个事务， 在事务中修改了一个或多个表的数据，会话对这些修改的数据行持有排他锁， 从 而阻塞其 他会话对该表的 操作。如果这种状态持续很长时间，很有可能是前端应用程序出现了异常，并且 没有健壮的异常处理机制，出错后没有回滚以前打开的事务并关闭连接，导致阻塞一直存在。 前端应用程序出错原因主要有两种，一种是执行SQL语句时被阻塞等原因导致执行时间长并产生超时；一种是执行非数据库访问逻辑时因为某些原因出错了，例如转换数据类型失败、接收数据量太大导致内存溢出、访问别的接口报错等。

本着这个经验，对这些sleeping的会话进行回溯，发现这些会话在sleeping之前，都曾经被阻塞过很长时间，根据慢语句的特征判断是执行超时了。

而且这些会话都存在打开的事务，事务开始时间都在执行 语句超时的时间之前。

通过对存储过程进行分析，发现里面在用 TRY CATCH的方式处理事务，因此推断该方式无法捕获应用程序端的超时错误，导致事务和连接的泄露，因为存储过程比较复杂，下面用一个测试来模拟

测试 3

CREATE PROCEDURE dbo.usp_testAS   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。

新建一个查询，查看会话56的事务信息，可以看到存在一个打开的事务。

再通过sys.dm_tran_locks可以看到会话56还保持着对表Table_2和Table_1的意向排他锁以及Table_2上 更改 的两行数据的排他锁。 此时在其他会话中 对 T a bl e _ 2 执 行 查 询和修改 ，都 被 会 话 5 6 阻 塞 。

总结： “超时”错误是应用程序端的异常，数据库驱动程序执行SQL语句时等待服务器端的响应，等待时间达到设置的阈值后发送一个终止执行的信号给服务器端并向上层应用程序抛出异常。服务器 端接收到该信号后终止语句的执行，并不会报错，TRY CATCH是无法捕获的 ，因此无法执行到 SUCCEED处的COMMIT或者 ERROR处的ROLLBACK，导致了事务的泄露，该事务中的对表Table_2的排他锁一直持有，其他会话对表Table_2的操作会被阻塞，直到杀掉该会话。

解决 4

但是很多客户是购买软件厂商的产品，修改程序不容易实现或者周期很长。因此只能在数据库端进行补偿性的措施，就是配置一个自动查杀会话的作业，根据sleeping会话的特征定期KILL掉。也可以在SQL专家云中启用自动查杀会话的功能。

北京格瑞趋势科技有限公司是聚焦于数据服务的高新技术企业，成立于2008年，创始团队及核心技术人员来自微软和雅虎。微软数据平台金牌合作伙伴，卫宁健康数据平台战略合作伙伴。通过产品+服务双轮驱动的业务模式，14年间累计服务4000+客户，覆盖互联网、市政、交通、电信、医疗、教育、电力、制造业等各个领域。