标签: latch

第一次发帖，希望我做对了。

我是一个“偶然的 dba”，他正在学习很多东西，但不可否认还有很多东西要学。这是我的大脑转储：

1. Prod 服务器有 500 万行。我将这些行复制到测试服务器。
2. 使用 SNAPSHOT 或 READ UNCOMMITTED 会产生不同的经过时间，但 Prod 和 Test 之间的比率始终约为 5:1（SNAPSHOT 为 14 分钟：3 分钟，READ UNCOMMITTED 为 4 分钟：sub-1）
3. 使用 STATISTICS IO ON 显示 Prod 上的大多数读取是逻辑的（~90%），而 Test 上的读取都不是逻辑的。我想这应该意味着 Prod 会更快。
4. 大多数时间似乎将等待“PAGEIOLATCH_SH”类型。
5. 我不认为不同的统计数据无关紧要，因为不应在未过滤、未连接、未排序的查询上使用任何索引。
6. 选择两台服务器上的前 n 行显示了一个非常线性的比例……比例总是 ~5:1。
7. 比较不是一一对应，但我认为唯一相关的区别是活动和存储。
8. 我在几乎没有活动时进行了比较，并看到了相同的结果。
9. 我发现 autogrowth 设置为 1MB（呃），我已经改变了，但我想知道这是否导致文件系统级别的存储碎片化。
10. 该数据库位于与 Windows 安装不同的卷上，但它确实与 tempdb 和 FILESTREAM 存储共享一个卷，我认为这也可能导致存储碎片化。
11. “优化驱动器”Windows 实用程序表示该卷“正常（98% 空间效率）”，这似乎表明文件系统碎片可能不是问题。

问题：

感谢您的关注和帮助！

编辑：在第二条语句中添加了剩余时间信息。

我们的 Ola Hallengren IntegrityCheck 作业由于在用户数据库上运行 DBCC CHECKDB 时发生缓冲区锁存超时而失败。

但是，报告的缓冲区锁存器超时位于 TempDB（数据库 ID 2）中。

作业的输出：

Date and time: 2022-01-22 09:04:15 [SQLSTATE 01000]
Database context: [master] [SQLSTATE 01000]
Command: SET LOCK_TIMEOUT 600000; DBCC CHECKDB ([SentryOne]) WITH NO_INFOMSGS, ALL_ERRORMSGS, MAXDOP = 4 [SQLSTATE 01000]
Msg 845, Sev 17, State 1, Line 1 : Time-out occurred while waiting for buffer latch type 2 for page (6:222), database ID 2. [SQLSTATE 42000]
Outcome: Failed [SQLSTATE 01000]
Duration: 12:40:32 [SQLSTATE 01000]
Date and time: 2022-01-22 21:44:47 [SQLSTATE …

问题

自今年年初以来，由于我们系统中的 SQL 超时，我们一直在经历高度的用户中断。

有问题的 SQL-Server 实例在工作时间内的 CPU 使用率非常高（所有 16 个内核的 CPU 使用率始终高于 90%）。

我们还注意到等待时间非常长：CXPACKET 和 LATCH_EX 的组合约占所有等待的 97%。这在 CXPACKET 和 LATCH_EX 之间分成大约 50/50。

占 LATCH_EX 绝大多数 (>95%) 的非缓冲闩锁等待是 ACCESS_METHODS_DATASET_PARENT。

这表明问题与并行性有关。

等待时间比例的一个例子是：

CXPACKET : 332,301,799 ms
LATCH_EX : 267,955,752 ms
PAGEIOLATCH_SH : 2,955,160 ms

这是 1 月 11 日 08:00-16:24 之间的时间段。

正在考虑的选项

1) 将 MAXDOP 从 0 更改为 4 到 8 之间的值

2) 将并行度的成本阈值从 50 修改为更高的数字

关于如何减轻我们所看到的非常高的 CPU 负载并减少超时的建议最受欢迎，特别是建议的行动方案是否明智，以及将 MAXDOP 和并行成本阈值更改为哪些数字。

背景资料

• SQL-Server 2008 R2 在 AMD Opteron 6180 SE …

背景： 我最近开始在一家拥有许多不同州的数据库的新商店。我今天早上到达（刚刚被添加到 SQL DBA 邮件组）找到一封关于昨晚在其中一台服务器上失败的 CHECKDB 作业的电子邮件（我被警告过有问题）。

我不会在这里详述这件事的细节，它似乎归结为等待缓冲区锁存器的一些超时 - 就其本身而言，很难说出为什么会这样，因为应该有（并且似乎有一直）昨晚运行时很少使用系统。

日志中持续存在超过 15 秒的 I/O 请求问题，并且 vmware 人员说存储存在通信问题（持续的网络问题），所以这在某种程度上解释了我认为的问题。

重要提示：我今天早上重新运行了 CHECKDB，它完全很快，发现了 0 个错误，据我所知，自从昨晚失败以来没有发生任何事情，所以（如果我错了，请纠正我），我在那里非常有信心没有数据库问题，昨晚是一个异常，可能是由网络或存储问题引发的（当网络人员回复我时，我会了解更多关于这个......如果他们这样做的话）。

实际点： 在日志中，就在昨晚的 CHECKDB 作业失败的地方，等待缓冲区闩锁的超时 - 对我来说奇怪的是它应该尝试的页面的数据库 ID闩锁是 11，并且实例上没有具有该 ID 的数据库 - ID 最多只能达到 10。

接下来是 CHECKDB 行，发现 1 个错误，修复了 0 个，指向具有分割点的内部数据库快照（请参阅下面的错误日志）

具体问题：

1. 为什么会有对不存在的数据库 ID 的引用（内部数据库快照是否在某个时候被分配了一个数据库 ID，这就是它所指的内容）？
2. 有没有办法找出有问题的数据库快照是什么（这与 CHECKDB 的工作方式有关，还是其他原因）？
3. 有没有办法找到有问题的快照发生了什么（因为当我今天早上再次运行 CHECKDB 时，这显然不是问题）。

错误日志：

01/04/2017 23:50 spid101 Unknown DBCC CHECKDB (zenworks_UAL) WITH no_infomsgs 由 ARTSLOCAL\svc_zcmsql 执行发现 1 个错误并修复了 0 个错误。已用时间：0 小时 28 分 51 秒。内部数据库快照具有分割点 LSN = 00adf51f:00019bf4:0001 和第一个 …

我已经阅读了许多关于 NOLOCK 或读取未提交的隔离级别在采用的锁/闩锁方面如何运作的不同看法。

当使用带有 NOLOCK 的 SELECT 或在 Read Uncommitted Isolation 级别时，是唯一取出模式稳定性锁的锁，还是在查询通过行时滚动获取共享锁？（显然这些锁需要立即放下）

闩锁呢？当我假设不允许引用正在修改的内存对象时，如何处理内存中的页面？

最近，当我试图查找有关latch_ex 等待类型的信息时，我遇到了一个博客，如下所述，其中介绍了latch 和lock。

阅读此博客后，我只是对一件事感到好奇。当应用程序提交请求时，SQL Server 将首先在缓冲区缓存中查找信息，如果页面不在缓冲区缓存中，则仅从磁盘读取并将其放入缓冲区缓存中，然后再将信息发送给应用程序。我的问题基于上面的屏幕截图，其中指出闩锁和锁定需要避免两个线程更新同一页面。基本上所有来到SQL server的请求都会先进入buffer cache，如果buffer cache中的页面忙于更新，另一个线程将不得不等待。它不会回到磁盘，因为页面已经在内存中。那么锁定的目的是什么，因为每个请求都将通过内存完成并且有闩锁来保护页面