当我运行时DBCC CHECKDB，我收到一系列如下错误消息：
表错误：对象 ID 2020918271，索引 ID 1，分区 ID 72057594196590592，分配单元 ID 72057594190233600（类型为行内数据），页（4：129574），行 0。记录检查（有效 UDT 列）失败。值为 3 和 0。
现在我只是想了解这个错误方法以及它的严重程度 - 这似乎是一些与校验和相关的错误，可能没有那么严重。最近的备份似乎有同样的问题，但无论如何这都不是大问题，因为可以从其他来源重新创建数据。
无论如何，我正在尝试弄清楚这个问题，也许可以了解哪些行已损坏，以及是否存在任何特定模式。当我运行DBCC PAGE以查看其中的内容时，例如以下语句：
DBCC PAGE('MyDB', 4, 129574, 3)
它什么都没显示。什么也没有。只有标准：
DBCC 执行已完成。如果 DBCC 打印了错误消息，请联系系统管理员。
但没有错误，也没有页面数据。事实上，每一个错误出来的CHECKTABLE是具有文件/页码的文件/页码，我从中获取了此输出PAGE。
我还从输出中看到以下错误CHECKTABLE，但只是偶尔出现：
表错误：对象 ID 2020918271，索引 ID 1，分区 ID 72057594196590592，分配单元 ID 72057594190233600（类型为行内数据）。页面 (4:129575) 未在扫描中显示，尽管其父页面 (4:129977) 和上一个页面 (4:129574) 引用了该页面。检查之前的任何错误。
看起来可能相关，但我不太确定具体原因。UDT 可能相对较大（大约 5 KB），所以也许它分散在多个页面中，而其中一个页面丢失了？不过，这只是一个大胆的猜测。
出现的错误数量CHECKTABLE也使整个表看起来好像都是这样的，但我知道事实并非如此，因为我可以很好地读取数据。事实上，每天都有一个自动过程运行，随着时间的推移，它将读取该表中的所有数据，并且它没有报告任何错误。此外，如果我在DBCC PAGE其中一个父页面（确实存在，即使“前一个”页面不存在）上运行，我可以获取关键列，并且可以获取SELECT所有周围键的所有数据而不会出现任何错误。
DBCC CHECKTABLE有人能告诉我这是怎么回事吗？当引用的页面根本不存在时，出现这些错误是否合理？它CHECKTABLE本身是否可能发出虚假错误？
答案1
您是否打开了跟踪标志DBCC TRACEON(3604)？否则，所有 DBCC PAGE 输出都只会进入错误日志。