Стратегия DBCC CHECKDB: последняя успешная проверка, разбиение работы, интерпретация результатов

Команда

-- Last successful CHECKDB (1900-01-01 = never):
SELECT name, DATABASEPROPERTYEX(name, 'LastGoodCheckDbTime') AS last_good_checkdb
FROM   sys.databases
WHERE  state_desc = N'ONLINE' AND name <> N'tempdb'
ORDER BY last_good_checkdb;

-- Estimated tempdb requirement:
DBCC CHECKDB (N'Musteri') WITH ESTIMATEONLY;

-- Split a large DB across days: allocation + catalog + table by table CHECKTABLE
USE [Musteri];
DBCC CHECKALLOC (N'Musteri') WITH NO_INFOMSGS;
DBCC CHECKCATALOG (N'Musteri') WITH NO_INFOMSGS;
DBCC CHECKTABLE (N'dbo.Siparis') WITH NO_INFOMSGS, ALL_ERRORMSGS;

-- Get results as rows (error rows with object and page):
DBCC CHECKDB (N'Musteri') WITH TABLERESULTS, NO_INFOMSGS, ALL_ERRORMSGS, MAXDOP = 4;

Что делает

Показывает время последнего успешного CHECKDB для каждой базы, оценивает нужный объём tempdb, позволяет разбить проверку больших баз на части CHECKALLOC + CHECKCATALOG + CHECKTABLE и возвращает результаты в виде строк (объект, индекс, страница).

Когда использовать

При аудите обслуживания, для очень больших баз, не укладывающихся в окно обслуживания, или для определения масштаба повреждения после 823/824.

Внимание

Фраза "repair_allow_data_loss is the minimum repair level" в результате означает, что исправление удалит данные; сначала рассмотрите восстановление из исправной резервной копии (или восстановление страниц). Если затронуты только некластеризованные индексы (index_id > 1), удаление и повторное создание индекса устраняет проблему без потери данных. После обнаружения повреждения исследуйте дисковую подсистему. PHYSICAL_ONLY пропускает логические проверки; полный CHECKDB всё равно нужен периодически. При разбиении через CHECKTABLE покрытие неполное, если не выполняются также CHECKALLOC/CHECKCATALOG.