我知道我的数据库上有很多阻塞,并且已尽力按供应商进行排序,因为此应用程序受他们支持并且尚未产生任何成功的结果。时不时地,我们遇到阻塞问题,这种阻塞变得如此严重,而且它们的设计如此糟糕,以至于整个门户都崩溃了,除非并且直到我杀死几个持有独占锁的 SPID(大部分)。
我已经使用 sp_blitzindex 快一年了,并且是 Brent Ozar 先生和团队提供的 First Responder Kit 的忠实粉丝。当我对该发生阻塞的数据库执行 sp_blitzindex 时,它显示 - “ Aggressive Under-Indexing: Total lock wait time > 5 minutes (row + page) with long average waits ” 优先级为 10。我检查了URL列和还检查了其他相关页面,但无法获得太多帮助。
我知道这里列出的表索引不足,需要创建更多索引,但是当我使用以下命令在表级别单独运行这些对象的 sp_blitzindex 时,需要创建更多索引:
EXEC dbo.sp_BlitzIndex @DatabaseName='db1', @SchemaName='sch', @TableName='tab1';
我根本没有得到任何缺失的索引详细信息。所有现有索引都被利用并且读取计数小于写入计数,此处突出显示的唯一问题在主键的“锁定等待”列中。
我不知道需要创建哪个列索引。我还检查了 sp_blitzlock 以查看是否可以收集更多信息,这将有所帮助,但是我看到的所有信息都存在很多死锁,并且列出了相同的对象,这些对象被认为是激进的索引不足。
还通过在此特定数据库中将排序顺序作为“读取”和“持续时间”传递来检查 sp_blitzcache 的输出,但没有丢失索引请求。有警告说“未参数化查询”和“未参数化查询,非 SARGables”,这些计划涉及不同的表集。
非常感谢任何帮助。
Version: Microsoft SQL Server 2014 (SP3) (KB4022619) - 12.0.6024.0 (X64) Sep 7 2018 01:37:51 Enterprise Edition: Core-based Licensing (64-bit) on Windows NT 6.3 (Build 9600: ) (Hypervisor)
免费单位
由于您使用的是First Responder Kit,因此我将坚持在我的示例中使用它来教您如何进一步诊断。
没有缺失索引?
为什么 SQL Server 在 DMV 或查询计划中没有任何缺失的索引请求?
首先,等待
使用
sp_BlitzFirst @SinceStartup = 1;
并查看您的等待统计信息。如果
LCK_
等待不在您列表的顶部(前 10 名左右),并且如果该Avg ms Per Wait
列没有显示超过 1-2 秒的LCK_
等待值,那么情况可能不会那么糟糕。我可能会将注意力转移到其他地方。修饰符
与其用于查看 Reads 或 Duration,不如
sp_BlitzCache
使用它查看以下内容:您可能会发现一次修改大量数据的查询。如果这样做,将它们更改为批量修改可以减少锁定开销。
这种方法的问题在于,当您查找它们时,它依赖于缓存中的执行计划。由于各种原因,它们可能不是。
由于您正在运行
sp_BlitzCache
,请注意警告汇总中的行(第二个输出);常见问题
长锁可能来自最终用户可能不会注意到的地方,例如索引维护。
如果这是源头,您可能需要考虑缩减执行维护的碎片级别(50-80%)、维护频率(每周或每月),或者根本不这样做,只更新统计信息(侵入性小得多,不易阻塞)。
寻找使用 的代码模式
BEGIN TRAN
,然后在提交之前做大量的工作。这需要您进行代码审查。这里没有捷径,这通常是您希望监控工具做的事情。寻找具有级联动作
sp_BlitzIndex
的外键。这些可能会导致大量的锁定。希望这可以帮助!