Diagnostiquer et résoudre les erreurs de cohérence de base de données signalées par DBCC CHECKDB

Cet article explique comment résoudre les erreurs signalées par la commande DBCC CHECKDB.

Version du produit d’origine : SQL Server
Numéro de base de connaissances d’origine : 2015748

Symptômes

Lorsque DBCC CHECKDB (ou d’autres commandes similaires comme DBCC CHECKTABLE) est exécutée, un message comme celui-ci est écrit dans le journal des erreurs SQL Server :

DBCC CHECKDB (mydb) executed by MYDOMAIN\theuser found 15 errors and repaired 3 errors.
Elapsed time: 0 hours 0 minutes 0 seconds.
Internal database snapshot has split point LSN = 00000026:0000089d:0001 and first LSN = 00000026:0000089c:0001.
This is an informational message only. No user action is required.

Ce message indique combien d’erreurs de cohérence de base de données ont été détectées et combien ont été réparées, si une option de réparation a été utilisée. Ce message est également écrit dans le journal des événements de l’application Windows en tant que message de niveau information avec EventID=8957. Même si des erreurs sont signalées, ce message est un message d’information.

Les informations contenues dans le message commençant par « instantané de base de données interne... » s’affichent uniquement si DBCC CHECKDB a été exécuté en ligne, auquel cas la base de données n’est pas en mode SINGLE_USER. Cela est dû au fait que pour une base de données en ligne DBCC CHECKDB, un instantané de base de données interne est utilisé pour présenter un ensemble cohérent de données à vérifier.

Cet article ne décrit pas comment résoudre chaque erreur spécifique signalée par DBCC CHECKDB, mais plutôt l’approche générale si des erreurs sont signalées. Toute référence à CHECKDB dans cet article s’applique également à DBCC CHECKTABLE et à DBCC CHECKFILEGROUP, sauf indication contraire.

Cause

La commande DBCC CHECKDB vérifie la cohérence physique et logique des pages de base de données, des lignes, des pages d’allocation, des relations d’index, l’intégrité référentielle de table système et d’autres vérifications de structure. Si l’une de ces vérifications échoue (selon les options que vous avez choisies), les erreurs sont signalées.

La cause de ces problèmes peut aller de l’altération du système de fichiers, des problèmes de système matériel sous-jacent, des problèmes de pilote, des pages endommagées dans la mémoire ou le cache de stockage, ou des problèmes avec SQL Server. Pour plus d’informations sur l’identification de la cause racine des erreurs signalées, consultez Examiner la cause racine.

Résolution

  1. Résolvez les problèmes matériels sous-jacents sur le système avant de poursuivre la restauration d’une sauvegarde ou autrement réparer la base de données. Appliquez les mises à jour du pilote de périphérique, du microprogramme, du BIOS et du système d’exploitation pertinentes pour le chemin d’E/S. Collaborez avec l’administrateur du chemin d’E/S complet (ordinateur local, pilotes de périphérique, cartes réseau de stockage, SAN, stockage back-end et cache) et de la mémoire (RAM) pour isoler et résoudre les problèmes éventuels. Les exemples incluent la mise à jour des pilotes de périphérique et la vérification de la configuration de l’ensemble du chemin d’E/S. Pour plus d’informations sur l’examen de la cause racine, consultez Examiner la cause racine.

  2. Si DBCC CHECKDB signale des erreurs de cohérence permanentes, la meilleure solution consiste à restaurer des données à partir d’une sauvegarde correcte connue. Pour plus d’informations, consultez Restauration et récupération.

  3. Appliquez la dernière mise à jour cumulative SQL Server ou Service Pack pour vous assurer que vous ne rencontrez aucun problème connu. Consultez la documentation de la mise à jour cumulative ou du Service Pack pour connaître les problèmes connus résolus liés à l’altération de la base de données (erreurs de cohérence) et appliquez les correctifs pertinents. Un emplacement central où vous pouvez rechercher tous les correctifs d’une version particulière se trouvent dans les listes de correctifs détaillés pour SQL Server 2022, 2019, 2017.

  4. Si les DBCC CHECKDB erreurs sont intermittentes, c’est-à-dire si elles apparaissent sur une exécution et disparaissent lors de la prochaine exécution, vous pouvez rencontrer des problèmes de cache de disque (pilote de périphérique ou autre problème de chemin d’E/S). Collaborez avec les mainteneurs du chemin d’E/S pour isoler et résoudre les problèmes. Par exemple, la mise à jour des pilotes de périphérique, la vérification de la configuration de l’ensemble du chemin d’E/S et la mise à jour du microprogramme et du BIOS sur les périphériques du chemin d’E/S et sur le système.

  5. S’il n’est pas possible de restaurer à partir d’une sauvegarde, CHECKDB est doté d’une fonctionnalité permettant de réparer les erreurs que vous pouvez utiliser. Il existe deux niveaux de réparation :

    • REPAIR_REBUILD - effectue des réparations qui n’entraînent aucune perte de données.
    • REPAIR_ALLOW_DATA_LOSS - effectue des réparations qui ont la possibilité de perte de données.

    Pour plus d’informations, consultez la documentation DBCC CHECKDB.

    Vous devez faire preuve de prudence lorsque vous choisissez l’option de réparation « autoriser la perte de données », car cette opération peut laisser votre base de données dans un état logiquement incohérent. Le résultat DBCC CHECKDB fournit une recommandation sur le niveau de réparation minimal à utiliser. Il est courant d’exécuter CHECKDB avec REPAIR_ALLOW_DATA_LOSS plusieurs fois jusqu’à ce qu’aucune erreur supplémentaire ne soit signalée. Cela est dû au fait que lorsque la réparation corrige un ensemble d’erreurs, d’autres liens défectueux peuvent être découverts. Toutefois, de nouvelles erreurs peuvent s’afficher si la cause sous-jacente n’a pas été résolue. Par conséquent, si des problèmes de niveau système tels que le matériel ou le système de fichiers provoquent une altération des données, ces problèmes doivent d’abord être résolus avant la restauration d’une sauvegarde ou d’une réparation. Les ingénieurs du support technique Microsoft ne peuvent pas aider à récupérer physiquement des données endommagées si la réparation ne corrige pas les erreurs de cohérence ou si la sauvegarde de la base de données est endommagée.

    Lorsque vous exécutez DBCC CHECKDB, une recommandation est fournie pour indiquer l’option de réparation minimale requise pour réparer toutes les erreurs. Ces messages ressemblent à la sortie suivante :

    CHECKDB a détecté 0 erreurs d’allocation et 15 erreurs de cohérence dans la base de données « mydb ».
    REPAIR_ALLOW_DATA_LOSS est le niveau de réparation minimal pour les erreurs trouvées par DBCC CHECKDB (mydb).

    La recommandation de réparation est le niveau minimal de réparation pour tenter de résoudre toutes les erreurs provenant de CHECKDB. Le niveau de réparation minimal ne signifie pas que cette option de réparation corrige toutes les erreurs. Certaines erreurs ne peuvent simplement pas être corrigées. Vous devrez peut-être également exécuter le processus de réparation plusieurs fois. Toutes les erreurs signalées n’exigent pas la résolution de ce niveau de réparation. Cela signifie que toutes les réparations CHECKDB avec REPAIR_ALLOW_DATA_LOSS n’entraînent pas de perte de données. La réparation doit être exécutée pour déterminer si la résolution d’une erreur entraîne une perte de données. Une technique permettant de déterminer le niveau de réparation de chaque table consiste à utiliser DBCC CHECKTABLE pour toute table signalant une erreur. Cela indique le niveau minimal de réparation pour une table donnée.

    Avertissement

    Vous devez effectuer une validation manuelle des données une fois CHECKDB la réparation, l’exportation ou l’importation des données terminée. Pour plus d’informations, consultez les arguments DBCC CHECKDB. Les données peuvent ne pas être cohérentes logiquement après la réparation. Par exemple, la réparation (en particulier l’option REPAIR_ALLOW_DATA_LOSS) peut supprimer des pages de données entières qui contiennent des données incohérentes. Dans ce cas, une table avec une relation de clé étrangère à une autre table peut se retrouver avec des lignes qui n’ont pas de lignes correspondantes dans la table parente.

  6. Essayez de générer un script du schéma de la base de données. Utilisez le script pour créer une base de données, puis utilisez un outil tel que BCP ou l’Assistant Exportation/Importation SSIS pour exporter autant de données que possible de la base de données endommagée vers la nouvelle base de données. L’exportation de données à partir d’une table endommagée risque d’échouer. Dans ce cas, ignorez cette table, passez à la suivante et enregistrez ce que vous pouvez.

  7. Passez en revue les articles suivants pour connaître les erreurs spécifiques générées par DBCC CHECKDB et suivez les étapes fournies (le cas échéant). Voici quelques exemples :

Examiner la cause profonde des erreurs de cohérence de la base de données

Pour identifier la cause racine des erreurs de cohérence de base de données, tenez compte des méthodes suivantes :

  • Vérifiez le journal des événements système Windows pour connaître les erreurs liées au système, au pilote ou au disque, et collaborez avec votre fabricant de matériel pour les résoudre.
  • Exécutez les diagnostics fournis par les fabricants de votre matériel pour l’ordinateur et/ou le système de disque. La plupart des systèmes fournissent des diagnostics intégrés BIOS/UEFI pour le stockage (disques durs), la mémoire, les processeurs, les cartes système, les tableaux RAID et plusieurs autres composants.
  • Collaborez avec votre fournisseur de matériel ou votre fabricant d’appareils pour vous assurer que :
  • Envisagez d’utiliser un utilitaire tel que SQLIOSim sur le lecteur où se trouvent les bases de données qui ont signalé les erreurs de cohérence. SQLIOSim est un outil indépendant du moteur SQL Server pour tester l’intégrité des E/S pour le système de disque. SQLIOSim est fourni avec SQL Server et ne nécessite pas de téléchargement distinct. Il se trouve dans le dossier \MSSQL\Binn .
  • Consultez la documentation de la mise à jour cumulative ou du Service Pack pour connaître les problèmes connus résolus liés à l’altération de la base de données (erreurs de cohérence) et appliquer les correctifs pertinents. Un emplacement central où vous pouvez rechercher tous les correctifs d’une version particulière s’ils figurent dans les listes de correctifs détaillés pour SQL Server 2022, 2019, 2017.
  • Recherchez les autres erreurs signalées par SQL Server, telles que les violations d’accès ou les assertions. Toute opération sur des bases de données endommagées entraîne fréquemment des exceptions de violation d’accès ou des erreurs d’assertion.
  • Assurez-vous que vos bases de données utilisent l’option PAGE_VERIFY CHECKSUM . Si des erreurs de somme de contrôle sont signalées, il s’agit d’une indication que les erreurs de cohérence se sont produites après que SQL Server a écrit des pages sur le disque. Par conséquent, votre sous-système d’E/S doit être soigneusement vérifié. Pour plus d’informations sur les erreurs de somme de contrôle, consultez Comment résoudre les problèmes de msg 824 dans SQL Server.
  • Recherchez les erreurs de message 832 dans ERRORLOG. Ces erreurs peuvent indiquer que les pages peuvent être endommagées alors qu’elles sont en cache avant d’être écrites sur le disque dur. Pour plus d’informations, consultez Comment résoudre les problèmes liés à Msg 832 dans SQL Server.
  • Sur un autre système, essayez de restaurer une sauvegarde de base de données que vous savez « propre » (aucune erreur provenant de CHECKDB), suivie des sauvegardes du journal des transactions qui couvrent la période pendant laquelle l’erreur a été générée. Si vous pouvez « recréer » ce problème en restaurant une sauvegarde de base de données « propre » et une sauvegarde du journal des transactions, contactez le support technique Microsoft pour obtenir de l’aide.
  • Les erreurs de pureté des données peuvent poser problème lorsque l’application insère ou met à jour des données non valides dans des tables SQL Server. Pour plus d’informations sur la résolution des erreurs de pureté des données, consultez Résolution des problèmes d’erreur DBCC 2570 dans SQL Server 2005.
  • Vérifiez l’intégrité du système de fichiers à l’aide de la commande chkdsk. chkdsk pendant l’exécution de SQL Server. Il peut signaler des erreurs transitoires liées aux fichiers si SQL Server écrit dans les fichiers vérifiés. En outre, les commutateurs tels que /r ou /f peuvent déplacer des octets de fichier vers un autre emplacement sur le disque, et ce mouvement peut entraîner une altération si SQL Server écrit ou lit également à partir de ces fichiers. Par conséquent, veillez à arrêter SQL Server avant d’exécuter la commande chkdsk. En outre, soyez prudent avec les options de réparation comme /r et /f. Vérifiez que vous disposez d’une sauvegarde de vos bases de données avant d’exécuter une réparation, car ces options peuvent endommager les fichiers, si des erreurs de disque sont détectées par chkdsk.

Plus d’informations

Pour plus d’informations sur la syntaxe de DBCC CHECKDB et sur la façon d’exécuter la commande, ainsi que sur les informations ou options disponibles à ce sujet, consultez DBCC CHECKDB (Transact-SQL).

Si des erreurs sont détectées à l’aide de CHECKDB, d’autres messages similaires au message suivant sont signalés dans le ERRORLOG à des fins de création de rapports d’erreurs :

**Dump thread - spid = 0, EC = 0x00000000855F5EB0
***Stack Dump being sent toFilePath\FileName
* ******************************************************************************
*
* BEGIN STACK DUMP:
*  Date/Timespid 53
*
* DBCC database corruption
*
* Input Buffer 84 bytes -
*             dbcc checkdb(mydb)
*
* *******************************************************************************
*   -------------------------------------------------------------------------------
* Short Stack Dump
Stack Signature for the dump is 0x00000000000001E8
External dump process return code 0x20002001.

Les informations d’erreur ont été envoyées au service de rapport d’erreurs Watson.

Les fichiers utilisés pour la création de rapports d’erreurs incluent un fichier SQLDump<nnn>.txt . Ce fichier peut être utile à des fins historiques, car il contient une liste des erreurs trouvées à partir de CHECKDB dans un format XML.

Pour connaître la dernière exécution DBCC CHECKDB sans erreurs détectées pour une base de données (le dernier CHECKDB intègre connu), vérifiez le journal des erreurs SQL Server. Recherchez un message comme celui suivant pour une base de données utilisateur ou système. Ce message est consigné comme message de niveau Informations dans le journal des événements de l’application Windows avec EventID = 17573 également) :

Date/Heure spid7s CHECKDB pour la base de données « master » s’est terminé sans erreurs sur Date/Heure22:11:11.417 (heure locale). Il s’agit d’un message d’information uniquement ; aucune action utilisateur n’est requise

  • Dernière mise à jour :