Résoudre les erreurs de cohérence de base de données signalées par DBCC CHECKDB

  • Article

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

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

Symptômes

Lorsque DBCC CHECKDB (ou d’autres commandes similaires telles que DBCC CHECKTABLE) sont exécutées, un message semblable à 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 des applications Windows en tant que message au niveau des informations avec EventID=8957. Même si des erreurs sont signalées, ce message est un message de niveau information.

Les informations contenues dans le message commençant par « instantané de base de données interne... » s’affiche uniquement si DBCC CHECKDB a été exécuté en ligne, dans lequel la base de données n’est pas en SINGLE_USER mode . En effet, pour un instantané de base de données en ligneDBCC CHECKDB, une base de données interne est utilisée pour présenter un ensemble cohérent de données à case activée.

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 CHECKTABLEet DBCC CHECKFILEGROUP , sauf indication contraire.

Cause

La DBCC CHECKDB commande 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, de l’intégrité référentielle de la 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), des erreurs sont signalées.

La cause de ces problèmes peut aller de l’altération du système de fichiers, des problèmes matériels sous-jacents, des problèmes de pilote, des pages endommagées dans la mémoire ou le cache de stockage, ou des problèmes avec le SQL Server. Pour plus d’informations sur la façon d’identifier 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 procéder à la restauration d’une sauvegarde ou à la réparation de 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 qui sont 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 principal et cache) pour isoler et résoudre les problèmes. Par exemple, 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 la vérification 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 les 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 le Service Pack pour vous assurer que vous ne rencontrez aucun problème connu. Consultez la documentation mise à jour cumulative ou 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 pour une version particulière si 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 lors d’une exécution et disparaissent lors de la prochaine, vous pouvez rencontrer des problèmes de cache de disque (problème de pilote de périphérique ou d’autre problème de chemin d’E/S). Collaborez avec les chargés de maintenance 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 et le système du chemin d’E/S.

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

    • REPAIR_REBUILD - effectue des réparations qui n’ont aucun risque de perte de données.
    • REPAIR_ALLOW_DATA_LOSS - effectue des réparations qui ont le risque de perte de données.

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

    Vous devez faire preuve de prudence lorsque vous choisissez de réparer avec autoriser la perte de données, car cela peut laisser votre base de données dans un état logiquement incohérent. La DBCC CHECKDB sortie émet une recommandation sur le niveau de réparation minimal à utiliser. Il est courant d’exécuter CHECKDB plusieurs fois jusqu’à REPAIR_ALLOW_DATA_LOSS ce qu’aucune erreur supplémentaire ne soit signalée. En effet, lorsque la réparation corrige un ensemble d’erreurs, d’autres liaisons rompues peuvent être découvertes. Toutefois, de nouvelles erreurs peuvent apparaître si la cause sous-jacente n’a pas été résolue. Par conséquent, si des problèmes au niveau du système, tels que le matériel ou le système de fichiers, provoquent une altération des données, ces problèmes doivent être résolus en premier, 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 résout pas les erreurs de cohérence ou si la sauvegarde de 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 trouvé 0 erreur 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 détecté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 à partir 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 tout simplement pas être corrigées. Vous devrez peut-être également exécuter le processus de réparation plusieurs fois. Toutes les erreurs signalées ne nécessitent pas que l’utilisation de ce niveau de réparation soit résolue. Cela signifie que toutes les réparations par CHECKDB entraînent REPAIR_ALLOW_DATA_LOSS une 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 d’affiner le niveau de réparation pour 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 ou l’exportation ou l’importation de données terminée. Pour plus d’informations, consultez Arguments DBCC CHECKDB. Les données peuvent ne pas être logiquement cohérentes après la réparation. Par exemple, la réparation (en particulier REPAIR_ALLOW_DATA_LOSS l’option) 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 de clé primaire correspondantes dans la table parente.

  6. Essayez de générer un script pour le schéma de base de données. Utilisez le script pour créer une base de données, puis utilisez un outil comme 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 est susceptible d’échouer. Dans ce cas, ignorez cette table, passez à la suivante et enregistrez ce que vous pouvez.

  7. Consultez 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 racine des erreurs de cohérence de base de données

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

  • Vérifiez dans le journal des événements système Windows toute erreur liée au niveau système, au pilote ou au disque, et collaborez avec le fabricant de votre matériel pour les résoudre.
  • Exécutez n’importe quelle diagnostics fournie par vos fabricants de matériel pour l’ordinateur et/ou le système de disque.
  • Collaborez avec votre fournisseur de matériel ou votre fabricant d’appareils pour vous assurer que :
  • Envisagez d’utiliser un utilitaire comme SQLIOSim sur le lecteur où résident les bases de données qui ont signalé les erreurs de cohérence. SQLIOSim est un outil indépendant du moteur de 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 mise à jour cumulative ou 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 pour une version particulière si les listes de correctifs détaillés pour SQL Server 2022, 2019, 2017.
  • Vérifiez toutes les autres erreurs signalées par SQL Server telles que les violations d’accès ou les assertions. L’activité 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, cela indique 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 How to Troubleshoot Msg 824 in SQL Server.
  • Recherchez les erreurs du message 832 dans errorLOG. Ces erreurs peuvent indiquer que les pages peuvent être endommagées lorsqu’elles sont dans le cache avant d’être écrites sur le disque. Pour plus d’informations, consultez How to Troubleshoot Msg 832 in SQL Server.
  • Sur un autre système, essayez de restaurer une sauvegarde de base de données dont vous savez qu’il s’agit de « propre » (aucune erreur de ) suivie des sauvegardes du CHECKDBjournal des transactions qui s’étendent sur la durée de génération de l’erreur. 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 être un problème lié à l’insertion ou à la mise à jour de données non valides dans SQL Server tables. Pour plus d’informations sur la résolution des erreurs de pureté des données, consultez Résolution des problèmes liés à l’erreur DBCC 2570 dans SQL Server 2005.
  • Vérifiez l’intégrité du système de fichiers à l’aide de la commande chkdsk .

Plus d’informations

Pour plus d’informations sur la syntaxe de DBCC CHECKDB et les informations ou options sur l’exécution de la commande, consultez DBCC CHECKDB (Transact-SQL).

Si des erreurs sont détectées à l’aide CHECKDBde , d’autres messages similaires au message suivant sont signalés dans errorLOG à des fins de signalement 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 rapport d’erreurs Watson.

Les fichiers utilisés pour le rapport d’erreurs incluent un fichier SQLDump<nnn>.txt . Ce fichier peut être utile à des fins d’historique, car il contient une liste des erreurs trouvées à partir CHECKDB d’un format XML.

Pour savoir quand la dernière fois DBCC CHECKDB a été exécutée sans erreurs détectées pour une base de données (la dernière propre CHECKDBconnue), case activée le SQL Server ERRORLOG pour un message comme le suivant dans une base de données utilisateur ou système (ce message est également écrit sous la forme d’un message de niveau d’information dans le journal des événements des applications Windows avec EventID = 17573) :

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