Когда я бегу DBCC CHECKDB, Я получаю множество таких сообщений об ошибках:
Ошибка таблицы: идентификатор объекта 2020918271, идентификатор индекса 1, идентификатор раздела 72057594196590592, идентификатор единицы распределения 72057594190233600 (тип данных в строке), страница (4: 129574), строка 0. Ошибка проверки записи (допустимый столбец UDT). Значения 3 и 0.
Щас просто пытаюсь понять, что это за ошибка средства и насколько это серьезно - похоже, это какая-то ошибка, связанная с контрольной суммой, и, вероятно, не такая серьезная. Похоже, что недавние резервные копии имеют ту же проблему, но в любом случае это не имеет большого значения, потому что данные можно воссоздать из других источников.
В любом случае, я пытаюсь разобраться в этом, возможно, понять, какие строки повреждены, если в этом есть какой-то конкретный шаблон. Когда я бегу DBCC PAGE чтобы увидеть, что там, например, следующее утверждение:
DBCC PAGE('MyDB', 4, 129574, 3)
Ничего не показывает. Нада. Почтовый индекс. Просто стандарт:
Выполнение DBCC завершено. Если DBCC распечатал сообщения об ошибках, обратитесь к системному администратору.
Но ни ошибки, ни данных страницы. По факту, каждая ошибка это выходит из CHECKTABLE имеет номер файла / страницы, для которого я получаю этот вывод из PAGE.
Я также вижу следующую ошибку из CHECKTABLE вывод, но только спорадически:
Ошибка таблицы: идентификатор объекта 2020918271, идентификатор индекса 1, идентификатор раздела 72057594196590592, идентификатор единицы распределения 72057594190233600 (тип данных в строке). Страница (4: 129575) не была замечена при сканировании, хотя ее родительский (4: 129977) и предыдущий (4: 129574) ссылаются на нее. Проверьте все предыдущие ошибки.
Похоже, это может быть связано, но я не совсем уверен, как. UDT может быть относительно большим (около 5 КБ), поэтому, возможно, он разделен по страницам, и одна из страниц отсутствует? Хотя это просто дикая догадка.
Количество ошибок, исходящих из CHECKTABLE также выглядит так, как будто вся таблица такая, но я знаю, что это не так, потому что я могу нормально читать данные. Фактически, есть автоматизированный процесс, который запускается каждый день, который со временем считывает практически все данные в этой таблице, и он не сообщил ни одной ошибки. Также, если я бегу DBCC PAGE на одной из родительских страниц (которые существуют, хотя «предыдущие» страницы нет), я могу получить ключевые столбцы, и я могу SELECT все данные для всех окружающих ключей без ошибок.
Кто-нибудь может сказать мне, что здесь происходит? Имеет ли это смысл для DBCC CHECKTABLE выдавать мне эти ошибки, когда упомянутые страницы даже не существуют? Возможно ли, что CHECKTABLE сам выдает ложные ошибки?
Вы включили флаг трассировки DBCC TRACEON(3604)? В противном случае вывод oll DBCC PAGE попадает только в журнал ошибок.