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