SQL Server 2008-R2 数据库上的大量短期阻塞

Question

寻求专家就短期封锁提供建议，我们现在已经看到了近一周的时间。

DB 是 15 TB，而我们有很多阻塞的这个表 B - 几乎有 300 个是 2 TB。

在使用 sp_whoisactive 时，我看到查询在 3-4 秒的较短部分内被阻塞，有些在 9-10 秒内被阻塞，但由于这些查询几乎一整天都在连接超过 2-3 千个，这会导致应用程序中出现大量错误。

故障排除：

• 更新了 NC 指数的统计数据，我们只有一个 NC 和一个 C 指数。
• 通过哨兵检查我们可以看到，这些被阻塞的语句都是上面提到的那个表的插入语句。

以下是一些指标：

1. 等待过去 3-4 小时的统计数据，直到阻塞为止
   • PAGELATCH_EX --> 51.1 % 总等待 730 513 153.5
   • PAGELATCH_SH --> 23 % 总等待 343 538 769.7
   • THREADPOOL --> 18 % 总等待时间 257 222 894.4
2. 平均批次/秒：8612.6
3. CPU 和内存 --> 远低于阈值，因为我们有 256 个逻辑处理器和 612 GB RAM
4. 检查点页数/秒 --> 1706
5. 懒惰写入 --> 0
6. 日志刷新/秒 1844.4
7. 事务/秒 9074

结果根据 david 的查询：下面的 Note@ 是在我们进行节点故障转移后 15 分钟运行的

 wait_type  wait_time_ms_per_sec
PAGELATCH_EX    733024.4
PAGELATCH_SH    328846.4
CPU_USED    7131.4
WRITELOG    6484.4
DBMIRROR_EVENTS_QUEUE   4973.6
DBMIRRORING_CMD 1456.6
OLEDB   990.2
TRACEWRITE  984.2
SOS_SCHEDULER_YIELD 280.6
THREADPOOL  254
ASYNC_NETWORK_IO    45.4
LATCH_EX    9.4
PAGEIOLATCH_EX  7.6
PREEMPTIVE_OS_GETPROCADDRESS    3.4
MSQL_XP 3.2
DBMIRROR_SEND   1.4
PREEMPTIVE_OS_DELETESECURITYCONTEXT 1
PAGELATCH_UP    0.4
PREEMPTIVE_OS_WAITFORSINGLEOBJECT   0.4
PREEMPTIVE_OS_AUTHORIZATIONOPS  0.2
PREEMPTIVE_OS_AUTHENTICATIONOPS 0.2
SOS_RESERVEDMEMBLOCKLIST    0.2
CMEMTHREAD  0.2

请提供其他故障排除建议，并让我知道是否需要任何其他指标。

编辑@我们正在使用 MAXDOP 8 并且 par'sm 的成本阈值设置为 default-5

更新：没有做任何更改，当我们看到夜间连接下降时，突然问题似乎消失了，现在检查没有阻塞。以下是截至目前的统计数据

OLEDB   11883.8
WRITELOG    11732.2
DBMIRROR_EVENTS_QUEUE   4969.8
CPU_USED    4093.75
DBMIRRORING_CMD 1457.2
TRACEWRITE  1080.2
PAGEIOLATCH_SH  333.4
PAGELATCH_EX    237.4
PAGELATCH_SH    31.4
ASYNC_NETWORK_IO    30.2
SOS_SCHEDULER_YIELD 6
LATCH_EX    4.4
DBMIRROR_SEND   1.6
PREEMPTIVE_OS_AUTHENTICATIONOPS 1.4
MSQL_XP 1.2
PREEMPTIVE_OS_GETPROCADDRESS    1.2
PAGELATCH_UP    0.4
PREEMPTIVE_OS_DECRYPTMESSAGE    0.4
SOS_RESERVEDMEMBLOCKLIST    0.4
PREEMPTIVE_OS_DELETESECURITYCONTEXT 0.2
PREEMPTIVE_OS_WAITFORSINGLEOBJECT   0.2
CMEMTHREAD  0.2
PREEMPTIVE_OS_AUTHORIZATIONOPS  0.2
PREEMPTIVE_OS_CRYPTACQUIRECONTEXT   0.2
PREEMPTIVE_OS_NETVALIDATEPASSWORDPOLICY 0.2

不知道今天看到的情况如何以及为什么会发生，我们没有看到那么多连接，也没有看到阻塞。但那肯定它很快就会弹出

更新@它的背面，看起来同样的等待

Answer 1

这个：

wait_type  wait_time_ms_per_sec
PAGELATCH_EX    733024.4
PAGELATCH_SH    328846.4
CPU_USED    7131.4
WRITELOG    6484.4

表明您有闩锁争用问题，而且只有闩锁争用问题。

自从

@ 下面是在我们进行节点故障转移后 15 分钟运行的

CPU_USED 行应该是准确的。因此，您的工作负载每秒只能使用 7 秒的 CPU 时间。这就像只在 7 个内核上运行一样。同时，您有 1000 秒的页面锁定时间，这意味着您平均有 1000 个会话等待锁定页面，而只有 7 个会话在执行有用的工作。

您还在一个非常大的服务器上运行非常旧的软件。这台服务器的吞吐量相当高，表明它支持的操作很重要。还要考虑您的用户名。因此，您应该强烈考虑聘请 Microsoft 支持人员或在此类事情上具有专业知识的合作伙伴。

也就是说，下一步是确定闩锁等待的来源。通常，这些要么位于数据库中表的热页上，要么位于 TempDb 中的系统页上。sys.dm_exec_requests.wait_resource 应该告诉你哪个。

如果是 tempdb，则建议减少 SQL Server tempdb 中的分配争用。

如果您的数据库中有一个表，则发布该表的 DDL（包括索引）和阻塞查询的详细信息。

这里有一份关于诊断和解决 SQL 2008 上的闩锁争用的白皮书：诊断和解决 SQL Server 上的闩锁争用