SQL Server - Vérifier et réparer une base de donnée DBCC CHECKDB

Dans cet article j’explique comment vérifier et réparer une base de données SQL Server.
J’explique notamment comment faire la distinction entre les opérations et options qui peuvent potentiellement générer des PERTES DE DONNEES et celles qui ne génèrent pas de perte de données.

1 - Vérifier l’intégrité d’une base de données

La commande DBCC CHECHDB vérifie la cohérence et l’intégrité d’une base de données. Elle constitue la principale méthode de recherche d’une corruption dans la base. La commande DBCC CHECKDB effectue les vérifications suivantes :

• Les index et les pages de données sont liés correctement
• Les index sont à jour et trié correctement
• Les pointeurs sont cohérents
• Les données de chaque page sont à jour
• Les décalages de pages sont à jour
• Les vues indexées, les données varbinary(max) du système de fichiers à l’aide de FILESTREAM, sont cohérents et valides
• Les données du Service Broker sont valides

Exemple d’utilisation

DBCC CHECKDB (MaBase);

Remarque

Je vous recommande fortement de lancer la commande DBCC CHECKDB avant de sauvegarder votre base de données.

2 – Réparer une base de données

Lorsque la base de données est corrompue, la commande de vérification DBCC CHECKDB affiche les erreurs, comme le montre l’exemple ci-dessous :

…Object ID 2084575921, index ID 0, partition ID 72345201078903994, alloc unit ID 72326351571606 (type In-row data): Page (1:94299) could not be processed. See other errors for details. ….

Lorsque la base de données est corrompue, la meilleure solution est d’effectuer une restauration de la base de données depuis une sauvegarde (backup), et non pas de tenter de réparer la base de données !

La commande DBCC CHECKDB présente toutefois un certain nombre d’options qui peuvent être utilisées pour réparer la base de données. ATTENTION, certaines options peuvent générer des PERTES DE DONNEES et ne doivent être utilisées qu’en dernier recours.
Ci-dessous la liste des options et leur signification
- L’option REPAIR_FAST effectue les réparations mineures qui prennent peu de temps et n’amènes pas de perte de données.
- L’option REPAIR_BUILD procède à une vérification et à une réparation globale qui nécessite plus de temps mais sans risque de perte de données. L’option REPAIR_BUILD nécessite que la base de données soit en mode mono-utilisateur.
- L’option REPAIR_ALLOW_DATA_LOSS réalise toute les tâches de REPAIR_BUILD et ajoute les tâches supplémentaires pouvant conduite à une PERTE DE DONNÉES (Allocation et suppression de lignes pour corriger des problèmes structuraux et des erreurs de pages et suppression d’objets textes corrompus).

Remarques importantes

- Lorsque vous cherchez à résoudre des problèmes de base de données, commencez par REPAIR_FAST ou REPAIR_REBUILD. Si cela ne suffit pas, utilisez l’option REPAIR_ALLOW_DATA_LOSS, mais attention, ne perdez pas de vue que l’option REPAIR_ALLOW_DATA_LOSS peut conduire à une PERTE INACCEPTABLE DE DONNÉES IMPORTANTES. Je vous recommande fortement d’effectuer une sauvegarde de la base de données avant d’utiliser l’option REPAIR_ALLOW_DATA_LOSS
- Pour assurer la récupération de la base de données dans son état d’origine, je vous suggère de placer la commande DBCC dans une transaction pour examiner les résultats et annuler la transaction si nécessaire.

Exemple d’utilisation de la commande DBCC CHECKDB avec l’option REPAIR_REBUILD :

-- 1 - On positionne la base en mode mono-utilisateur 
ALTER DATABASE MaBase
   SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO

-- 2 - On lance la commande de réparation de la base, et ce, sans risque de perte de
--     données (REPAIR_REBUILD) 
DBCC CHECKDB (MaBase , REPAIR_REBUILD); 
GO

-- 3 - On remet la base en mode multi-utilisateurs  (si tout va bien !) 
ALTER DATABASE MaBase 
   SET MULTI_USER;
GO