我确实很难找到我们遇到的一些障碍。
根阻止SPID的状态为“正在休眠”,cmd为“正在等待命令”,并且sqltext
为SET TRANSACTION ISOLATION LEVEL READ COMMITTED
。
当我查看“按阻塞的交易计数列出的最高交易”报告时,阻塞的SQL语句为“-”。
我已经在SQL上执行了跟踪,并且当阻塞发生时是在跟踪根阻塞SPID,但它并没有真正引导我到任何地方。最后一个trace语句与sqltext
上面的相同SET TRANSACTION ISOLATION LEVEL READ COMMITTED
。
我检查了所有可以找到的相关存储过程,以确保它们具有TRY / CATCH BEGIN TRAN / COMMIT TRAN / ROLLBACK TRAN语句(我们将存储过程用于所有内容,因此没有独立的语句在运行)。该问题在过去的24小时内才刚刚开始发生,并且没有人声称对系统进行了任何更改。
解决方案:我们很少使用的存储过程之一有一个插入错误(列数不匹配),但是我们仍然对正在发生的事情感到困惑。
查看所有跟踪信息时,有时会列出该存储过程的EXEC语句,但绝不会在阻塞SPID上发生BLOCK之前。看来,当它开始阻塞时,跟踪并没有记录它(或其中的任何一条语句)的执行情况。但是,还有其他时间跟踪确实记录了它的执行并且没有发生阻塞。
存储过程错误报告来自用户,我能够在跟踪中找到多个EXEC语句并在SSMS中运行它们。当我运行它们时,我们没有任何阻塞发生或挂起的情况。它们按预期运行(错误后触发catch块并回滚了事务)。解决了存储过程的问题后,我们再也没有看到此问题。