DBCC checkdb 的内存授权是如何确定的（除了来自资源管理器的内存授权的最大大小，可能是默认池）？
我不是试图解决一个特定的问题。我只是好奇并试图理解。
CHECKDB 作业最近开始为 2 个数据库（msdb 和一个用户数据库）返回错误号 2706。虽然 msdb.dbo.suspect_pages 表是空的。当我手动运行 CHECKDB 时，它说： CHECKDB 在数据库“msdb”中发现 0 个分配错误和 0 个一致性错误。
我不确定它是否相关，但就在错误开始出现之前，我们将 SQL Server 2016 从 CU17 升级到 SP3。
我在哪里可以找到有关错误号 2706 含义的信息？
谢谢
为了解决这个问题，在这种情况下，我们正在修复一个数字数据库，其中在损坏之前没有进行任何备份，因此恢复备份不是一种选择。不是我的数据库:)
在使用 REPAIR_ALLOW_DATA_LOSS 运行 DBCC CHECKDB 时，我们会收到数千个如下所示的错误：
Msg 8928, Level 16, State 1, Line 7
Object ID 2105058535, index ID 1, partition ID 72057594038779904, alloc unit ID 72057594039762944 (type LOB data): Page (1:24911) could not be processed. See other errors for details.
Repairing this error requires other errors to be corrected first.
Msg 8965, Level 16, State 1, Line 7
Table error: Object ID 2105058535, index ID 1, partition ID 72057594038779904, alloc unit ID 72057594039762944 (type LOB data). The off-row data node at page (1:24911), slot 0, text ID 265289728 is referenced by page (1:24820), slot 0, but was not seen in the scan.
Repairing this error requires other errors to be corrected first.
Msg 8928, Level 16, State 1, Line 7
Object ID 2105058535, index ID 1, partition ID 72057594038779904, alloc unit ID 72057594039762944 (type LOB data): Page (1:24912) could not be processed. See other errors for details.
Repairing this error requires other errors to be corrected first.
Msg 8965, Level 16, State 1, Line 7
Table error: Object ID 2105058535, index ID 1, partition ID 72057594038779904, alloc unit ID 72057594039762944 (type LOB data). The off-row data node at page (1:24912), slot 0, text ID 265289728 is referenced by page (1:24820), slot 0, but was not seen in the scan.
Repairing this error requires other errors to be corrected first.
Msg 8928, Level 16, State 1, Line 7
Object ID 2105058535, index ID 1, partition ID 72057594038779904, alloc unit ID 72057594039762944 (type LOB data): Page (1:24913) could not be processed. See other errors for details.
Repairing this error requires other errors to be corrected first.
反复运行它并不能减少错误，所以看起来 DBCC 无法修复它。
我的下一个想法是尝试识别并删除表中有问题的行。但是，当我尝试删除已知有问题的行时，它也出错了，所以我目前的想法是将已知良好的行提取到与旧表具有相同架构的新表中，删除旧表并重命名新表以匹配旧的。
这样做的问题是，SQL Server 没有提供可捕获的错误，而是在遇到问题行时简单地断开连接，因此我似乎无法找到一种编程方式来识别“好”行。
T-SQL 中是否有任何方法可以强制它提供一个很好的可捕获错误，以便我可以遍历表并提取好的行，或者 DBCC CHECKDB 的一些“高级”模式可能能够修复它在网络上的任何地方都不明显？
我迷失了一件事。根据 MS docs full checkdb without option does column-value checks，那么运行 data_purity 有什么好处？我所说的“增益”是指进行了多么详细的检查，我现在不考虑性能。
我是否理解正确，如果数据库是在 SQL2005 之前创建的，它将 dbi_dbccFlags 设置为 0 并且完整的 checkdb 将跳过列值检查，但是一旦此类数据库将至少有一个成功的 data_purity 检查，该标志将设置为 2 并且在每个完整的 checkdb 期间都会进行列值检查？如果数据库是在 SQL2005+ 中创建的，它将默认将 dbi_dbccFlags 设置为 2，然后完全 checkdb 没有选项和 data_purity 将是相同的检查？
估计也似乎表明，对于 SQL2005+，这两个检查之间没有区别，至少在 TempDB 所需的空间方面：
- DBCC CHECKDB('AdventureWorks2019') WITH PHYSICAL_ONLY, ESTIMATEONLY
“AdventureWorks2019”的 DBCC 结果。
数据库 AdventureWorks2019 上的 CHECKDB 所需的估计 TEMPDB 空间（以 KB 为单位）= 39189。
- DBCC CHECKDB('AdventureWorks2019') WITH ESTIMATEONLY
“AdventureWorks2019”的 DBCC 结果。
数据库 AdventureWorks2019 上的 CHECKDB 所需的估计 TEMPDB 空间（以 KB 为单位）= 225996。
- DBCC CHECKDB('AdventureWorks2019') WITH DATA_PURITY, ESTIMATEONLY
“AdventureWorks2019”的 DBCC 结果。
数据库 AdventureWorks2019 上的 CHECKDB 所需的估计 TEMPDB 空间（以 KB 为单位）= 225996。
如果文件组包含列存储索引，则似乎设置文件组以read_only防止dbcc checkdb整个数据库。尝试运行checkdb或checkfilegroup（对于数据库中的任何文件组，包括读写辅助和[PRIMARY]）时，返回以下错误...
Msg 8921, Level 16, State 1, Line 24
Check terminated. A failure was detected while collecting facts.
Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
在只读文件组中有列存储数据的受支持方法吗？还是在这种情况下我被排除在完整性检查之外？
复现
create database check_fg_ro
go
use check_fg_ro
go
exec sp_changedbowner 'sa';
go
alter database check_fg_ro add filegroup check_fg_ro_2;
alter database check_fg_ro
add file (
name='check_fg_ro_2'
,filename='C:\check_fg_ro_2.ndf'
) to filegroup check_fg_ro_2;
go
create table foo (
i int not null primary key
) on check_fg_ro_2;
go
create columnstore index ccix_foo on foo(i);
go
use master
go
alter database check_fg_ro modify filegroup check_fg_ro_2 read_only;
go
dbcc checkdb( check_fg_ro ) with no_infomsgs, all_errormsgs, extended_logical_checks;
/*
Msg 8921, Level 16, State 1, Line 24
Check terminated. A failure was detected while collecting facts.
Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
*/
go
免责声明：交叉发布到technet 论坛
我在生产中的数据库在不同的驱动器中有 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 盘上任何数据文件的自动增长功能，然后再试一次吗？它会引起任何问题还是有其他方法。
我收到了很多错误DBCC CHECKDB，包括：
消息 8939，级别 16，状态 98，第 1 行
表错误：对象 ID 0，索引 ID -1，分区 ID 0，分配单元 ID 3667181342891245568（未知类型），页面 (7791:-1694668604)。测试 (IS_OFF (BUF_IOERR, pBUF->bstat)) 失败。值为 133129 和 -12。
消息 8928，级别 16，状态 1，行 1
对象 ID 405576483，索引 ID 73，分区 ID 72057594049200128，分配单元 ID 72057594054246400（行内数据类型）：无法处理页面 (1:194923)。有关详细信息，请参阅其他错误。
消息 8976，级别 16，状态 1，行 1
表错误：对象 ID 405576483，索引 ID 73，分区 ID 72057594049200128，分配单元 ID 72057594054246400（类型行内数据）。页面 (1:194923) 未在扫描中看到，尽管其父级 (1:186194) 和前一个 (1:194922) 引用了它。检查任何以前的错误。
消息 8980，级别 16，状态 1，行 1
表错误：对象 ID 405576483，索引 ID 73，分区 ID 72057594049200128，分配单元 ID 72057594054246400（类型行内数据）。索引节点页面 (1:186194)，插槽 103 引用子页面 (1:194924) 和前一个子页面 (1:194923)，但没有遇到它们。
消息 8978，级别 16，状态 1，行 1
表错误：对象 ID 405576483，索引 ID 73，分区 ID 72057594049200128，分配单元 ID 72057594054246400（类型行内数据）。页面 (1:194932) 缺少上一页 (1:194931) 的引用。可能的连锁问题。
最重要的是，最后会转达以下内容：
CHECKDB 在数据库“houseme”中发现 0 个分配错误和 28 个一致性错误。
repair_allow_data_loss 是 DBCC CHECKDB (houseme) 发现的错误的最低修复级别。
我该怎么办？
有谁知道如何让 DBCC CheckDB 产生错误？我正在测试一个脚本，需要以最简单的模式使用 DBCC Checkdb 来返回错误，同时尝试修复和尝试进入单用户模式时...
我正在使用的简单 dbcc checkdb 命令是批处理文件的一部分，如下所示：
OSQL -S MYPC -E -d MyDB -l 10 -Q "DBCC CHECKDB(AG_DB_STORESQL)" -b -o c:\MyFolder\MSSQL_DB_CHECK.Log
如果没有发现错误，脚本结束。如果发现错误，脚本会尝试使用 REPAIR_REBUILD 选项修复它们，如果失败，脚本会尝试使用 REPAIR_ALLOW_DATA_LOSS 选项修复它们。显然，在尝试修复脚本之前尝试将数据库置于单用户模式（这也是错误陷阱）
所以我正在寻找的是一种导致 DBCC CheckDB 返回错误的方法。
试图弄清楚一些但无法找到任何东西谷歌搜索或在论坛中搜索。
我们在我们的一个 MS SQL 服务器的数据文件夹中得到了几个文件
数据库名.ndf_MSSQL_DBCC66 数据库名.ndf_MSSQL_DBCC63
谁能告诉我这些文件是什么？
当数据库仍然可以访问但流量很少时，我们有一个例行的 DBCC CHECKDB 在晚上运行。自上个月以来，我们有几次 DBCC CHECKDB 因此错误而崩溃：
由于错误状态 5，sqladmin 执行的带 no_infomsgs 的 DBCC CHECKDB (Database1) 异常终止。经过时间：0 小时 47 分 9 秒。
这之前有几个 SQL Alert Severity 17，这是资源不足，以及 SQL 服务器日志中 DBCC MEMORYSTATUS 的输出。因此我认为 DBCC CHECKDB 崩溃是由于内存不足。
再次运行 DBCC CHECKDB 不会返回错误。一个非 DBA 甚至在工作时间做了一次，虽然拖累了性能，花了将近 3 个小时才完成，但并没有导致内存问题。（他被告知不要再这样做了）。
服务器本身有 12GB 的 RAM，但没有为 SQ 服务器设置最小和最大限制。SQL Server 本身使用大约 10GB 内存，而所有其他进程使用 1GB。当时我不知道有什么其他事情对服务器征税。
编辑：
- 没有设置最小或最大内存限制，原始问题缺少关键字“否”
- temp DB 有足够的增长空间
- 任何卷上都没有磁盘空间警报，所以我认为磁盘空间不是问题
- 数据库大小约为 50GB
- 我不知道除 Windows 更新之外的任何系统更改
- 通常 CHECKDB 在晚上需要 60-90 分钟才能完成