Estrategia de DBCC CHECKDB: última comprobación correcta, división del trabajo, interpretación de 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;

Qué hace

Muestra la hora del último CHECKDB correcto de cada base de datos, estima el tempdb necesario, permite dividir la comprobación de bases de datos grandes en piezas CHECKALLOC + CHECKCATALOG + CHECKTABLE y devuelve los resultados como filas (objeto, índice, página).

Cuándo usarlo

Al auditar el mantenimiento, para bases de datos muy grandes que no caben en la ventana de mantenimiento o al determinar el alcance de la corrupción tras 823/824.

Precaución

La frase "repair_allow_data_loss is the minimum repair level" en el resultado significa que la reparación borrará datos; considere primero una restauración desde un backup bueno (o una restauración de páginas). Si solo están afectados índices nonclustered (index_id > 1), eliminar y recrear el índice lo resuelve sin pérdida de datos. Tras encontrar corrupción, investigue el subsistema de disco. PHYSICAL_ONLY omite las comprobaciones lógicas; sigue siendo necesario un CHECKDB completo periódicamente. Al dividir con CHECKTABLE, la cobertura es incompleta salvo que también se ejecuten CHECKALLOC/CHECKCATALOG.