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" 문구는 복구 시 데이터가 삭제됨을 의미하므로 먼저 정상 백업에서 복원(또는 페이지 복원)을 고려한다. nonclustered 인덱스(index_id > 1)만 영향을 받았다면 인덱스를 삭제 후 재생성하여 데이터 손실 없이 해결된다. 손상을 발견한 후에는 디스크 서브시스템을 조사한다. PHYSICAL_ONLY는 논리 점검을 건너뛰므로 전체 CHECKDB도 주기적으로 필요하다. CHECKTABLE로 분할할 때 CHECKALLOC/CHECKCATALOG도 실행하지 않으면 점검 범위가 불완전하다.