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