China Dataset

由于结构限制，NTFS 文件系统中碎片严重的文件可能不会超过一定大小。DBCC 快照或快照数据库的稀疏性质可能会导致属性耗尽。

我们知道，每次执行 DBCC CHECKDB 时，都会创建数据库快照。如果是 VLDB，则需要大量 ATTRIBUTE_LIST_ENTRY 实例来维护 NTFS 中碎片严重的文件。如果空间位于文件系统已跟踪的群集旁边，则属性将被压缩为单个条目。

但是，如果空间碎片化，则必须使用多个属性进行跟踪。因此，严重的文件碎片化可能会导致属性耗尽，从而导致 665 错误，随后导致 CHECKDB 失败。

解决此问题有哪些可行的选项？
以下是我们可以用来消除此问题的选项列表。以下所有选项都需要数据库停机。

添加具有 ReFS 格式（非 NTFS）的新驱动器并将数据文件移动到该新卷。ReFS 没有相同的 ATTRIBUTE_LIST_ENTRY 限制。
对数据文件所在的卷进行碎片整理。确保碎片整理实用程序是事务 玻利维亚电报数据 性的，并且在此过程中 SQL 处于关闭状态。碎片整理在固态硬盘 (SSD) 介质上的工作方式不同，通常无法解决问题。复制文件并允许 SSD 固件重新打包物理存储通常是更好的解决方案。
文件复制 – 执行文件复制可能会更好地获取空间，因为在此过程中字节可能会紧密地挤在一起。复制文件（或将其移动到其他卷）可能会减少属性使用，并可能防止出现操作系统错误 665。将一个或多个数据库文件复制到另一个驱动器。然后，您可以将文件保留在新卷上或将其复制回原始卷。
如何避免这种情况？
此问题主要发生在较大的数据库上。如果您的数据库超过 2 TB，则建议遵循以下任何最佳实践：

拥有多个数据文件，而不是一个。
如果可能的话，为数据文件分配 ReFS 格式的驱动器，而不是 NTFS。
如果您对 ReFS 格式有限制，则使用 /L 选项将驱动器格式化为 NTFS 以获取较大的 FRS。这会使 ATTRIBUTE_LIST_ENTRY 更大，并有助于避免属性耗尽。
通过设置适当的自动增长大小来限制数据库增长的频率，从而减少碎片。
始终在非工作时间执行数据库维护。
长期解决方案是什么？
使用 ReFS 格式是解决此问题的长期解决方案。虽然我们有上述不同的选项来解决这个问题，但永久的解决方案是为保存更大数据库的驱动器使用 ReFS 卷。

需要帮助克服数据库管理员的挑战？立即联系我们的专家。