我写信是想看看是否有人可以帮助我解决一个我似乎无法弄清楚的问题。这将是一个难题,我将尝试列出尽可能多的重要信息,但如果我遗漏任何信息,请告诉我,我很乐意提供您可能需要的任何信息如果你愿意,可以帮忙吗?
我遇到的症状是,作为维护计划中的任务之一,针对 VLDB(大约 1TB)运行时,dbcc checkdb 被锁定,并且错误日志报告错误:分配 BUF 失败:FAIL_BUFFER_ALLOCATION 7(有时8) 然后错误日志开始填满关于物理和虚拟内存的内存图表(我能描述的最好的方式,请参见随附的屏幕截图)。
所以这是场景。在我们迁移 OLDSERVER 之前,我们目前正在开始测试我们的 NEWSERVER。在我们的 OLDSERVER 上,一切都按预期工作。在我们的夜间维护计划例程中,问题出现在我们的 PROD 实例中的 NEWSERVER 上。实例中存在多个数据库,但我们关心的是 DB1。DB1由2个数据文件和1个日志文件组成。在 OLDSERVER 上,.mdf (519 GB) 位于 H:,.ndf (200 GB) 位于 E:,而 .ldf (313 GB) 位于 D:。在 NEWSERVER 上,两个数据文件都在 E: 上,日志文件在 D: 上。注意:我没有参与具有 2 个数据文件的数据库的配置或它们的位置,或者任何一个服务器的设置/配置。
在 OLDSERVER 上,维护计划(由检查数据库完整性任务、完整数据库备份和维护清理任务组成,并配置为仅针对 DB1 运行)每晚完成,没有任何问题。在 NEWSERVER 上,维护计划(以完全相同的方式设置)有时会完成,但大多数情况下会像蜗牛一样缓慢地爬行(或发现比蜗牛更慢的东西),并且最终会在 Check Database Integrity 任务期间失败。
我可以手动运行 DBCC CHECKDB,有时它会非常及时地完成,但有时即使手动运行也会表现出相同的行为。并不是说我知道这些设置中的任何一个是否直接适用,但我尝试过打开和关闭内存中的锁定页面,没有区别,我也尝试过打开和关闭即时文件初始化,没有区别。
下面是我们称之为 NEWSERVER 的物理服务器的详细信息。
- 操作系统: Windows Server 2016 Standard - 6.3 (14393)
- 处理器数量: 32
- 内存: 384 GB(可用 382 GB)
- 驱动器(配置的所有 SSD):操作系统 (C:) -181 GB 免费 243 GB | 日志 (D:) - 117 GB 免费 488 GB | 数据 (E:) - 2.86 TB 免费 3.81 TB | 备份 (F:) - 1.44 TB 免费 1.9 TB
- SQL Server 2016 标准版- SP2 CU3 (13.0.5216.0)
- 实例数: 4(PROD、DEV、TEST、TRAIN)
- 每个实例的最大内存配置: PROD (131072 MB) | 开发 (65536 MB) | 测试(65536 MB)| 火车 (32768 MB)
以下是我们称为 OLDSERVER 的物理服务器的详细信息
- 操作系统: Windows Server 2016 Standard - 6.3 (14393)
- 处理器数量: 24
- 内存: 384 GB
- 驱动器(主轴和 SSD 混合):操作系统(C:SSD)-163 GB 免费 249 GB | 日志(D:15k 主轴)- 197 GB 免费 557 GB | ProdData(E:SSD)- 604 GB 免费 865 GB | 备份(F:10k 主轴)- 1.46 TB 免费 2.18 TB | NonProdData(G:SSD)- 591 GB 免费 1.08 TB | ProdData2(H:SSD)- 231 GB 免费 743 GB
- SQL Server 2016 标准版- SP2 CU2 (13.0.5153.0)
- 实例数: 5(PROD、DEV、TEST、TRAIN、PROD2)
- 每个实例的最大内存配置: PROD (131072 MB) | 开发 (65536 MB) | 测试(65536 MB)| 火车 (32768 MB) | 产品 2 (32768 MB)
附件是错误日志的第一行(将近 50 行)(如果需要,我可以提供更多。
非常感谢任何帮助或想法!
虽然我无法从OLDSERVER数据中分辨出来,但看起来NEWSERVER至少有 2 个 NUMA 节点,而我不确定OLDSERVER是否有多个 NUMA 节点或单个节点。
目前,假设OLDERSERVER只有一个 NUMA 节点,您似乎遇到了一个已在 SQL Server 2016 SP2 CU5中修复的已知问题,而您目前使用的是 SQL Server 2016 SP2 CU3。
如果您查看 MEMORYSTATUS 输出,它确实有大约 1.59% 的可用页面,至少在 NUMA 节点 0 上是这样。
我至少会应用 SP2 CU5 并再次运行负载。
事实证明,在与 Microsoft 就此问题进行了几个月的合作后,他们确定它现在是 DBCC CHECKDB 和 VLDB 的“已知问题”,并且 SQL 2016 SP3 中将进行修复。当我询问该问题是否存在于 SQL 2017 中时,他们说是的,而且他们很可能也会在那里发布一个服务包。那个很有趣,因为我认为他们不再做服务包了,但她说这是一个足够大的问题,他们可能不得不在服务包中做这件事……所以现在我等着……