Почему DBCC CHECKTABLE сообщает об ошибках на несуществующих страницах?

Когда я бегу DBCC CHECKDBЯ получаю множество сообщений об ошибках, как это:

Ошибка таблицы: идентификатор объекта 2020918271, идентификатор индекса 1, идентификатор раздела 72057594196590592, идентификатор единицы выделения 72057594190233600 (тип данных в строке), страница (4:129574), строка 0. Ошибка проверки записи (допустимый столбец UDT). Значения 3 и 0.

Сейчас я просто пытаюсь понять, что означает эта ошибка и насколько она серьезна - похоже, это ошибка, связанная с контрольной суммой, и, вероятно, не такая серьезная. Недавние резервные копии, похоже, имеют ту же проблему, но в любом случае это не имеет большого значения, потому что данные могут быть воссозданы из других источников.

Во всяком случае, я пытаюсь разобраться в этом, может быть, понять, какие строки повреждены, если есть какой-то конкретный шаблон для этого. Когда я бегу DBCC PAGE чтобы увидеть, что там, например, следующее утверждение:

DBCC PAGE('MyDB', 4, 129574, 3)

Ничего не показывает Нада. Zip. Просто стандарт:

Выполнение DBCC завершено. Если DBCC напечатал сообщения об ошибках, обратитесь к системному администратору.

Но нет ошибок и нет данных страницы. На самом деле, каждая ошибка, которая выходит из CHECKTABLE имеет номер файла / страницы, для которого я получаю этот вывод PAGE,

Я также вижу следующую ошибку от CHECKTABLE выходной, но только время от времени:

Ошибка таблицы: идентификатор объекта 2020918271, идентификатор индекса 1, идентификатор раздела 72057594196590592, идентификатор блока выделения 72057594190233600 (тип In-row data). Страница (4:129575) не была видна на скане, хотя его родитель (4:129977) и предыдущий (4: 129574) ссылаются на него. Проверьте все предыдущие ошибки.

Похоже, это может быть связано, но я не совсем уверен, как. UDT может быть относительно большим (около 5 КБ), поэтому, может быть, он разбит по страницам, и одна из страниц отсутствует? Это просто дикая догадка, хотя.

Количество ошибок, выходящих из CHECKTABLE также выглядит так, как будто вся таблица похожа на это, но я знаю, что это не так, потому что я могу читать данные очень хорошо. Фактически, существует автоматизированный процесс, который запускается каждый день, который со временем прочитает почти все данные в этой таблице, и он не сообщил ни об одной ошибке. Также, если я бегу DBCC PAGE на одной из родительских страниц (которые существуют, даже если "предыдущие" страницы не существуют), я могу получить ключевые столбцы, и я могу SELECT все данные для всех окружающих ключей без каких-либо ошибок.

Кто-нибудь может сказать мне, что здесь происходит? Имеет ли это смысл для DBCC CHECKTABLE давать мне эти ошибки, когда упомянутые страницы даже не существуют? Возможно ли, что CHECKTABLE сам испускает ложные ошибки?