Я включаю DBCC CHECKDB в нашей среде OLTP (SQL 2005,2008). Системные накладные расходы - очень заметная вещь на наших серверах, поэтому я хочу, чтобы они были настолько эффективными, насколько это имеет для них смысл. НАСКОЛЬКО - Я хочу включить опцию NOINDEX, опцию, которую я никогда раньше не использовал. Мои мысли таковы: если есть проблема с индексом, обнаруженная вне проверки целостности, я могу просто перестроить индекс. Также будет значительно сокращена продолжительность проверок целостности и будут обнаружены более опасные повреждения.
В чем заключается недостаток моего плана?
Спасибо, Деб
DBCC CHECKDB необходимо выполнять в нерабочее время или в периоды низкой нагрузки. В огромной базе данных он (по замыслу) настолько сильно ударит по дисковой подсистеме сервера, что станет практически непригодным для использования. Ему необходимо прочитать каждую страницу в базе данных. Использование опции NOINDEX не очень помогает, потому что вам нужно проверить, что ни один из (перестраиваемых) индексов не поврежден. Если один из них был поврежден, ошибки могли быть возвращены в ваши приложения или внутри процедур / транзакций. Если все эти ошибки не обрабатываются должным образом кодом или процедурами вашего приложения (то есть, при правильном откате вложенных транзакций), вы можете получить логичный повреждение данных (например, дебет без кредита в системе учета).
Мы еженедельно выполняем CHECKDB для всех баз данных в предрассветные часы воскресного утра, так как тогда их использование очень мало. Для наших самых крупных и наиболее часто используемых круглосуточных операций мы запускаем DBCC CHECKTABLE вместо этого с WAITFOR между таблицами, чтобы минимизировать влияние на конечного пользователя. Если вы пойдете по этому маршруту, вам также необходимо периодически запускать DBCC CHECKALLOC и DBCC CHECKCATALOG в базе данных (они включены в полную CHECKDB).
Наконец, если вы столкнулись с какой-либо формой повреждения базы данных SQL Server, вам необходимо немедленно посмотреть на стек оборудования вашего хранилища. Мы не видели никаких повреждений БД со времен SQL 6.5 еще в 1990-х годах в нашем магазине, и у нас есть десятки SQL-серверов большого объема. Единственный раз, когда я видел повреждение БД в SQL 7 и более поздних версиях, было из-за неисправного RAID-контроллера на сайте клиента (Promise действительно отстой).
Недостатка нет, но вы рискуете, что нарушение целостности некластеризованного индекса может повлиять на конечного пользователя или приложение, вы не потеряете никаких данных, но это может повлиять на восстановление индекса.
Если производительность очень важна, запускайте полные резервные копии ежедневно, выполняйте восстановление на другом сервере и выполняйте проверку копии.