Какие виды коррупции может пропустить DBCC CheckDB?

Этот вопрос был вызван этим предыдущим сообщением, и моя база данных была сохранена для дальнейшего расследования, которое было восстановлено после:

BACKUP 'BrokenDatabase' detected an error on page (1:123456) in file ’BrokenDatabase.mdf'.
Error: 3043, Severity: 16, State: 1.

В связанном вопросе и резервной копии, которую я готов для исследований DBCC PAGE, DBCC CHECKDB прошел без ошибок, но очевидно, что имеется повреждение.

Какие типы коррупции могут возникнуть, когда CHECKDB пройдет, но BACKUP WITH CHECKSUM потерпит неудачу?

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

Во-первых, может случиться так, что DBCC CHECKDBвы не обнаружите несоответствия, если вы отключите проверку контрольной суммы или torn_page. Цитата из Пола Рэндала в этом посте :

Вы правы - если рваная страница или контрольная сумма не включены, то нет ничего, что можно было бы обнаружить с точки зрения защиты страницы. CHECKDB может по-прежнему обнаруживать повреждения, обнаруженные при выполнении всех проверок согласованности, которые он выполняет, но, например, он не увидит повреждений в середине значений данных.

Ха - это облом при включении контрольных сумм страниц - ничего не происходит, пока страница не будет прочитана, изменена и выписана обратно. Единственный способ заставить страницы получать контрольные суммы - это изменить их - например, путем перестройки всех ваших индексов, что может быть неприятно - вообще не существует инструмента «касания».

Вышеописанная ситуация может ударить вас, если вы обновили базу данных с SQL Server 2000 или более ранней версии до 2005 или более поздней. Затем вам нужно вручную включить контрольные суммы страниц с помощью ALTER DATABASE, чтобы они стали активными. Но затем вступает в силу второй абзац вышеприведенной цитаты, который может вас беспокоить.

BACKUP WITH CHECKSUMобнаружит несоответствия контрольной суммы, но только если на страницу уже была записана контрольная сумма, когда выполняется резервное копирование. Обычно DBCC CHECKDBтакже обнаруживает эти ошибки, поэтому не рекомендуется использовать BACKUP WITH CHECKSUM для замены DBCC CHECKDB .

Теперь есть вторая возможность DBCC CHECKDBне показывать какие-либо несоответствия, даже если они есть. Для этого я просто цитирую Пола Рэндала в « Заблуждениях о коррупции»: могут ли они исчезнуть? :

Так что насчет исчезающих коррупций? Это касается того, как работают проверки согласованности. Проверка согласованности выполняется только на тех страницах в базе данных, которые выделены. Если страница ни для чего не выделена, то ее 8192 байта не имеют смысла и не могут быть интерпретированы. Не путайте между зарезервированным и выделенным - я объясняю это в первом посте заблуждений здесь. Пока страница выделена, DBCC CHECKDB будет проверять согласованность, включая проверку контрольной суммы страницы, если она существует. Повреждение может казаться «исчезающим», если поврежденная страница выделяется во время выполнения DBCC CHECKDB, но затем освобождается к моменту следующего запуска DBCC CHECKDB. В первый раз он будет объявлен как поврежденный, но во второй раз он не будет выделен, поэтому он не будет проверен на непротиворечивость и не будет зарегистрирован как поврежденный. Коррупция выглядит таинственно исчезнувшей. Но это не так, просто поврежденная страница больше не выделяется. Ничто не мешает SQL Server освободить поврежденную страницу - на самом деле это то, что делают многие из исправлений DBCC CHECKDB - освободить то, что сломано, и исправить все ссылки.

У меня нет окончательного ответа на ваш вопрос, но, поскольку он DBCC CHECKDBпроверяет только выделенные страницы, он не показывает несоответствия на освобожденных страницах. Единственная ситуация, которую я могу себе представить, заключается в том, что BACKUP также создает резервные копии тех освобожденных страниц, которые показывают потенциальные ошибки контрольной суммы, которые были пропущены DBCC CHECKDB.