DBCC CHECKDB жизненно важен для баз данных SQL Server, чтобы быть на 100% уверенными в отсутствии коррупции. Однако из-за огромного размера баз данных очень сложно найти окно обслуживания, когда вы заявляете, что работаете 24x7. За прошедшие годы команда SQL Server внедрила различные механизмы, которые будут выявлять наиболее распространенные формы повреждений, особенно связанных с физическим повреждением, вызванным оборудованием.
SQL Server 2005 и выше имеет PAGE_VERIFY = CHECKSUM, что может помочь вам заранее обнаруживать физическое повреждение на страницах базы данных, тем самым добавляя контрольную сумму на каждую страницу, когда она записывается в систему ввода-вывода, и проверяет контрольную сумму, когда она читается с диска.
Кроме того, резервное копирование (полное или дифференциальное) с помощью CHECKSUM гарантирует обнаружение любого повреждения ввода-вывода, вызванного аппаратным обеспечением.
Следовательно, с аппаратной стороны коррупции, SQL Server хорошо обнаруживает и сообщает об этом. (Убедитесь, что вы также установили важные оповещения о коррупции ).
Это, как говорится, все еще логичное повреждение , вызванное ошибками скриблера - когда страницы в памяти повреждены либо сторонним кодом, выполняющимся внутри процесса SQL Server, либо драйверами или другим программным обеспечением с достаточными привилегиями, выполняющимися в режиме ядра Windows и / или SQL Server. Ошибки и т. Д. Не выявляются с помощью вышеуказанных методов, и, следовательно, CHECKDB входит в картину.
DBCC CHECKDB выполняет более тщательные проверки, которые включают проверку заголовков страниц на возможные повреждения, которые не обнаруживаются никакими другими средствами.
Есть какие-нибудь существующие сценарии?
Вместо того, чтобы изобретать велосипед, я настоятельно рекомендую вам взглянуть на решение Ola для проверки целостности SQL Server.
Эффективно работает DBCC CHECKDB:
Вам просто нужно проявить творческий подход, когда вы тесно работаете в окне обслуживания, имеющем огромные базы данных или большое количество баз данных для запуска CHECKDB.
После участия в тренинге по SQLSkills я реализовал в своей среде:
- расставьте приоритеты по тем таблицам, которые необходимо проверить.
- разделить таблицы на группы с различными приоритетами, а затем запустить
DBCC CHECKTABLEвместе с запуском DBCC CHECKALLOCиDBCC CHECKCATALOG
- Создайте рабочую таблицу, в которой будут храниться имена таблиц с приоритетами. Просто убедитесь, что все таблицы с высокими приоритетами (которые являются огромными) не входят в одну группу, иначе ваш CHECKDB не будет заполнен вообще.
- Вы даже можете иметь столбец тайм-аута в своей рабочей таблице, который будет управлять, когда ваш CHECKDB будет убит, когда он пройдет окно обслуживания.
- Добавьте, сколько времени потребовалось для каждой таблицы
DBCC CHECKTABLE, DBCC CHECKALLOCи DBCC CHECKCATALOG. Чтобы вы могли понять, сколько времени обычно уходит на проверку.
- Вы даже можете запустить с
NOINDEXпараметром, так как он ускорит работу, поскольку он не проверяет некластеризованные индексы в пользовательских таблицах. Это имеет некоторые преимущества, так как не так критично, как повреждение данных, поскольку данные не теряются, и вы можете удалить и заново создать индекс, если это необходимо.
Очевидно, что редакция Enterprise может использовать преимущества параллельного выполнения операторов DBCC, но обратите внимание на настройку MAXDOP, так как она может в конечном итоге занять весь ваш ЦП. Это может быть жестко ограничено управляющим ресурсами.
Примечание. Если у вас есть столбец SPARSE, то ваш CHECKDB будет работать очень медленно, как описано здесь .
Наконец, как предотвратить повреждение базы данных, используя весь доступный набор инструментов + вашу веру в аппаратную систему сервера базы данных и, самое главное, ценность ваших данных.
Несколько отличных ссылок: