Partager via

DBCC CHECKDB (Transact-SQL)

  • Article

S’applique à : SQL Server Azure SQL Database Azure SQL Managed Instance

Vérifie l'intégrité logique et physique de tous les objets de la base de données spécifiée en effectuant les opérations suivantes :

  • Exécute DBCC CHECKALLOC sur la base de données.
  • Exécute DBCC CHECKTABLE sur chaque table et vue de la base de données.
  • Exécute DBCC CHECKCATALOG sur la base de données.
  • Valide le contenu de chaque vue indexée dans la base de données.
  • Valide la cohérence au niveau du lien entre les métadonnées de la table et les répertoires et les fichiers du système de fichiers lors du stockage de données varbinary(max) dans le système de fichiers à l’aide de FILESTREAM.
  • Valide les données Service Broker dans la base de données.

Cela signifie que les commandes DBCC CHECKALLOC, DBCC CHECKTABLE et DBCC CHECKCATALOG ne doivent pas être exécutées séparément de DBCC CHECKDB. Pour plus d'informations sur les vérifications réalisées par ces commandes, consultez les descriptions des commandes.

DBCC CHECKDB est pris en charge sur les bases de données contenant des tables à mémoire optimisée, mais la validation se produit seulement sur les tables sur disque. Cependant, dans le cadre de la sauvegarde et de la restauration des bases de données, une validation CHECKSUM est effectuée pour les fichiers des groupes de fichiers mémoire optimisés.

Comme les options de réparation de DBCC ne sont pas disponibles pour les tables à mémoire optimisée, vous devez sauvegarder les bases de données régulièrement et tester les sauvegardes. Si des problèmes d'intégrité des données se produisent dans une table mémoire optimisée, vous devez restaurer à partir de la dernière sauvegarde connue et fiable.

Conventions de la syntaxe Transact-SQL

Syntaxe

DBCC CHECKDB
    [ ( database_name | database_id | 0
        [ , NOINDEX
        | , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
    ) ]
    [ WITH
        {
            [ ALL_ERRORMSGS ]
            [ , EXTENDED_LOGICAL_CHECKS ]
            [ , NO_INFOMSGS ]
            [ , TABLOCK ]
            [ , ESTIMATEONLY ]
            [ , { PHYSICAL_ONLY | DATA_PURITY } ]
            [ , MAXDOP = number_of_processors ]
        }
    ]
]

Arguments

database_name | database_id | 0

Nom ou ID de la base de données pour laquelle vous exécutez des vérifications d’intégrité. En l'absence de spécification, ou si 0 est spécifié, la base de données actuelle est utilisée. Les noms de base de données doivent suivre les règles applicables aux identificateurs.

NOINDEX

Spécifie que les vérifications intensives des index non cluster pour les tables utilisateur ne seront pas effectuées. Ce paramètre diminue la durée d’exécution globale. NOINDEX n’affecte pas les tables système, car les vérifications d’intégrité sont toujours effectuées sur les index des tables système.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

Spécifie que DBCC CHECKDB répare les erreurs trouvées. N'utilisez les options REPAIR qu'en dernier recours. La base de données spécifiée doit être en mode mono-utilisateur pour pouvoir utiliser l'une des options de réparation suivantes.

  • REPAIR_ALLOW_DATA_LOSS

    Tente de réparer toutes les erreurs signalées. Ces réparations peuvent entraîner des pertes de données.

    Avertissement

    L’option REPAIR_ALLOW_DATA_LOSS est une fonctionnalité prise en charge, mais il ne s’agit pas toujours nécessairement de la meilleure option pour amener une base de données à un état physiquement cohérent. En cas de réussite, l’option REPAIR_ALLOW_DATA_LOSS peut entraîner une perte de données. En fait, elle peut entraîner une perte de données supérieure à celle que vous pourriez constater si un utilisateur restaurait la base de données à partir de la dernière bonne sauvegarde.

    Microsoft recommande toujours d’effectuer une restauration utilisateur à partir de la dernière bonne sauvegarde comme méthode principale pour récupérer des erreurs signalées par DBCC CHECKDB. L’option REPAIR_ALLOW_DATA_LOSS n’est pas une alternative pour la restauration à partir d’une sauvegarde réputée correcte. C’est une option d’urgence en dernier recours, recommandée seulement si la restauration à partir d’une sauvegarde n’est pas possible.

    Certaines erreurs, qui peuvent être réparées seulement en utilisant l’option REPAIR_ALLOW_DATA_LOSS, peuvent nécessiter de désallouer une ligne, une page ou une série de pages pour réparer les erreurs. Toutes les données désallouées ne sont plus accessibles ou récupérables par l'utilisateur et le contenu exact des données désallouées ne peut pas être déterminé. Par conséquent, l'intégrité référentielle peut être inexacte après la désallocation de lignes ou de pages, car les contraintes de clé étrangère ne sont pas vérifiées ou conservées dans le cadre de cette opération de réparation. L’utilisateur doit examiner l’intégrité référentielle de sa base de données (en utilisant DBCC CHECKCONSTRAINTS) après avoir utilisé l’option REPAIR_ALLOW_DATA_LOSS.

    Avant d’effectuer la réparation, vous devez créer des copies physiques des fichiers qui appartiennent à cette base de données. Ceci comprend le fichier de données principal (.mdf), les fichiers de données secondaires (.ndf), tous les fichiers journaux des transactions (.ldf) et les autres conteneurs qui forment la base de données, y compris les catalogues de texte intégral, les dossiers de flux de fichiers, les données à mémoire optimisée, etc.

    Avant d’effectuer la réparation, envisagez de changer l’état de la base de données en mode EMERGENCY, et essayez d’extraire autant d’informations que possible des tables critiques et d’enregistrer ces données.

  • REPAIR_FAST

    Conserve la syntaxe pour une compatibilité descendante uniquement. Aucune réparation n'est effectuée.

  • REPAIR_REBUILD

    Effectue des réparations qui ne présentent aucun risque de perte de données. Cette option peut inclure des réparations rapides, comme la réparation de lignes manquantes dans des index non cluster, ainsi que des réparations nécessitant plus de temps, comme que la reconstruction d’un index.

    Cet argument ne répare pas les erreurs impliquant des données FILESTREAM.

Important

Comme DBCC CHECKDB est entièrement journalisé et récupérable avec n’importe quelle option REPAIR, Microsoft recommande toujours d’utiliser DBCC CHECKDB avec une option REPAIR dans une transaction (exécutez BEGIN TRANSACTION avant d’exécuter la commande). Ainsi, l’utilisateur peut confirmer qu’il veut accepter les résultats de l’opération. L’utilisateur peut ensuite exécuter COMMIT TRANSACTION pour valider tout le travail effectué par l’opération de réparation. Si l’utilisateur ne veut pas accepter les résultats de l’opération, il peut exécuter une instruction ROLLBACK TRANSACTION pour annuler les effets des opérations de réparation.

Pour réparer les erreurs, nous vous recommandons d'effectuer une restauration à partir d'une sauvegarde. Les opérations de réparation ne prennent en compte aucune des contraintes qui peuvent exister sur les tables ou entre tables. Si la table spécifiée est impliquée dans une ou plusieurs contraintes, nous vous recommandons d’exécuter DBCC CHECKCONSTRAINTS après une réparation. Si vous devez utiliser REPAIR, exécutez DBCC CHECKDB sans option de réparation afin de déterminer le niveau de réparation à utiliser. Si vous utilisez le niveau REPAIR_ALLOW_DATA_LOSS, nous vous recommandons de sauvegarder la base de données avant d’exécuter DBCC CHECKDB avec cette option.

ALL_ERRORMSGS

Affiche toutes les erreurs signalées par objet. Tous les messages d'erreur sont affichés par défaut. La spécification ou non de cette option n'a aucun effet. Les messages d’erreur sont triés par ID d’objet, à l’exception des messages générés à partir de la base de données tempdb.

EXTENDED_LOGICAL_CHECKS

Si le niveau de compatibilité est 100, introduit dans SQL Server 2008 (10.0.x), cette option effectue des vérifications de cohérence logique sur une vue indexée, sur les index XML et sur les index spatiaux, là où ils sont présents.

Pour plus d’informations, consultez Effectuer des vérifications de cohérence logique sur les index plus loin dans cet article.

NO_INFOMSGS

Supprime tous les messages d'information.

TABLOCK

Fait que DBCC CHECKDB obtient des verrouillages au lieu d’utiliser un instantané de base de données interne. Cette opération comprend un verrou exclusif sur la base de données. TABLOCK va accélérer l’exécution de DBCC CHECKDB sur une base de données dont la charge est importante, mais va diminuer la concurrence disponible sur la base de données pendant l’exécution de DBCC CHECKDB.

Important

TABLOCK limite les vérifications effectuées ; DBCC CHECKCATALOG n’est pas exécuté sur la base de données et les données de Service Broker ne sont pas validées.

ESTIMATEONLY

Affiche une estimation de la quantité d’espace de tempdb nécessaire pour exécuter DBCC CHECKDB avec toutes les autres options spécifiées. La vérification de la base de données actuelle n’est pas effectuée.

PHYSICAL_ONLY

Limite la nature de la vérification à l'intégrité de la structure physique sur la page et les en-têtes d'enregistrement, et à l'intégrité de la cohérence d'allocation de la base de données. Cette vérification, qui vise à contrôler la cohérence physique de la base de données, inclut par ailleurs la détection des pages endommagées, des échecs de somme de contrôle et des erreurs matérielles courantes, susceptibles de compromettre les données utilisateur.

Une exécution complète de DBCC CHECKDB peut prendre beaucoup plus de temps que dans les versions antérieures. Ce problème se produit parce que :

  • Les vérifications logiques sont plus complètes.
  • Certaines des structures sous-jacentes à vérifier sont plus complexes.
  • De nombreuses vérifications nouvelles ont été introduites pour inclure les nouvelles fonctionnalités.

Par conséquent, l’utilisation de l’option PHYSICAL_ONLY étant susceptible de réduire considérablement la durée d’exécution de DBCC CHECKDB sur les grandes bases de données, elle est recommandée pour une utilisation fréquente sur des systèmes de production. Nous vous recommandons d’effectuer régulièrement une exécution complète de DBCC CHECKDB. La fréquence de ces exécutions dépend de facteurs spécifiques à chaque entreprise et à chaque environnement de production.

Cet argument implique toujours NO_INFOMSGS et n’est autorisé avec aucune des options de réparation.

Avertissement

La spécification de l’option PHYSICAL_ONLY fait que DBCC CHECKDB va ignorer toutes les vérifications des données FILESTREAM.

DATA_PURITY

Fait que DBCC CHECKDB vérifie si la base de données contient des valeurs de colonnes qui ne sont pas valides ou sont hors limites. Par exemple, DBCC CHECKDB détecte les colonnes dont les dates et les heures sont supérieures ou inférieures à la plage acceptable pour le type de données datetime, ou les colonnes décimales ou ayant un type de données numérique approximatif avec des valeurs d’échelle ou de précision qui ne sont pas valides.

Les vérifications d’intégrité des valeurs de colonne sont activées par défaut et ne nécessitent pas l’option DATA_PURITY. Pour les bases de données mises à niveau depuis des versions antérieures de SQL Server, les vérifications des valeurs des colonnes ne sont pas activées par défaut tant que la commande DBCC CHECKDB WITH DATA_PURITY n’a pas été exécutée sans erreur sur cette base de données. Ensuite, DBCC CHECKDB vérifie l’intégrité sur la base colonne-valeur par défaut. Pour plus d’informations sur la façon dont CHECKDB peut être affecté par la mise à niveau de la base de données depuis des versions antérieures de SQL Server, consultez la section Remarques plus loin dans cette rubrique.

Avertissement

Si PHYSICAL_ONLY est spécifié, les vérifications d’intégrité des colonnes ne sont pas effectuées.

Les erreurs de validation signalées par cette option ne peuvent pas être corrigées en utilisant les options de réparation de DBCC. Pour des informations sur la correction manuelle de ces erreurs, consultez l’article 923247 (en anglais) de la Base de connaissances : Dépannage d’erreur DBCC 2570 dans SQL Server 2005 et versions ultérieures.

MAXDOP

S’applique à : SQL Server 2014 (12.x) Service Pack 2 et ultérieur.

Remplace l’option de configuration max degree of parallelism de sp_configure pour l’instruction. MAXDOP peut être supérieur à la valeur configurée avec sp_configure. Si MAXDOP dépasse la valeur configurée avec Resource Governor, le moteur de base de données SQL Server utilise la valeur MAXDOP de Resource Governor décrite dans ALTER WORKLOAD GROUP. Toutes les règles sémantiques utilisées avec l’option de configuration du degré maximal de parallélisme sont applicables quand vous utilisez l’indicateur de requête MAXDOP. Pour plus d’informations, consultez Configurer l’option de configuration du serveur max degree of parallelism.

Avertissement

Si MAXDOP est défini sur zéro, SQL Server choisit le degré maximal de parallélisme à utiliser.

Notes

DBCC CHECKDB n’examine pas les index désactivés. Pour plus d’informations sur les index désactivés, consultez Désactiver les index et contraintes.

Si un type défini par l'utilisateur est marqué comme étant ordonné par octet, il ne doit y avoir qu'une seule sérialisation du type défini par l'utilisateur. L’absence d’une sérialisation cohérente des types définis par l’utilisateur ordonnés par octet provoque l’erreur 2537 quand DBCC CHECKDB est exécuté. Pour plus d’informations, consultez Configuration requise pour les types définis par l’utilisateur.

Comme la base de données Resource est modifiable seulement en mode mono-utilisateur, vous ne pouvez pas y exécuter la commande DBCC CHECKDB directement. Cependant, lors de l’exécution de DBCC CHECKDB sur la base de données master, une deuxième commande CHECKDB est également exécutée en interne sur la base de données Resource. Cela signifie que DBCC CHECKDB peut retourner des résultats supplémentaires. La commande retourne des jeux de résultats supplémentaires lorsqu'aucune option n'est définie ou lorsque l'option PHYSICAL_ONLY ou ESTIMATEONLY est définie.

À compter de SQL Server 2005 (9.x) Service Pack 2, l’exécution de DBCC CHECKDB n’efface plus le cache du plan pour l’instance de SQL Server. Avant SQL Server 2005 (9.x) Service Pack 2, l’exécution de la commande DBCC CHECKDB effaçait le cache du plan. Cette opération entraîne la recompilation de tous les plans d'exécution ultérieurs et peut entraîner une baisse temporaire et brutale des performances des requêtes.

Exécuter des vérifications de cohérence logique sur des index

La vérification de la cohérence logique sur les index varie selon le niveau de compatibilité de la base de données, comme suit :

  • Si le niveau de compatibilité est au moins 100 (introduit dans SQL Server 2008 (10.0.x)) :
  • Sauf si NOINDEX est spécifié, DBCC CHECKDB effectue les vérifications de la cohérence physique et logique sur une table ainsi que sur tous ses index non cluster. Toutefois, seules des vérifications de cohérence physique sont effectuées par défaut sur les index XML, les index spatiaux et les vues indexées.
  • Si WITH EXTENDED_LOGICAL_CHECKS est spécifié, des vérifications logiques sont effectuées sur une vue indexée, des index XML et des index spatiaux, là où ils sont présents. Par défaut, les vérifications de cohérence physique sont effectuées avant les vérifications de cohérence logique. Si NOINDEX est également spécifié, seules les vérifications logiques sont effectuées.

Ces vérifications de cohérence logique effectuent une vérification croisée de la table d'index interne de l'objet d'index avec la table utilisateur à laquelle il fait référence. Pour rechercher les lignes excentrées, une requête interne est construite pour effectuer l'intersection complète de la table interne et de la table utilisateur. L’exécution de cette requête peut avoir un effet significatif sur les performances et il n’est pas possible de suivre sa progression. Par conséquent, nous vous recommandons de spécifier WITH EXTENDED_LOGICAL_CHECKS seulement si vous soupçonnez des problèmes d'index qui ne sont pas liés à une altération physique ou si les sommes de contrôle au niveau de la page ont été désactivées et que vous soupçonnez un endommagement matériel au niveau des colonnes.

  • Si l’index est un index filtré, DBCC CHECKDB effectue des vérifications de cohérence pour vérifier que les entrées d’index satisfont au prédicat du filtre.
  • Si le niveau de compatibilité est égal ou inférieur à 90, à moins que l’option NOINDEX soit spécifiée, DBCC CHECKDB effectue à la fois des vérifications de cohérence physique et logique sur une seule table ou une vue indexée, et sur tous ses index non cluster et XML. Les index spatiaux ne sont pas pris en charge.
  • À compter de SQL Server 2016 (13.x), les vérifications supplémentaires sur les colonnes calculées persistantes, les colonnes UDT et les index filtrés ne seront pas exécutées par défaut afin d’éviter les évaluations d’expressions coûteuses. Cette modification réduit considérablement la durée de CHECKDB sur les bases de données contenant ces objets. Cependant, la vérification de cohérence physique de ces objets est toujours effectuée. Les évaluations d’expressions ne sont effectuées en plus des vérifications logiques déjà présentes dans le cadre de l’option EXTENDED_LOGICAL_CHECKS (vue indexée, index XML et index spatiaux) que quand l’option EXTENDED_LOGICAL_CHECKS est spécifiée.

Pour connaître le niveau de compatibilité d’une base de données

Instantané de base de données interne

DBCC CHECKDB utilise un instantané de base de données interne pour la cohérence transactionnelle nécessaire à la réalisation de ces vérifications. Ceci évite les problèmes de blocage et d'accès simultané lors de l'exécution de ces commandes. Pour plus d’informations, consultez Affichage de la taille du fichier partiellement alloué d’une capture instantanée de base de données (Transact-SQL) et la section de DBCC (Transact-SQL) intitulée Utilisation de la capture instantanée de base de données interne DBCC. Si un instantané ne peut pas être créé ou si TABLOCK est spécifié, DBCC CHECKDB acquiert des verrous pour obtenir la cohérence requise. Dans ce cas, un verrou de base de données exclusif est requis pour effectuer les vérifications d'allocation, tandis que des verrous de table partagés sont nécessaires pour effectuer les vérifications de table.

DBCC CHECKDB échoue quand elle est exécutée sur la base de données master si un instantané de base de données interne ne peut pas être créé.

L’exécution de DBCC CHECKDB sur tempdb n’effectue aucune vérification d’allocation ou de catalogue, et elle doit acquérir des verrous de table partagés pour vérifier les tables. La raison en est que, pour des raisons de performances, les instantanés de base de données ne sont pas disponibles sur tempdb. Cela signifie que la cohérence transactionnelle requise ne peut pas être obtenue.

Comment DBCC CHECKDB crée une base de données par instantané interne à partir de SQL Server 2014

  1. DBCC CHECKDB crée un instantané interne de la base de données.

  2. La base de données par instantané interne est créée à l’aide de fichiers physiques. Par exemple, pour une base de données avec database_id = 10 qui a trois fichiers E:\Data\my_DB.mdf, E:\Data\my_DB.ndf et E:\Data\my_DB.ldf, l’instantané de base de données interne est créé en utilisant les fichiers E:\Data\my_DB.mdf_MSSQL_DBCC11 et E:\Data\my_DB.ndf_MSSQL_DBCC11. Le database_id de l’instantané est database_id + 1. Notez également que les nouveaux fichiers sont créés dans le même dossier en utilisant la convention de nommage <filename.extension>_MSSQL_DBCC<database_id_of_snapshot>. Aucun fichier partiellement alloué n’est créé pour le journal des transactions.

  3. Les nouveaux fichiers sont marqués comme fichiers partiellement alloués au niveau du système de fichiers. La Taille sur le disque utilisée par les nouveaux fichiers augmente en fonction de la quantité de données mises à jour dans la base de données source lors de l’exécution de la commande DBCC CHECKDB. La Taille des nouveaux fichiers sera identique à celle du fichier .mdf ou .ndf.

  4. Les nouveaux fichiers sont supprimés à la fin du traitement de DBCC CHECKDB. Ces fichiers partiellement alloués qui sont créés par DBCC CHECKDB ont les attributs « Supprimer à la fermeture » définis.

Avertissement

Si le système d’exploitation rencontre un arrêt inattendu alors que la commande DBCC CHECKDB est en cours, ces fichiers ne sont pas nettoyés. Ils vont occuper de l’espace et risquent de provoquer des défaillances lors des exécutions ultérieures de DBCC CHECKDB. Dans ce cas, vous pouvez supprimer ces nouveaux fichiers après avoir vérifié qu’aucune commande DBCC CHECKDB n’est en cours d’exécution.

Les nouveaux fichiers sont visibles à l’aide d’utilitaires de fichier ordinaires comme l’Explorateur Windows.

Notes

Avant SQL Server 2014 (12.x), des flux de fichiers nommés étaient utilisés à la place pour créer les fichiers d’instantané interne. Les flux de fichiers nommés utilisaient le format <filename.extension>:MSSQL_DBCC<database_id_of_snapshot>. Les flux de fichiers nommés ne sont pas visibles à l’aide d’utilitaires de fichier ordinaires comme l’Explorateur Windows. Par conséquent, dans SQL Server 2012 (11.x) et antérieur, vous pouvez rencontrer les messages d’erreur 7926 et 5030 quand vous exécutez la commande DBCC CHECKDB pour des fichiers de base de données situés sur un volume au format ReFS. Cela est dû au fait que les flux de fichiers ne peuvent pas être créés sur le système Resilient File System (RefS).

Vérifier et réparer les données FILESTREAM

Quand FILESTREAM est activé pour une base de données et une table, vous pouvez éventuellement stocker des objets BLOB(Binary Large Object) varbinary(max) dans le système de fichiers. Quand vous utilisez DBCC CHECKDB sur une base de données qui stocke des objets Blob dans le système de fichiers, DBCC vérifie la cohérence au niveau des liens entre le système de fichiers et la base de données.

Par exemple, si une table contient une colonne varbinary(max) qui utilise l’attribut FILESTREAM, DBCC CHECKDB va vérifier qu’il existe un mappage un-à-un entre les répertoires et les fichiers du système de fichiers et les lignes, les colonnes et les valeurs de colonne de la table. DBCC CHECKDB peut réparer l’altération si vous spécifiez l’option REPAIR_ALLOW_DATA_LOSS. Pour réparer l'altération FILESTREAM, DBCC supprime toutes les lignes de la table auxquelles il manque des données du système de fichiers.

Bonnes pratiques

Nous vous recommandons d'utiliser l'option PHYSICAL_ONLY pour une utilisation fréquente sur des systèmes de production. L’utilisation de PHYSICAL_ONLY permet de raccourcir fortement le temps d’exécution de DBCC CHECKDB sur les grandes bases de données. Nous vous recommandons aussi d’exécuter régulièrement DBCC CHECKDB sans options. La fréquence à laquelle vous devez effectuer ces exécutions dépend de chaque activité et de son environnement de production.

Sur Azure SQL Managed Instance, l’espace de stockage disponible doit prendre en charge l’intégralité du fichier d’instantané de base de données interne créé par DBCC CHECKDB, quelle que soit la quantité d’espace de stockage réellement utilisée par les données. Cela peut entraîner une situation où l’exécution DBCC CHECKDB sur une base de données très volumineuse mais éparse (la taille des données est beaucoup plus petite que la taille de fichier de base de données) échoue en raison d’un manque d’espace sur votre instance managée SQL. Si DBCC CHECKDB vous consommez l’espace de stockage disponible pendant l’exécution, vous recevez le message d’erreur suivant :

Msg 1133, Level 16, State 3, Line 1
The managed instance has reached its storage limit. To storage usage for the managed instance cannot exceed (...) MBs.
You might need to temporarily scale up your SQL managed instance storage capacity before running `DBCC CHECKDB` again.

Vérifier des objets en parallèle

Par défaut, DBCC CHECKDB effectue une vérification parallèle des objets. Le degré de parallélisme est automatiquement défini par le processeur de requêtes. Le degré maximum de parallélisme est configuré de la même manière que les requêtes parallèles. Pour limiter le nombre maximal de processeurs disponibles pour la vérification DBCC, utilisez sp_configure. Pour plus d’informations, consultez Configurer l’option de configuration du serveur max degree of parallelism. La vérification parallèle peut être désactivée avec l’indicateur de trace 2528. Pour plus d’informations, consultez Indicateurs de trace (Transact-SQL).

Notes

Cette fonctionnalité n'est pas disponible dans toutes les éditions de SQL Server. Pour plus d’informations, consultez Vérifications de cohérence parallèles dans la section Simplicité de gestion SGBDR dans l’article Éditions et fonctionnalités prises en charge de SQL Server 2022.

Comprendre les messages d’erreur de DBCC

Une fois la commande DBCC CHECKDB terminée, un message est écrit dans le journal des erreurs SQL Server. Si la commande DBCC est correctement exécutée, le message indique que l'exécution a réussi, ainsi que la durée d'exécution de la commande. Si la commande DBCC est interrompue avant la fin de la vérification en raison d'une erreur, le message indique que la commande n'a pas abouti, précise une valeur d'état ainsi que la durée d'exécution de la commande. Le tableau suivant répertorie et décrit les valeurs d'état pouvant être incluses dans le message.

State Description
0 Erreur numéro 8930 générée. Ceci indique une corruption des métadonnées qui a arrêté la commande DBCC.
1 Erreur numéro 8967 générée. Une erreur DBCC interne s'est produite.
2 Une erreur s'est produite lors de la réparation de la base de données en mode urgence.
3 Ceci indique une corruption des métadonnées qui a arrêté la commande DBCC.
4 Une assertion ou une violation d'accès a été détectée.
5 Une erreur inconnue s'est produite et a arrêté la commande DBCC.

Notes

SQL Server enregistre la date et l’heure d’exécution d’une vérification de cohérence pour une base de données sans erreurs (ou une vérification de cohérence « propre »). C’est ce que l’on appelle last known clean check. Quand une base de données est démarrée pour la première fois, cette date est écrite dans le journal des événements (EventID-17573) et dans le journal des erreurs au format suivant :

CHECKDB for database '<database>' finished without errors on 2022-05-05 18:08:22.803 (local time). This is an informational message only; no user action is required.

Rapport d’erreurs

Un fichier de vidage (SQLDUMP<nnnn>.txt) est créé dans le répertoire LOG de SQL Server chaque fois que DBCC CHECKDB détecte une erreur d’endommagement. Quand les fonctionnalités Rapport d’erreurs et de collecte des données Utilisation de fonctionnalités sont activées pour l’instance de SQL Server, ce fichier est automatiquement transféré à Microsoft. Les données collectées sont utilisées pour améliorer les fonctionnalités SQL Server. Le fichier de vidage contient les résultats de la commande DBCC CHECKDB ainsi que des informations de diagnostic supplémentaires. L’accès est limité au compte de service SQL Server et aux membres du rôle sysadmin. Par défaut, le rôle sysadmin contient tous les membres du groupe Windows BUILTIN\Administrators et du groupe Administrateurs local. La commande DBCC n’échoue pas si le processus de collecte des données échoue.

Résolution des erreurs

Si des erreurs sont signalées par DBCC CHECKDB, nous vous recommandons de restaurer la base de données à partir de sa sauvegarde au lieu d’exécuter REPAIR avec une des options correspondantes. En cas d'absence de sauvegarde, la réparation corrige les erreurs détectées. Cette option de réparation est spécifiée à la fin de la liste des erreurs signalées. Néanmoins, la correction des erreurs en utilisant l’option REPAIR_ALLOW_DATA_LOSS risque de nécessiter la suppression de certaines pages, et donc aussi de certaines données.

Dans de telles circonstances, des valeurs risquent d’être entrées dans la base de données alors qu’elles ne sont pas valides ou qu’elles sont hors limites, en fonction du type de données de la colonne. DBCC CHECKDB peut détecter des valeurs de colonne non valides pour tous les types de données de colonne. Ainsi, l’exécution de DBCC CHECKDB avec l’option DATA_PURITY sur des bases de données mises à niveau depuis des versions antérieures de SQL Server peut révéler des erreurs préexistantes des valeurs de colonne. Comme SQL Server ne peut pas réparer automatiquement ces erreurs, vous devez mettre à jour la valeur de la colonne manuellement. Si CHECKDB détecte une telle erreur, CHECKDB retourne un avertissement, le numéro d’erreur 2570, et des informations pour identifier la ligne affectée et corriger l’erreur manuellement.

La réparation peut être effectuée dans une transaction utilisateur pour permettre à celui-ci d'annuler les modifications effectuées. Si des réparations sont restaurées, la base de données contiendra encore des erreurs et il faudra donc la restaurer à partir d'une sauvegarde. Une fois les réparations effectuées, sauvegardez la base de données.

Résoudre les erreurs en mode urgence dans la base de données

Quand une base de données a été placée en mode urgence l’instruction ALTER DATABASE, DBCC CHECKDB peut effectuer certaines réparations spéciales sur la base de données si l’option REPAIR_ALLOW_DATA_LOSS est spécifiée. Ces réparations peuvent éventuellement aboutir à la remise en ligne dans un état physiquement cohérent de bases de données irrécupérables en temps normal. Vous devez utiliser ces réparations en dernier recours et seulement quand vous ne pouvez pas restaurer la base de données à partir d’une sauvegarde. Si la base de données est placée en mode urgence, elle est marquée comme READ_ONLY, la journalisation est désactivée et l’accès est limité aux membres du rôle serveur fixe sysadmin.

Notes

Vous ne pouvez pas exécuter la commande DBCC CHECKDB en mode urgence dans une transaction utilisateur, puis annuler la transaction après l’exécution.

Quand la base de données est en mode urgence et que DBCC CHECKDB est exécutée avec la clause REPAIR_ALLOW_DATA_LOSS, les actions suivantes se produisent :

  • DBCC CHECKDB utilise les pages marquées comme inaccessibles en raison d’erreurs d’E/S ou de somme de contrôle, comme si les erreurs ne s’étaient pas produites. Cette procédure améliore les chances de récupérer les données de la base de données.
  • DBCC CHECKDB tente de récupérer la base de données en utilisant des techniques classiques de récupération basées sur les journaux.
  • Si, en raison de la corruption du journal des transactions, la récupération de la base de données échoue, le journal des transactions est reconstruit. La reconstruction du journal des transactions peut nuire à la cohérence transactionnelle.

Avertissement

L’option REPAIR_ALLOW_DATA_LOSS est une fonctionnalité de SQL Server prise en charge. Toutefois, il ne s'agit pas toujours nécessairement de la meilleure option pour mettre une base de données à un état physiquement cohérent. En cas de réussite, l’option REPAIR_ALLOW_DATA_LOSS peut entraîner une perte de données. En fait, elle peut entraîner une perte de données supérieure à celle que vous pourriez constater si un utilisateur restaurait la base de données à partir de la dernière bonne sauvegarde. Microsoft recommande toujours d’effectuer une restauration utilisateur à partir de la dernière bonne sauvegarde comme méthode principale pour récupérer des erreurs signalées par DBCC CHECKDB. L’option REPAIR_ALLOW_DATA_LOSS n’est pas une alternative pour restaurer à partir d’une sauvegarde réputée correcte. Il s’agit d’une option d’urgence en dernier recours, recommandée seulement si la restauration à partir d’une sauvegarde n’est pas possible.

Après la reconstruction du journal, il n'existe aucune garantie ACID totale.

Après la reconstruction du journal, DBCC CHECKDB est exécutée automatiquement, et signale et corrige les problèmes de cohérence physique.

La cohérence logique des données et les contraintes appliquées par la logique d'entreprise doivent être validées manuellement.

La taille du journal des transactions reste à sa taille par défaut et doit être réajustée manuellement à sa taille récente.

Si la commande DBCC CHECKDB réussit, la base de données est physiquement cohérente et son état est défini sur ONLINE. Toutefois, la base de données peut contenir une ou plusieurs incohérences transactionnelles. Nous vous recommandons d’exécuter DBCC CHECKCONSTRAINTS pour identifier tout défaut de logique métier et de sauvegarder immédiatement la base de données. Si la commande DBCC CHECKDB échoue, la base de données ne peut pas être réparée.

Exécuter DBCC CHECKDB avec REPAIR_ALLOW_DATA_LOSS dans des bases de données répliquées

L’exécution de la commande DBCC CHECKDB avec l’option REPAIR_ALLOW_DATA_LOSS peut affecter les bases de données utilisateur (bases de données de publication et d’abonnement) ainsi que la base de données de distribution utilisée par la réplication. Les bases de données de publication et d'abonnement incluent des tables publiées et des tables de métadonnées de réplication. Sachez que les problèmes suivants peuvent se poser dans ces bases de données :

  • Tables publiées. Les actions effectuées par le processus de CHECKDB pour réparer les données utilisateur endommagées peuvent ne pas être répliquées :
  • La réplication de fusion utilise des déclencheurs pour assurer le suivi des modifications apportées aux tables publiées. Si des lignes sont insérées, mises à jour ou supprimées par le processus de CHECKDB, les déclencheurs ne sont pas activés : la modification n’est donc pas répliquée.
  • La réplication transactionnelle utilise le journal des transactions pour assurer le suivi des modifications apportées aux tables publiées. L'Agent de lecture du journal place ensuite ces modifications dans la base de données de distribution. Certaines réparations de DBCC, bien qu’elles soient consignées, ne peuvent pas être répliquées par l’Agent de lecture du journal. Par exemple, si une page de données est désallouée par le processus de CHECKDB, l’Agent de lecture du journal ne traduit pas cette désallocation en une instruction DELETE : la modification n’est donc pas répliquée.
  • Tables de métadonnées de réplication. Les actions effectuées par le processus de CHECKDB afin de réparer les tables de métadonnées de réplication endommagées nécessitent la suppression, puis la reconfiguration de la réplication.

Si vous devez exécuter la commande DBCC CHECKDB avec l’option REPAIR_ALLOW_DATA_LOSS sur une base de données utilisateur ou de distribution :

  1. Suspendez le système : arrêtez l'activité sur la base de données et toutes les autres bases de données appartenant à la topologie de réplication, puis tentez de synchroniser tous les nœuds. Pour plus d’informations, consultez Suspension d’une topologie de réplication (programmation Transact-SQL de la réplication).
  2. Exécutez DBCC CHECKDB.
  3. Si le rapport de DBCC CHECKDB inclut des réparations pour des tables de la base de données de distribution ou des tables de métadonnées de réplication dans une base de données utilisateur, supprimez et reconfigurez la réplication. Pour plus d’informations, consultez Désactiver la publication et la distribution.
  4. Si le rapport de DBCC CHECKDB inclut des réparations pour des tables répliquées, procédez à une validation des données pour déterminer s’il existe des différences entre les données de la base de données de publication et celles de la base de données d’abonnement.

Jeux de résultats

DBCC CHECKDB retourne le jeu de résultats suivant. Les valeurs peuvent varier, excepté quand les options ESTIMATEONLY, PHYSICAL_ONLY ou NO_INFOMSGS sont spécifiées :

 DBCC results for 'model'.
    
 Service Broker Msg 9675, Level 10, State 1: Message Types analyzed: 13.
    
 Service Broker Msg 9676, Level 10, State 1: Service Contracts analyzed: 5.
    
 Service Broker Msg 9667, Level 10, State 1: Services analyzed: 3.
    
 Service Broker Msg 9668, Level 10, State 1: Service Queues analyzed: 3.
    
 Service Broker Msg 9669, Level 10, State 1: Conversation Endpoints analyzed: 0.
    
 Service Broker Msg 9674, Level 10, State 1: Conversation Groups analyzed: 0.
    
 Service Broker Msg 9670, Level 10, State 1: Remote Service Bindings analyzed: 0.
    
 DBCC results for 'sys.sysrowsetcolumns'.
    
 There are 630 rows in 7 pages for object 'sys.sysrowsetcolumns'.
    
 DBCC results for 'sys.sysrowsets'.
    
 There are 97 rows in 1 pages for object 'sys.sysrowsets'.
    
 DBCC results for 'sysallocunits'.
    
 There are 195 rows in 3 pages for object 'sysallocunits'.
    
 There are 0 rows in 0 pages for object "sys.sysasymkeys".
    
 DBCC results for 'sys.syssqlguides'.
    
 There are 0 rows in 0 pages for object "sys.syssqlguides".
    
 DBCC results for 'sys.queue_messages_1977058079'.
    
 There are 0 rows in 0 pages for object "sys.queue_messages_1977058079".
    
 DBCC results for 'sys.queue_messages_2009058193'.
    
 There are 0 rows in 0 pages for object "sys.queue_messages_2009058193".
    
 DBCC results for 'sys.queue_messages_2041058307'.
    
 There are 0 rows in 0 pages for object "sys.queue_messages_2041058307".
    
 CHECKDB found 0 allocation errors and 0 consistency errors in database 'model'.
    
 DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKDB retourne le jeu de résultats suivant (message) quand NO_INFOMSGS est spécifié :

 The command(s) completed successfully.

DBCC CHECKDB retourne le jeu de résultats suivant quand PHYSICAL_ONLY est spécifié :

 DBCC results for 'model'.
    
 CHECKDB found 0 allocation errors and 0 consistency errors in database 'master'.
    
 DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKDB retourne le jeu de résultats suivant quand ESTIMATEONLY est spécifié.

 Estimated TEMPDB space needed for CHECKALLOC (KB)
    
 -------------------------------------------------
    
 13
    
 (1 row(s) affected)
    
 Estimated TEMPDB space needed for CHECKTABLES (KB)
    
 --------------------------------------------------
    
 57
    
 (1 row(s) affected)
    
 DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Autorisations

Nécessite l’appartenance au rôle de serveur fixe sysadmin ou au rôle de base de données fixe db_owner .

Exemples

R. Vérifier la base de données active et une autre base de données

L'exemple suivant exécute DBCC CHECKDB pour la base de données actuelle et pour la base de données AdventureWorks2022.

-- Check the current database.
DBCC CHECKDB;
GO
-- Check the AdventureWorks2022 database without nonclustered indexes.
DBCC CHECKDB (AdventureWorks2022, NOINDEX);
GO

B. Vérifier la base de données actuelle et supprimer les messages d’information

L'exemple suivant vérifie la base de données actuelle et supprime tous les messages d'information.

DBCC CHECKDB WITH NO_INFOMSGS;
GO

Voir aussi