Stratégie DBCC CHECKDB : dernier contrôle réussi, découpage du travail, interprétation des résultats

Commande

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

Ce que fait la commande

Affiche l'heure du dernier CHECKDB réussi pour chaque base, estime l'espace tempdb nécessaire, permet de découper le contrôle des grandes bases en CHECKALLOC + CHECKCATALOG + CHECKTABLE, et renvoie les résultats sous forme de lignes (objet, index, page).

Quand l'utiliser

Lors de l'audit de la maintenance, pour les très grandes bases qui ne tiennent pas dans la fenêtre de maintenance, ou pour déterminer l'étendue d'une corruption après 823/824.

Attention

La phrase "repair_allow_data_loss is the minimum repair level" dans le résultat signifie que la réparation supprimera des données ; envisagez d'abord une restauration depuis une bonne sauvegarde (ou une restauration de pages). Si seuls des index nonclustered (index_id > 1) sont touchés, supprimer et recréer l'index corrige le problème sans perte de données. Après avoir trouvé une corruption, examinez le sous-système disque. PHYSICAL_ONLY saute les contrôles logiques ; un CHECKDB complet reste nécessaire périodiquement. En découpant avec CHECKTABLE, la couverture est incomplète si CHECKALLOC/CHECKCATALOG ne sont pas exécutés aussi.