Далі йде збірка результатів, про які я читав. Ви знайдете набагато більше інформації у пов'язаних блогах та документах.
По-перше, може статися, що 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.