Разделение 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 в базе данных.

Итак, вот мои вопросы:

  1. Есть ли способы выполнить эти дополнительные проверки отдельно? Должен ли я беспокоиться об этом? (Индексированные представления, вероятно, более важны для меня, чем два других)

  2. Какие-либо существенные изменения, которые мне нужно внести в мою стратегию, если я хочу реализовать это в базах данных SQL2000, 2005 и 2008?

  3. 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) Если время не вызывает сползания в окно доступности производства, то почему бы и нет?

Другие вопросы по тегам