我在生产中的数据库在不同的驱动器中有 28ndf 文件。在 T 驱动器上只有 test_audit20.ndf 到 test_audit23.ndf 文件。并且文件 test_audit20 和 test_audit21.ndf 自动增长是无的。
在 test_audit db 上执行 checkdb 命令时出现错误：
Msg 1823, Level 16, State 6, Line 1
无法创建数据库快照，因为它无法启动。
Msg 1823, Level 16, State 7, Line 1
无法创建数据库快照，因为它无法启动。
Msg 1823, Level 16, State 8, Line 1
无法创建数据库快照，因为它无法启动。
消息 7928，级别 16，状态 1，行 1
无法创建用于在线检查的数据库快照。
原因是在先前的错误中给出的，或者基础卷之一不支持稀疏文件或备用流。
试图获得独占访问权限以脱机运行检查。
消息 8921，第 16 层，状态 3，第 1 行
检查终止。收集事实时检测到故障。可能是 tempdb 空间不足或系统表不一致。检查以前的错误。
消息 3313，级别 21，状态 1，行 1
在重做数据库“test_audit”中记录的操作期间，日志记录 ID (19372:991854:10) 发生错误。
通常，特定故障以前会在 Windows 事件日志服务中记录为错误。从完整备份还原数据库，或修复数据库。
消息 9001，级别 21，状态 7，第 1 行
数据库“test_audit”的日志不可用。检查事件日志以获取相关的错误消息。解决所有错误并重新启动数据库。
消息 5128，第 17 层，状态 2，第 1 行
由于磁盘空间不足，写入稀疏文件 't:\test_audit23.ndf_MSSQL_DBCC6' 失败。
Msg 0, Level 20, State 0, Line 0
当前命令发生严重错误。结果，如果有的话，应该丢弃。
我不确定为什么它需要写入这个磁盘。
可能是为此磁盘上的一个文件打开了自动增长。我们可以关闭它，它可能会开始工作。
目前我有 X 和 Y 驱动器，它们是“活动”数据驱动器，应该在其中发生增长。这些也几乎已满（每个 3TB），我必须建立一些新的磁盘驱动器并将数据文件合并到它们。我已经达到了 AWS 在该区域预置 TB 的限制。
此外，我每周都在手动扩展这些数据文件。正如我之前提到的，我不能依赖 SQL 的自动增长，因为它会等到所有文件都已满。这会导致数据写入集中到一个磁盘/文件中，并在发生这种情况时对性能产生巨大的负面影响——并导致客户支持的工单激增并影响 SLA。
我的问题是我可以尝试关闭 T 盘上任何数据文件的自动增长功能，然后再试一次吗？它会引起任何问题还是有其他方法。
该消息告诉您失败的原因，这是失败的根本原因：
看起来 T 卷空间不足。
拍摄隐藏快照并在数据库上运行崩溃恢复以使其处于一致状态，以便 checkdb 可以针对数据库的隐藏快照副本运行。这就是 checkdb 在线运行时的工作方式。有一个名为“离线”的 tabblock 选项，因为它在在线方式没有的地方使用锁。
你大多是正确的。它不会强制所有写入单个数据文件，但它会重新计算比例填充值，这会导致少数文件出现热点。这是众所周知的（尽管似乎没人关心），这就是为什么我们有跟踪标志来共同增长整个文件组（TF 1118）。这已更改，现在是 2016 年的数据库选项。
每周手动增长数据文件似乎过分了。如果你知道它每周只会增长一个 TB，为什么增长得这么低？如果将性能卷维护任务分配给服务帐户或服务 sid，您应该能够将数据文件增长得相当大而影响很小。
自动增长设置不是您的问题，稀疏写入和卷上的空间不足是。
更新：
也许。要看。
如果数据文件已经在单片卷上，那么我会努力将它们从同一个卷中迁移出来。您可以使用挂载点、存储空间等，但您需要有可用空间。同样，这与您的自动增长设置无关，而是与可用空间量以及使快照保持一致所需的空间量有关。
你还能做什么？
好吧，您不必一次运行 CheckDB()。您可以将其分解成更小的检查块，例如使用 checkalloc、checkcatalog、checktable 等。请参阅此处的链接，我不需要重新制作轮子，因为 Paul 已经有很棒的文章。
问题的根本原因是您不熟悉 CheckDB 的工作原理，这没关系。既然您知道现在需要一定程度的理解，请查看我提供的链接并阅读 Paul 的帖子。
将为每个数据文件制作快照文件，它是一个快照，实际上并不写入数据库本身。当您阅读 Paul 的系列文章时，我相信您会理解是什么以及为什么 - 以及这个答案。