Estratégia de DBCC CHECKDB: última verificação bem-sucedida, divisão do trabalho, interpretação dos resultados

Comando

-- 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;

O que faz

Mostra a hora do último CHECKDB bem-sucedido de cada banco de dados, estima o tempdb necessário, permite dividir a verificação de bancos grandes em partes CHECKALLOC + CHECKCATALOG + CHECKTABLE e retorna os resultados como linhas (objeto, índice, página).

Quando usar

Ao auditar a manutenção, para bancos de dados muito grandes que não cabem na janela de manutenção ou ao determinar a extensão da corrupção após 823/824.

Atenção

A frase "repair_allow_data_loss is the minimum repair level" no resultado significa que o reparo vai apagar dados; considere primeiro um restore a partir de um backup bom (ou page restore). Se apenas índices nonclustered (index_id > 1) forem afetados, remover e recriar o índice resolve sem perda de dados. Após encontrar corrupção, investigue o subsistema de disco. PHYSICAL_ONLY pula as verificações lógicas; um CHECKDB completo continua sendo necessário periodicamente. Ao dividir com CHECKTABLE, a cobertura fica incompleta a menos que CHECKALLOC/CHECKCATALOG também rodem.