La commande de console de base de données CHECKDB (DBCC CHECKDB)est utilisée pour vérifier l’intégrité (physique & logique) des objets dans une base de données SQL Server.La commande est prise en charge dans les bases de données qui contiennent des tables optimisées en mémoire, mais la validation n’est prise en charge que dans les tables sur disque. L’option DBCC repair n’est pas disponible dans les tables optimisées en mémoire et conduit donc à la nécessité d’une sauvegarde régulière de la base de données.En cas de problème dans une table optimisée en mémoire, les données peuvent être restaurées à partir de la dernière sauvegarde effectuée.
Les différentes opérations qui sont effectuées par CHECKDB sont :
- DBCC CHECKALLOC exécution sur la base de données SQL.
- DBCC CHECKTABLE exécution sur chaque table et vue de la base de données SQL.
- DBCC CHECKCATALOG exécution sur la base de données SQL.
- Validation du contenu dans la vue indexée de la base de données.
- Validation de la cohérence au niveau des liens parmi les répertoires de fichiers et les métadonnées des tables.
- Validation des données du courtier de services.
Puisque DBCC CHECKDB exécute toutes les autres commandes, il ne sera pas nécessaire d’exécuter séparément les commandes CHECKALLOC, CHECKTABLE et CHECKCATALOG.
Syntaxe de DBCC CHECKDB
Les arguments utilisés dans la syntaxe ci-dessus signifient ce qui suit :
nom_de_base | id_de_base | 0 C’est le nom de la base de données.Au cas où le nom n’est pas signifié ou que seul 0 est écrit, alors la base de données actuelle est utilisée. NOINDEX Il spécifie que le contrôle d’intégrité des tables d’index non clusterisées ne doit pas être effectué. Cette syntaxe n’affecte pas les données résidant dans les tables. REPAIR_ALLOW_DATA_LOSS Cette syntaxe répare les erreurs qui sont trouvées dans la base de données.Cela peut conduire à la perte de certaines données.
Note : Cette syntaxe est supportée par Microsoft et ne s’avère pas à chaque fois être une solution idéale pour remettre la base de données dans un bon état physique. En effet, elle supprime l’ensemble des données qui s’avèrent être corrompues et peut entraîner une perte de données plus importante, que ce qui a été fait à l’origine sur la base de données.Par conséquent, elle doit être adoptée en dernier recours.
REPAIR_FAST Cet argument maintient uniquement la rétrocompatibilité et n’effectue aucune réparation. REPAIR REBUILD Cet argument inclut un processus de réparation plus rapide qui n’impose aucune menace de perte de données. ALL_ERRORMSGS Cet argument montre toutes les erreurs qui sont générées dans tous les objets. L’inclusion ou l’exclusion de cette syntaxe n’aura aucun effet car les messages d’erreur sont généralement triés par l’ID de l’objet. Le nombre maximum de messages d’erreur générés peut atteindre 1000. EXTENDED_LOGICAL_CHECKS Cet argument exécute un contrôle de cohérence logique sur les vues et les index, uniquement si le niveau de compatibilité est de 100. NO_INFOMSGS Il supprime tous les messages d’information. TABLOCK Cette syntaxe permet d’obtenir un verrou exclusif sur la base de données et augmente la vitesse de DBCC CHECKDB sur une base de données en cas de forte charge. Mais elle diminue la disponibilité de la base de données pour les opérations simultanées. ESTIMATEONLY Indique ou estime l’espace nécessaire à la base de données pour exécuter la commande CHECKDB. PHYSICAL_ONLY Cette option limite la vérification à la structure physique de la base de données. Une brève vérification de la base de données physique s’accompagne de la détection de pages déchirées, de pannes et de problèmes courants rencontrés par les utilisateurs. PURETÉ DES DONNÉES Cette syntaxe vérifie les valeurs de colonne qui sont hors de la plage ou qui ne sont pas valides. Les contrôles d’intégrité des valeurs de colonnes sont activés par défaut et ne nécessitent pas la syntaxe DATA_PURITY.
Ce qu’il faut garder à l’esprit
- Les index désactivés ne peuvent pas être vérifiés par DBCC CHECKDB.
- Les types définis par l’utilisateur et ordonnés par octet doivent être sérialisés si DBCC CHECKDB doit être exécuté. Dans tout autre cas, l’erreur 2537 se produit.
- DBCC CHECKDB ne peut pas être exécuté directement sur une base de données de ressources car elle ne peut être modifiée qu’en mode unique.
Messages d’erreur générés par DBCC CHECKDB
Lorsque l’exécution de la commande CHECKDB est terminée, un message est écrit dans le journal des erreurs SQL. En cas de succès, elle génère un message indiquant le succès et la durée totale d’exécution de la commande. En cas d’échec, le processus est interrompu en raison de l’apparition d’une erreur, comme l’indique un message. Les différentes valeurs d’état qui représentent le message d’erreur sont :
Rapport d’erreur
Chaque fois qu’une corruption est détectée par la commande CHECKDB, un fichier de vidage nommé SQLDUMPNNNN.txt est créé dans le répertoire de journalisation du serveur SQL. Dans le cas où la fonctionnalité de collecte de données d’utilisation et le rapport d’erreur sont activés dans SQL, le rapport d’erreur est envoyé à Microsoft à des fins d’amélioration.
Restauration de la base de données
Dans le scénario de génération d’erreur dans le serveur SQL, il est recommandé de restaurer la base de données à partir de la dernière sauvegarde créée au lieu de réparer la base de données.Dans le cas où aucune sauvegarde n’existe, vous pouvez aller pour les options de réparation. Mais opter pour la réparation avec REPAIR_ALLOW_DATA_LOSS peut conduire à la suppression de certaines données.
Résolution alternative pour la récupération de la base de données
Basiquement, la commande DBCC CHECKDB vérifie les cohérences de la base de données, y compris physique ou logique. Cette commande vérifie les pages, l’index et certains autres composants de la base de données du serveur SQL, mais à certains points critiques, cette option refuse de récupérer la base de données SQL. En cas d’absence de sauvegarde de la base de données MS SQL, les options de réparation choisies peuvent supprimer une quantité appréciable de données. Par conséquent, afin de récupérer la base de données sans compromettre l’intégrité des données, vous pouvez opter pour une solution de récupération de la base de données Microsoft SQL. Ils garantissent une récupération complète de la base de données sans supprimer aucune quantité de données.