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 も実行しないと網羅性が不完全になる。