调查高 SQL 等待，特别是 LCK_M_U

Question

最近我一直在努力解决 SQL 服务器的性能问题，尽管我们已经修复了配置中的大量基本错误，但它的性能仍然很差。澄清这不是整体性能，而是相当频繁的超时（来自客户端应用程序）。 以前我曾将内存视为原因，但现在已解决，我们仍然得到相同的行为。

查看来自管理数据仓库的图表，我可以看到 LCK_M_U/X/IX 在用户遇到超时时导致了我们的大部分等待。我正在阅读的所有内容都表明我需要查看正在运行的查询和进程，但我还没有找到任何针对我可以理解的级别的内容。如下图所示，锁似乎尖峰，这与用户端的错误一致。是否有一个聪明的 DMV 或一些我可以解决的问题，以尝试找出正在运行的查询正在创建锁定？是否是通过跟踪来查找详细信息的情况？如果信息不清楚，任何指导都非常感谢和道歉。

Answer 1

锁往往会形成链，你总是最感兴趣的是链头的进程正在做什么。简单地查看锁等待时间可能会产生误导，因为许多进程可以等待很长时间（从而增加等待时间统计数据），但都被单个狗慢进程阻塞。您可能会看到一个合并点：因为每当高级锁（X 或 SCH_M）进入资源的等待队列时，授予的锁必须与所有当前的被授予者和所有挂起的等待者兼容，所有后续请求都排在这之后.

举个例子：假设你有一个查询在一个表上运行一个报告，假设它需要 5 分钟。它在表上持有 IS 锁。此 IS 兼容所有正常操作（读取和写入）。一个需要 SCH_M 的请求进来了。与 IS 不兼容，因此将他放入队列中。现在突然之间，桌子上的所有其他活动都进入了队列，因为每个请求、读取或写入都与此服务员不兼容。所以突然之间所有的锁定时间都激增了。5 分钟后，慢查询完成（用 DB 术语“耗尽”），SCH_M 被授予，它在 5 毫秒内完成其工作，其他所有人都可以自由继续。这只是一个（极端）示例，它不一定是 SCH_M。这个想法是等待时间并不能说明全部情况。

幸运的是，SQL Server 本身可以通过一个几乎不为人知的名为blocked process threshold. 混合阻塞进程报告和DDL 事件通知，您将获得一个完全自动化的解决方案。

有关示例，请参阅我在MS SQL Server 第三方事务阻塞监视工具上的回答。

另一个观察结果：您在 IX 上的等待时间为 22.30%。这意味着发生了对象级锁定。意图锁（IS、IX）是兼容的，因此 IX 被阻塞的事实表明有人获得了不兼容的对象级锁。扫描获得 S，或升级到 X的大更新。

Answer 2

从表中的 sp_WhoIsActive 收集数据是跟踪阻塞和锁定问题的好技术。

如果您想查看所涉及锁的更详细信息，可以使用@get_locks参数。或者，@get_task_info 和 @get_additional_info通常会捕获足够的信息来确定原因。

如果收集的输出不足以清楚地理解问题，请随时附加到您的问题。