Я работаю над реализацией метода Пола Рэндала по ручному распространению DBCC CHECKDB в течение нескольких дней из его превосходной статьи. CHECKDB со всех сторон: параметры проверки согласованности для VLDB. Короче говоря, стратегия состоит из:
я получил отдельный вопрос StackOverflow относительно хорошего алгоритма для разделения таблиц на сегменты (звоните туда, если у вас есть рабочий сценарий TSQL), но этот вопрос заключается в том, чтобы убедиться, что я проверяю правильные вещи. Электронная документация по CHECKDB говорит, что помимо выполнения CHECKALLOC, CHECKCATALOG и CHECKTABLE, он также:
Итак, вот мои вопросы:
Есть ли способы выполнить эти дополнительные проверки отдельно? Стоит ли мне вообще об этом беспокоиться? (Индексированные представления, вероятно, вызывают у меня более непосредственное беспокойство, чем два других)
Какие-либо существенные изменения, которые мне нужно внести в свою стратегию, если я хочу реализовать это в базах данных SQL2000, 2005 и 2008?
CHECKALLOC и CHECKCATALOG, кажется, работают довольно быстро. Есть ли причина не запускать эти 2 проверки каждый день?
Спасибо!
Вы говорите, что это широкая реализация - если у вас действительно нет окна, а все базы данных являются VLDB (10 ТБ +), мне кажется, что это слишком усложняет ситуацию. Если большинство ваших экземпляров достаточно малы, запустите стандартное задание checkDB - и просто сделайте специальное задание для действительно больших баз данных. Они должны быть исключениями.
Вы думали о том, чтобы выполнить checkDBs против восстановления в предварительном продакшене? или только физически_ только большую часть времени? Или выполните checkDB для файла резервной копии с помощью стороннего инструмента, такого как Redgate SQL Virtual Restore.
Не знаете, как бы вы выполняли проверки в 1), возможно, просмотрите CHECKDB в Profiler, чтобы увидеть, что выполняется для этих проверок под обложками, и посмотреть, не является ли этот код чем-то, что можно дублировать?
Что касается пункта 2), и хотя я склонен думать о разделении на основе времени (ежемесячно), например, для приложения главной книги, я бы поместил таблицы в файловые группы на основе критичности (более критично - менее критично, более активно используется для менее активно используемого и т. Д. ) для вас больше смысла? Это предполагает, что группа таблицы с интенсивным трафиком в этом месяце будет такой же в следующем месяце. Возможно, значение used_page_count из DMV sys.dm_db_partition_stats поможет подтвердить исходное размещение таблицы в файловую группу.
3) Если время не вызывает сползания в доступное для производства окно, почему бы и нет?