CHECKDB中的错误665

Question

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

操作系统在文件‘D：\MSSQL\Data\database1.mdf_MSSQL_DBCC34 34’中的偏移量0x00021279006000写入时，将错误665(由于文件系统限制而无法完成请求的操作)返回给Server。

正在运行的命令：

DBCC CHECKDB (database) WITH ALL_ERRORMSGS, NO_INFOMSGS, PHYSICAL_ONLY

设置：

• 5生产环境中的服务器可用性组
  • 所有带有NVMe驱动器的物理服务器
  • Server 2016
  • CHECKDB运行在所有框上。
  • 仅在AG 中的服务器3和5(次要文件)上失败
    • 每台服务器在D驱动器上都有超过700 on的空闲

- Database is 2.2TB in size (1 file)

• 2测试环境中的服务器可用性组
  • 所有带有SAN驱动器的VM
  • Server 2019
  • CHECKDB运行在所有框上。
  • 仅在AG 中的服务器1(主服务器)上失败
    • 服务器在D驱动器上有超过300 on的空闲

- Database is 2.6TB (2 files - 2.3TB and 280GB)

这一切都发生在同一个晚上。生产服务器上的数据库相同，但测试中的数据库不同。当然，我接到电话开始调查。对于失败的数据库，我决定在prod的服务器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：).手术顺利完成。碎片整理后报告:卷信息:卷大小= 5.82 TB，空闲空间= 769.03 GB，总碎片空间= 0%，最大空闲空间大小= 574.24 GB注:碎片大于64 TB的文件碎片不包括在碎片整理统计中。不需要对此卷进行碎片整理。

基于本文(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)长的filerecord大小( cmd中的/L选项或powershell中的-UseLargeFRS )。这对音量是破坏性的。这并不能保证它不会有更多的问题(事实上，由于它是文件系统的限制，在默认情况下，它会在其他点出现这个问题)。关于文件记录大小，来自微软学习：

启用对大文件记录段(FRS)的支持。需要这样做才能增加卷上每个文件所允许的区段数。对于大型FRS记录，限制范围从约150万个范围增加到约600万个范围。

如果您不需要继续使用NTFS，则可以使用ReFS，它没有此问题。

从技术上讲，还有第三种选择，即使所有的数据文件都非常小。这不会阻止问题的可能发生，但它将尽量减少机会。尽管如此，我已经看到这种情况发生在60 GB的文件大小上。