本文可帮助你解决在执行 DBCC CHECKDB 、创建数据库快照或文件增长时针对数据库文件报告 OS 错误 1450 和 665 的问题。

原始产品版本： SQL Server
原始 KB 编号： 2002606

假设你在运行 SQL Server 的计算机上执行以下操作之一：

SQL Server对以下操作使用 稀疏文件 ：数据库快照 和 DBCC CHECKDB 。

由于这些操作，你可能会注意到SQL Server错误日志中报告了一个或多个这些错误，具体取决于运行SQL Server的环境。

The operating system returned error 665(The requested operation could not be completed due to a file system limitation) to SQL Server during a write at offset 0x00002a3ef96000 in file 'Sam.mdf:MSSQL_DBCC18'
The operating system returned error 1450 (Insufficient system resources exist to complete the requested service.) to SQL Server during a write at offset 0x00002a3ef96000 in file with handle 0x0000000000000D5C. This is usually a temporary condition and the SQL Server will keep retrying the operation. If the condition persists, then immediate action must be taken to correct it.`
除了这些错误，你可能还会注意到以下闩锁超时错误：
Timeout occurred while waiting for latch: class *'DBCC_MULTIOBJECT_SCANNER'*, id 000000002C61DF40, type 4, Task 0x00000000038089B8 : 16, waittime 600, flags 0x1a, owning task 0x0000000006A09828. Continuing to wait.  
Timeout occurred while waiting for latch: class *'ACCESS_METHODS_HOBT_COUNT'*, id 000000002C61DF40, type 4, Task 0x00000000038089B8 : 16, waittime 600, flags 0x1a, owning task 0x0000000006A09828. Continuing to wait.  
此外，在查看 DMV)  (各种动态管理视图（如 sys.dm_exec_requests 和 sys.dm_os_waiting_tasks）时，可能还会注意到阻塞。
在极少数情况下，你可能会在SQL Server错误日志中观察到一个不产生收益的计划程序问题，并且SQL Server生成内存转储。
如果需要大量 ATTRIBUTE_LIST_ENTRY 实例来维护 NTFS 中的大量碎片文件，则会出现此问题。 如果空间位于文件系统已跟踪的群集旁边，则会将属性压缩为单个条目。 但是，如果空间已碎片化，则必须使用多个属性对其进行跟踪。 因此，大量文件碎片可能会导致属性耗尽和生成的 665 错误。 此行为在以下知识库文章中进行了说明： NTFS 卷中碎片严重的文件可能不会超过特定大小。
当在这些快照文件的生命周期内发生大量数据修改时，SQL Server或其他应用程序创建的常规文件和稀疏文件都可能会碎片化到这些级别。
如果跨位于同一卷上的一组条带文件执行数据库备份，或者如果要将 (BCP-ing) 数据大容量复制到同一卷上的多个文件，则写入操作可能最终位于相邻位置，但属于不同的文件。 例如，一个流写入 201 到 400 之间的偏移量，另一个流从 401 写入到 600，第三个流可以从 601 写入到 800。 此过程也适用于其他流。 这将导致同一物理介质上的文件碎片。 每个备份文件或 BCP 输出流都可能耗尽属性存储，因为其中任何备份文件或 BCP 输出流都没有获得相邻存储。
有关SQL Server引擎如何使用 NTFS 稀疏文件和备用数据流的完整背景信息，请参阅详细信息。
请考虑使用以下一个或多个选项来解决此问题：
将数据库文件放置在弹性文件系统 (ReFS)  卷上，该卷与 NTFS 提供的限制不同ATTRIBUTE_LIST_ENTRY。 如果要使用当前 NTFS 卷，则必须在将数据库文件暂时移到其他位置后使用 ReFS 重新格式化。 使用 ReFS 是解决此问题的最佳长期解决方案。
SQL Server 2012 及更早版本使用命名文件流而不是稀疏文件来创建CHECKDB快照。 ReFS 不支持文件流。 DBCC CHECKDB在 ReFS 中的 SQL Server 2012 文件上运行可能会导致错误。 有关详细信息，请参阅 DBCC CHECKDB 如何从 2014 SQL Server 开始创建内部快照数据库中的说明。
对数据库文件所在的卷进行碎片化。 请确保碎片整理实用工具是事务性的。 有关对SQL Server文件所在的驱动器进行碎片整理的详细信息，请参阅SQL Server数据库驱动器进行碎片整理时的注意事项和建议。 必须关闭SQL Server才能对文件执行此操作。 建议在对文件进行碎片整理之前创建完整数据库备份，作为安全措施。 碎片整理在固态硬盘 (SSD) 介质上的工作方式不同，通常无法解决问题。 复制文件 () 并允许 SSD 固件重新打包物理存储通常是更好的解决方案。 有关详细信息，请参阅 操作系统错误 (665 - 文件系统限制) 不再仅限于 DBCC。
文件复制 - 执行文件副本可能允许更好的空间获取，因为字节可能在过程中紧密地打包在一起。 复制文件 (或将其移动到其他卷) 可能会减少属性使用情况，并可能防止 OS 错误 665。 将一个或多个数据库文件复制到另一个驱动器。 然后，可以将文件保留在新卷上，或将其复制回原始卷。
使用 /L 选项设置 NTFS 卷的格式以获取大型 FRS。 此选项可能会缓解此问题，因为它会使问题 ATTRIBUTE_LIST_ENTRY 变得更大。 使用DBCC CHECKDB时，此选项可能没有帮助，因为后者会为数据库快照创建稀疏文件。
对于运行 Windows Server 2008 R2 和 Vista 的系统，首先需要应用 知识库文章967351 中的修补程序， /L 然后再将 选项与 命令一起使用 format 。
将大型数据库拆分为较小的文件。 例如，如果有一个 8 TB 数据文件，则可以将其分解为 8 个 1 TB 数据文件。 此选项可能会有所帮助，因为对较小的文件进行较少的修改，因此不太可能引入属性耗尽。 此外，在移动数据的过程中，文件将进行紧凑组织，并减少碎片。 下面是概要步骤，其中概述了该过程：
将 7 个新的 1-TB 文件添加到同一文件组。
重新生成现有表的聚集索引，这会自动将每个表的数据分散到八个文件中。 如果表没有聚集索引，请创建一个并删除它以完成相同的操作。
收缩原始的 8-TB 文件，该文件现在已满约 12%。
数据库自动增长设置：调整自动 增长增量 数据库设置，以获取有利于生产性能和打包 NTFS 属性的大小。 自动增长发生的频率越低，增长增量大小越大，文件碎片的可能性就越小。
使用性能增强功能缩短命令的 DBCC CHECK 生存期，从而避免 665 错误： 使用 PHYSICAL_ONLY 选项时，对 DBCC CHECKDB 命令的改进可能会提高性能。 请记住，使用 PHYSICAL_ONLY switch 运行DBCC CHECKDB并不能保证避免此错误，但在许多情况下会降低出现此错误的可能性。
如果要跨多个文件执行数据库备份 (条带集) ，请仔细计划文件数， MAXTRANSFERSIZEBLOCKSIZE (请参阅 BACKUP) 。 目标是减少文件系统上的片段，通常通过将较大的字节区块写入文件来实现。 可以考虑跨多个卷对文件进行条带化，以提高性能并减少碎片。
如果使用 BCP 同时写入多个文件，请调整实用工具写入大小，例如增加 BCP 批大小。 此外，请考虑将多个流写入不同的卷，以避免碎片或减少并行写入次数。
若要执行 DBCC CHECKDB，可以考虑设置可用性组或日志传送/备用服务器。 或者使用第二台服务器， DBCC CHECKDB 在其中可以运行命令来卸载工作，并避免遇到稀疏文件大量碎片导致的问题。
执行 DBCC CHECKDB时，如果在数据库服务器上活动很少时运行命令，则稀疏文件将被轻填充。 对文件的写入次数越少，将降低 NTFS 属性耗尽的可能性。 如果可能，活动减少是另一个在只读服务器上运行 DBCC CHECKDB 的原因。
如果运行的是 SQL Server 2014，请升级到最新的 Service Pack。 有关详细信息，请参阅在 2014 SQL Server中对包含列存储索引的数据库执行 DBCC CHECKDB 命令时修复：OS 错误 665。
工作原理：SQL Server 2005 数据库快照 (副本) 
SQL Server报告操作系统错误 1450、1452 或 665， (重试) 
工作原理：SQL Server稀疏文件 (DBCC 和快照数据库) 重新访问
数据库快照的工作原理
DBCC CHECKDB (Transact-SQL) [请参阅“内部数据库快照”部分]
用于跟踪写入快照稀疏文件的新扩展事件
稀疏文件错误：1450 或 665 由于文件碎片：修复和解决方法
			即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。

        
提交和查看相关反馈