CHECKDB 期间出现错误 665

Question

在我们的服务器上运行 CHECKDB 时，我们遇到了以下错误：

在文件“D:\MSSQL\Data\database1.mdf_MSSQL_DBCC34”中的偏移量 0x00021279006000 处写入时，操作系统向 SQL Server 返回错误 665（由于文件系统限制，请求的操作无法完成）。

正在运行的命令：

DBCC CHECKDB (database) WITH ALL_ERRORMSGS, NO_INFOMSGS, PHYSICAL_ONLY

设置：

• 生产环境中的5台服务器可用性组

  • 所有具有 NVMe 驱动器的物理服务器
  • SQL Server 2016
  • CHECKDB 在所有机器上运行
  • 仅在 AG 中的服务器 3 和 5（辅助服务器）上失败
    • 每台服务器 D 盘上有超过 700GB 的可用空间
  • 数据库大小为 2.2TB（1 个文件）

• 测试环境中的2台服务器可用性组

  • 所有具有 SAN 驱动器的虚拟机
  • SQL Server 2019
  • CHECKDB 在所有机器上运行
  • 仅在 AG 中的服务器 1（主服务器）上失败
    • 服务器D盘有超过300GB的可用空间
  • 数据库为 2.6TB（2 个文件 - 2.3TB 和 280GB）

这一切都发生在同一个晚上。生产服务器上的数据库相同，但测试中的数据库不同。当然，我接到电话并开始调查此事。我决定在产品中的服务器 3 上再次运行 CHECKDB，以查找失败的数据库，并且成功且没有错误。此后我们再次收到错误，但它是随机的，这让我怀疑它是否是基于活动的。根据我们的监测，该活动相当正常。

根据本文 ( https://www.mssqltips.com/sqlservertip/3008/solving-sql-server-database-physical-file-fragmentation/ )，我们使用 CONTIG -A 查看了文件碎片。mdf 文件的碎片还不错（2 和 4 个碎片）。

根据这篇文章（https://learn.microsoft.com/en-US/troubleshoot/sql/database-engine/database-file-operations/1450-and-665-errors-running-dbcc-checkdb）我们已经要求服务器团队检查磁盘碎片。结果：

正在调用对 SQL_DATA_1 (D:) 的分析...

操作成功完成。

碎片整理后报告：

    Volume Information:
            Volume size                 = 5.82 TB
            Free space                  = 769.03 GB
            Total fragmented space      = 0%
            Largest free space size     = 574.24 GB

    Note: File fragments larger than 64MB are not included in the fragmentation statistics.

    You do not need to defragment this volume.

根据这篇文章（https://www.sqlskills.com/blogs/paul/diskeeper-10-intelliwrite-corruption-bug/），我们开始研究过滤器驱动程序，但我没有太多运气识别这方面的任何信息。

我们现在可以随意重现生产中的错误。它要求我们进行完整的 checkdb，但从那时起它每次都会出错。
DBCC CHECKDB (database) WITH ALL_ERRORMSGS

我们正在生产 AG 中的另一台服务器上运行完整检查，以查看是否因相同错误而失败。仅物理检查不会失败。

寻求有关如何进一步解决此问题的建议。

Answer 1

寻求有关如何进一步解决此问题的建议。

确实没有什么可以解决的。CheckDB 使用稀疏文件，因此，根据更改内容和位置，文件的元数据将有更多或更少的分配。现在，无论采取什么措施，NTFS 都将最终陷入瘫痪。确实不值得研究任何事情，因为你无法控制其中的任何事情。

你能做什么？

如果您想坚持使用 NTFS，一种选择是确保使用较大的记录大小。您可以通过 fsutil 的输出得到这个fsutil fsinfo ntfsinfo drive:。

如果您有 1k（1024 字节）文件记录，则可以使用 4k (4096) 的长文件记录大小格式化驱动器（cmd 中的 /L 选项或 powershell 中的 -UseLargeFRS）。这对于体积来说是破坏性的。这并不能保证它不会出现更多问题（事实上，由于它是文件系统限制，因此默认情况下会在其他时候出现此问题）。来自Microsoft Learn，关于文件记录大小：

启用对大文件记录段 (FRS) 的支持。这是为了增加卷上每个文件允许的扩展数量所必需的。对于大型 FRS 记录，限制从约 150 万个范围增加到约 600 万个范围。

如果您不需要保留在 NTFS 上，则可以使用 ReFS，它不存在此问题。

从技术上讲，还有第三种选择，即使所有数据文件变得非常小。这不会阻止问题发生的可能性，但会最大限度地减少可能性。话虽如此，我亲眼目睹过这种情况发生在小至 60 GB 的文件上。