DBCC CHECKDB: проверка целостности крупных баз данных SQL Server

Автор: SQLYARD, DBCC CHECKDB: Practical Integrity Checking for Large SQL Server Databases

DBCC CHECKDB — одна из важнейших команд в наборе инструментов администратора SQL Server. Она проверяет логическую и физическую целостность всех объектов базы данных, помогая выявлять повреждения на ранней стадии — до того, как они превратятся в кошмар восстановления.

В современных версиях, таких как SQL Server 2022, проверки «чистоты данных» (data purity) по умолчанию встроены в движок, CHECKDB может выполняться параллельно, использовать снимки (снапшоты) и даже запускаться на репликах. Тем не менее запустить эту команду на крупных базах данных в рамках коротких «окон» обслуживания бывает непросто.

В этом материале разобрано, когда и как эффективно запускать CHECKDB, как использовать подходящие параметры и как грамотно планировать его выполнение как для ежедневной эксплуатации, так и для готовности к аварийному восстановлению.

Почему важен DBCC CHECKDB

Повреждения данных могут возникать из‑за:

• проблем подсистемы хранения (битые сектора, ошибки SAN);
• отключений питания и сбоев;
• сбоев контроллеров памяти или диска;
• ошибок микропрограмм (firmware) или проблем на пути ввода‑вывода.

Даже в хорошо спроектированной инфраструктуре повреждения не всегда видны приложениям — до того момента, когда уже слишком поздно. DBCC CHECKDB действует как регулярная проверка здоровья, подтверждая корректность каждого распределения, структуры и страницы ваших данных.

Data Purity в SQL Server 2022

В более старых версиях SQL Server (до 2012) проверки «чистоты данных» необходимо было запускать явно:

DBCC CHECKDB ('YourDB') WITH DATA_PURITY;

Это обеспечивало соответствие хранимых значений типам данных и ограничениям столбцов.

Начиная с SQL Server 2012 новые базы данных автоматически контролируют «чистоту данных» на уровне движка. Полный CHECKDB уже включает эти проверки по умолчанию. Для баз, созданных или обновлённых из более ранних версий, разумно один раз выполнить WITH DATA_PURITY после миграции, чтобы убедиться в отсутствии «исторических» несоответствий.

Параметры, делающие CHECKDB практичным

Для небольшой базы данных CHECKDB запускается просто. Для огромных баз данных требуется планирование.

Наиболее полезные параметры:

Параметр	Что делает	Когда использовать
PHYSICAL_ONLY	Проверяет только распределение и физические структуры	Ежедневные/еженедельные «быстрые» сканы
NOINDEX	Пропускает проверку некластеризованных индексов	Когда индексы перестраиваются отдельно
ESTIMATEONLY	Оценивает требуемый объём TempDB/снимка	Для планирования запусков
MAXDOP = N	Управляет параллелизмом	Баланс времени выполнения и нагрузки на сервер
TABLOCK	Блокирует таблицы вместо использования снимка	Редко оправдано, применять с осторожностью

Пример:

DBCC CHECKDB ('SalesDB') 
WITH PHYSICAL_ONLY, NO_INFOMSGS, MAXDOP = 4;

Продвинутые настройки производительности

Для очень больших баз данных:

• Запускайте CHECKDB на отдельно созданном снимке (а не на снимке, который создаётся автоматом):

  CREATE DATABASE SalesDB_Snap ON 
  ( NAME = SalesDB_Data, FILENAME = 'F:\Snapshots\SalesDB_Data.ss' )
  AS SNAPSHOT OF SalesDB;
  DBCC CHECKDB (SalesDB_Snap) WITH NO_INFOMSGS, MAXDOP = 4;
  DROP DATABASE SalesDB_Snap;

  • Это переносит большую часть ввода‑вывода с боевых файлов на снимок.
• Переносите выполнение на читаемую вторичную реплику в группе доступности (AG).
• Используйте флаги трассировки 2562 и 2549 для уменьшения использования TempDB и оптимизации параллелизма (предварительно тестируйте).
• Проверяйте контрольные суммы страниц и делайте резервные копии с CHECKSUM, чтобы обнаруживать повреждения раньше, даже между запусками CHECKDB.

Лучшие практики

1. Ежедневно: запускайте проверку PHYSICAL_ONLY в период низкой нагрузки.

   DBCC CHECKDB ('SalesDB') WITH PHYSICAL_ONLY, NO_INFOMSGS;

2. Еженедельно: выполняйте более глубокую проверку с NOINDEX или частичную проверку по файловым группам, если база данных очень велика.

Ежемесячно: полный CHECKDB (со снимком или без него) в расширенное окно обслуживания.

После крупных операций (обновления версий, значимые ETL‑загрузки, миграции): всегда выполняйте полный CHECKDB.

Размер TempDB: убедитесь, что он может выдержать не менее 25% от размера базы при полных проверках.

Файловые группы: помогают ли они?

По умолчанию у каждой базы данных есть одна файловая группа: PRIMARY. Добавление дополнительных файловых групп само по себе не ускоряет CHECKDB.

Однако несколько файловых групп могут:

• позволить запускать проверку целостности по одной файловой группе с помощью DBCC CHECKFILEGROUP;
• снизить частоту проверок для статичных, доступных только для чтения данных (например, архивных секций);
• обеспечить более быстрое восстановление с помощью пофайлового (piecemeal) восстановления.

Такой подход имеет смысл для очень крупных, «уровневых» баз данных — но не для каждого окружения.

Удаление снимков

Всегда удаляйте снимки после выполнения CHECKDB:

DROP DATABASE YourDB_Snap;

Оставленные «висеть» снимки быстро займут место на диске и повлияют на производительность.

Заключение

• CHECKDB — ваша первая линия защиты от «тихих» повреждений.
• Нет необходимости запускать полные проверки каждую ночь. Многоуровневая стратегия защищает вас, не «съедая» всё окно обслуживания.
• Снимки, читаемые вторичные реплики и файловые группы — опциональные, но мощные инструменты для крупных баз.
• Всегда записывайте и анализируйте вывод CHECKDB. Не игнорируйте предупреждения — это ранние сигналы о возможных серьёзных проблемах.