两天前，我们在 Reporting Services 中的一份报告开始需要更长的时间才能生成。它的生成时间从 4 秒增加到 2 分钟。
调查发现：
存储过程运行时间为 1 秒，查询计划可接受
报告在 Visual Studio 的开发机器上按预期在 4 秒内运行
一旦报告发布到生产服务器，它的运行速度就会慢得多。
使用活动监视器显示报告被锁“LCK_M_S”阻止
我打开跟踪 1222 来检查死锁，但没有报告死锁。
关于发生的事情，我能获得的唯一信息是 ReportServer 数据库的“按锁计数排列的顶级事务”报告。它列出了 ReportServerTempDB 上的锁定事务。
这种模式在受影响的报告中可重复两天，您将运行它，在活动监视器中查看阻止过程，并且报告需要更长的 2 分钟。
就在我们进一步研究问题时，它突然消失了，团队中没有人改变任何东西，代码或数据，现在报告在 3-4 秒内恢复运行。
发生了什么？
在没有开发人员干预的情况下，重复运行 2 分钟并运行了 2-3 天的报告突然在 4 秒内恢复运行，并且在活动监视器中看到的阻塞过程消失了？
LCK_M_S 是阻塞问题而不是死锁问题。所以你只是在等待别的东西。您需要确定是什么进程阻止了您。
因此，“它突然消失了”，因为该块要么完成，要么失败并回滚。这个是正常的。从您的笔记或您的角度来看，听起来异常的是块的长度。
除了查找阻塞进程之外，您还可以考虑使用不同的事务隔离级别。例如，虽然不是没有自己的问题，但您可能会考虑为您的报告使用“READ COMMITTED SNAPSHOT”或“SNAPSHOT”隔离级别。这将允许它在事务开始时读取数据，并避免大多数阻塞情况。