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 base de connaissances d’origine : 2015748

Symptômes

Lorsque DBCC CHECKDB (ou d’autres commandes similaires comme DBCC CHECKTABLE) sont exécutées, 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 au niveau de l’information.

Les informations contenues dans le message commençant par « instantané de base de données interne... » s’affiche uniquement si DBCC CHECKDB elle a été exécutée en ligne, dans laquelle la base de données n’est pas en SINGLE_USER mode. Cela est dû au fait que pour un instantané de 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, DBCC CHECKDB mais plutôt l’approche générale si des erreurs sont signalées. Toute référence à CHECKDB cet article s’applique également à DBCC CHECKTABLE 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, 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 de 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 principal et cache) pour isoler et résoudre les problèmes. 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 la vérification de la cause racine, consultez Examiner la cause racine.

  2. Si DBCC CHECKDB vous signalez 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 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 appliquer les correctifs pertinents. Un emplacement central où vous pouvez rechercher tous les correctifs d’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 s’ils 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 et le système d’E/S.

  5. S’il n’est pas possible de restaurer à partir d’une sauvegarde, CHECKDB dispose 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’ont aucune possibilité de 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 lors de la réparation avec l’autorisation de perte de données, car il peut laisser votre base de données dans un état logiquement incohérent. La DBCC CHECKDB sortie fait une recommandation sur le niveau de réparation minimal à utiliser. Il est courant de s’exécuter CHECKDB plusieurs REPAIR_ALLOW_DATA_LOSS 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 liaisons rompues peuvent être découvertes. 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 à 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 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 la résolution de ce niveau de réparation. Cela signifie que toutes les réparations n’entraînent CHECKDB REPAIR_ALLOW_DATA_LOSS 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 limiter 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 d’une table donnée.

    Avertissement

    Vous devez effectuer une validation manuelle des données après CHECKDB la réparation ou l’exportation ou l’importation de données. 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 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 sur le schéma de 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 faire.

  7. Passez en revue les articles suivants pour connaître les erreurs spécifiques générées et DBCC CHECKDB 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, 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 vos fabricants matériels 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 :
    • Les périphériques matériels et la configuration confirment les exigences d’entrée/sortie Moteur de base de données Microsoft SQL Server.
    • Les pilotes de périphérique et les autres composants logiciels de prise en charge de tous les appareils situés dans le chemin d’E/S sont à jour.
  • 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 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 appliquer les correctifs pertinents. Un emplacement central où vous pouvez rechercher tous les correctifs d’une version particulière si 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. L’activité contre les 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 pendant qu’elles sont en cache avant d’être écrites sur le disque. 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 qu’elle est « propre » (aucune erreur à partir de CHECKDB) suivie des sauvegardes du journal des transactions qui s’étendent sur le moment où 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 être un problème lié à l’insertion ou à la mise à jour de 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 . Ne s’exécutez chkdsk pas pendant l’exécution de SQL Server. Il peut signaler des erreurs de fichier temporaires 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 chkdsk commande. 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 et les informations ou options sur l’exécution de DBCC CHECKDB la commande, consultez DBCC CHECKDB (Transact-SQL).

Si des erreurs sont détectées à l’aide 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 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 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 nettoyage CHECKDBconnu), vérifiez SQL Server ERRORLOG. Recherchez un message comme celui suivant pour une base de données utilisateur ou système. Ce message est écrit en tant que message au niveau de l’information 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 » terminée 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