DBCC CHECKDB (Transact-SQL)

Article
05/03/2025

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. Toutefois, dans le cadre de la sauvegarde et de la récupération de la base de données, une validation CHECKSUM est effectuée pour les fichiers dans les groupes de fichiers à mémoire optimisée.

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

syntaxsql

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 sont 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. Utilisez les options REPAIR_* uniquement comme 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 peut entraîner plus de perte de données que si vous effectuez une restauration à partir d’une dernière sauvegarde correcte connue. Consultez avertissement de perte de données avec REPAIR_ALLOW_DATA_LOSS

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. Il s’agit d’une option d’urgence dernier recours recommandée pour une utilisation uniquement si la restauration à partir d’une sauvegarde n’est pas possible.

Certaines erreurs, qui ne peuvent être réparées qu’à l’aide de l’option REPAIR_ALLOW_DATA_LOSS, peuvent impliquer l’allocation d’une ligne, d’une page ou d’une série de pages pour effacer les erreurs. Toutes les données libérées ne sont plus accessibles ni récupérables pour l’utilisateur, et le contenu exact des données libérées ne peut pas être déterminé. Par conséquent, l’intégrité référentielle peut ne pas être précise après que des lignes ou des pages soient libérées, 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, telles que la réparation de lignes manquantes dans des index non cluster et des réparations plus fastidieuses, telles que la reconstruction d’un index.

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

Important

Étant donné que DBCC CHECKDB avec l’une des options de REPAIR_* sont entièrement journalisées et récupérables, Microsoft recommande toujours à un utilisateur d’utiliser DBCC CHECKDB avec toutes les options de REPAIR_* dans une transaction (exécuter BEGIN TRANSACTION avant d’exécuter la commande) afin que l’utilisateur puisse confirmer qu’il souhaite 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 souhaite pas accepter les résultats de l’opération, il peut exécuter un 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 tiennent pas compte des contraintes qui peuvent exister sur ou entre des 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 pour trouver 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 entraîne l’exécution de DBCC CHECKDB plus rapidement sur une base de données sous une charge importante, mais diminue la concurrence disponible sur la base de données pendant que DBCC CHECKDB est en cours d’exécution.

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 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 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 peut entraîner une durée d’exécution beaucoup plus courte pour DBCC CHECKDB sur les bases de données volumineuses et est recommandée pour une utilisation fréquente sur les 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 plus d’informations sur la correction manuelle de ces erreurs, consultez MSSQLSERVER_2570.

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 max degree of parallelism s’appliquent lorsque vous utilisez l’indicateur de requête MAXDOP. Pour plus d’informations, consultez Configuration du serveur : degré maximal de parallélisme.

Avertissement

Si MAXDOP est défini sur zéro, SQL Server choisit l'max degree of parallelism à 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 les 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 Création de types User-Defined - Configuration requise.

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.

Dans SQL Server 2005 (9.x) Service Pack 2 et versions ultérieures, l’exécution d'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. L’effacement du cache du plan entraîne la recompilation de tous les plans d’exécution ultérieurs et peut entraîner une diminution soudaine et temporaire 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 vérifient de manière croisée la table d’index interne de l’objet d’index avec la table utilisateur référencée. 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.
Dans SQL Server 2016 (13.x) et versions ultérieures, des vérifications supplémentaires sur les colonnes calculées persistantes, les colonnes UDT et les index filtrés ne s’exécutent pas par défaut pour é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.

Découvrir le niveau de compatibilité d’une base de données

Voir ou modifier 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 afficher la taille du fichier partiellement alloué d’un de capture instantanée de base de données et la section utilisation de l’instantané de base de données interne DBCC dans 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

DBCC CHECKDB crée un instantané interne de la base de données.
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.ndfet E:\Data\my_DB.ldf, la base de données d’instantané interne est créée à l’aide de E:\Data\my_DB.mdf_MSSQL_DBCC11 et de fichiers 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.
Les nouveaux fichiers sont marqués comme fichiers partiellement alloués au niveau du système de fichiers. La taille sur 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 pendant la commande DBCC CHECKDB. Le Taille des nouveaux fichiers est le même que le fichier .mdf ou .ndf.
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 pendant que la commande DBCC CHECKDB est en cours, ces fichiers ne sont pas nettoyés. Ils prennent de l’espace et peuvent potentiellement provoquer des défaillances sur les exécutions futures de DBCC CHECKDB. Dans ce cas, vous pouvez supprimer ces nouveaux fichiers après avoir confirmé qu’il n’existe aucune commande DBCC CHECKDB 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 fichiers ordinaires tels que l’Explorateur Windows. Par conséquent, dans SQL Server 2012 (11.x) et versions antérieures, vous pouvez rencontrer des messages d’erreur 7926 et 5030 lorsque vous exécutez la commande DBCC CHECKDB pour les fichiers de base de données situés sur un volume ReFS-formaté. Cela est dû au fait que les flux de fichiers ne peuvent pas être créés sur de système de fichiers résilient (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 un varbinary(max) colonne qui utilise l’attribut FILESTREAM, DBCC CHECKDB vérifie qu’il existe un mappage un-à-un entre les répertoires du système de fichiers et les fichiers et les lignes de table, les colonnes et les valeurs de colonne. 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 table manquantes dans le 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 :

Output

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 Configuration du serveur : degré maximal de parallélisme. La vérification parallèle peut être désactivée avec l’indicateur de trace 2528. Pour plus d’informations, consultez indicateurs de trace.

Notes

Cette fonctionnalité n’est pas disponible dans chaque édition 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.

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 vidage de pile (SQLDump<nnnn>.txt, SQLDump<nnnn>.log, SQLDump<nnnn>.mdmp) est créé dans le répertoire sql Server LOG chaque fois que DBCC CHECKDB détecte une erreur d’altération. 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 la sauvegarde de base de données, au lieu d’exécuter DBCC CHECKDB avec l’une des options de REPAIR_*. 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 les réparations sont restaurées, la base de données contient toujours des erreurs et doit être restaurée à 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 permettre de remettre en ligne des bases de données normalement irrécupérables dans un état physiquement cohérent. 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. Lorsque la base de données est définie sur le mode d’urgence, la base de données est marquée 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 d’urgence à l’intérieur d’une transaction utilisateur et restaurer 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 entraîner une perte de cohérence transactionnelle.

Avertissement

L’option REPAIR_ALLOW_DATA_LOSS peut entraîner plus de perte de données que si vous effectuez une restauration à partir d’une dernière sauvegarde correcte connue. Consultez avertissement de perte de données avec REPAIR_ALLOW_DATA_LOSS

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.

Avertissement de perte de données avec REPAIR_ALLOW_DATA_LOSS

L’option REPAIR_ALLOW_DATA_LOSS est une fonctionnalité de SQL Server prise en charge. Toutefois, il peut ne pas toujours s’agir de la meilleure option pour amener une base de données à un état physiquement cohérent. Si elle réussit, l’option REPAIR_ALLOW_DATA_LOSS peut entraîner une perte de données.

En fait, il peut entraîner une perte de données plus importante que si un utilisateur devait restaurer la base de données à partir de la dernière sauvegarde correcte connue. 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 dernier recours recommandée pour une utilisation uniquement si la restauration à partir d’une sauvegarde n’est pas possible.

Une fois le journal reconstruit, il n’existe aucune garantie ACID complète.

Une fois le journal regénéré, DBCC CHECKDB est automatiquement effectué et les rapports et corrigent 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 est laissée à sa taille par défaut et doit être ajustée manuellement à sa taille récente.

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 :

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).
Exécutez DBCC CHECKDB.
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.
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.

Jeu de résultats

DBCC CHECKDB retourne le jeu de résultats suivant. Les valeurs peuvent varier à l’exception des options ESTIMATEONLY, PHYSICAL_ONLYou NO_INFOMSGS spécifiées :

Output

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é :

Output

The command(s) completed successfully.

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

Output

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é.

Output

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 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.

SQL

-- 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.

SQL

DBCC CHECKDB WITH NO_INFOMSGS;
GO

Partager via

DBCC CHECKDB (Transact-SQL)

Syntaxe

Arguments

database_name | database_id | 0

NOINDEX

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

ALL_ERRORMSGS

EXTENDED_LOGICAL_CHECKS

NO_INFOMSGS

TABLOCK

ESTIMATEONLY

PHYSICAL_ONLY

DATA_PURITY

MAXDOP

Notes

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

Découvrir le niveau de compatibilité d’une base de données

Instantané de base de données interne

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

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

Bonnes pratiques

Vérifier des objets en parallèle

Comprendre les messages d’erreur de DBCC

Rapport d’erreurs

Résolution des erreurs

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

Avertissement de perte de données avec REPAIR_ALLOW_DATA_LOSS

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

Jeu de résultats

Autorisations

Exemples

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

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

Commentaires

Ressources supplémentaires

Partager via

DBCC CHECKDB (Transact-SQL)

Syntaxe

Arguments

database_name | database_id | 0

NOINDEX

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

ALL_ERRORMSGS

EXTENDED_LOGICAL_CHECKS

NO_INFOMSGS

TABLOCK

ESTIMATEONLY

PHYSICAL_ONLY

DATA_PURITY

MAXDOP

Notes

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

Découvrir le niveau de compatibilité d’une base de données

Instantané de base de données interne

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

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

Bonnes pratiques

Vérifier des objets en parallèle

Comprendre les messages d’erreur de DBCC

Rapport d’erreurs

Résolution des erreurs

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

Avertissement de perte de données avec REPAIR_ALLOW_DATA_LOSS

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

Jeu de résultats

Autorisations

Exemples

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

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

Contenu connexe

Commentaires

Ressources supplémentaires