佛山品牌网站建设,wordpress __(),建筑人才网职位邀约是什么意思,自己建设网站怎么盈利背景客户反馈系统突然从11:10开始运行非常缓慢#xff0c;在SQL专家云中看到大量的产生阻塞的活动会话#xff0c;KILL掉阻塞的源头马上又出现新的源头#xff0c;实在没有办法只能重启应用程序断开所有数据库连接才解决#xff0c;请我们协助分析根本的原因。现象登录SQL专…背景客户反馈系统突然从11:10开始运行非常缓慢在SQL专家云中看到大量的产生阻塞的活动会话KILL掉阻塞的源头马上又出现新的源头实在没有办法只能重启应用程序断开所有数据库连接才解决请我们协助分析根本的原因。现象登录SQL专家云进入趋势分析页面下钻到11点钟内一个小时的数据看到从11:12开始出现阻塞越来越严重。进入活动会话原始数据页面看到不同时间点的阻塞源头会话是不同的但都是同一类的现象阻塞源头会话的状态是sleeping被阻塞的会话都在对同一个表执行UPDATE语句。分析状态为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 wangUPDATE dbo.Table_1 WITH(ROWLOCK) SET a wangEND TRY BEGIN CATCH IF ERROR 0 BEGIN GOTO succeed END ELSE BEGIN GOTO error END END CATCHsucceed: 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专家云中启用自动查杀会话的功能。
