DBCC CHECKDB (Transact-SQL)

S’applique à : SQL Server (toutes les versions prises en charge) 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.

Notes

DBCC CHECKDB est pris en charge sur les bases de données contenant des tables mémoire optimisées, mais la validation se produit uniquement 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.

Étant donné que options de réparation de DBCC ne sont pas disponibles pour les tables mémoire optimisées, 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.

Topic link iconConventions 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 ]    
        }    
    ]    
]    

Notes

Pour afficher la syntaxe Transact-SQL pour SQL Server 2014 et versions antérieures, consultez Versions antérieures de la documentation.

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. 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 qu’une base de données soit dans 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 principale méthode pour récupérer suite aux erreurs signalées par DBCC CHECKDB. L'option REPAIR_ALLOW_DATA_LOSS n'est pas une alternative pour la restauration à partir d'une sauvegarde reconnue fiable. Il s’agit d’une option d’urgence de « dernier recours », recommandée seulement si la restauration à partir d’une sauvegarde n’est pas possible.

Certaines erreurs, qui peuvent uniquement être réparées à l'aide de l'option REPAIR_ALLOW_DATA_LOSS, peuvent nécessiter de désallouer une ligne, une page ou une série de pages pour effacer 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 (à l'aide de DBCC CHECKCONSTRAINTS) après avoir utilisé l'option REPAIR_ALLOW_DATA_LOSS.

Avant d'effectuer la réparation, créez des copies physiques des fichiers qui appartiennent à cette base de données. Cela comprend le fichier de données principal (.mdf), les fichiers de données secondaires (.ndf), tous les fichiers de journaux de transactions (.ldf) et 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 optimisées en mémoire, etc.

Avant d'effectuer la réparation, modifiez l'état de la base de données en mode d'urgence et essayez d'extraire autant d'informations que possible à partir 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

Dans la mesure où DBCC CHECKDB est entièrement journalisé et récupérable avec n’importe quelle option REPAIR, Microsoft recommande toujours d’utiliser 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 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 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 la commande 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 la commande 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 (SQL Server 2008) ou supérieur, effectue des vérifications de cohérence logique sur une vue indexée, des index XML et des index spatiaux, là où ils sont présents.
Pour plus d’informations, consultez Exécution de vérifications de cohérence logique sur des index dans la section Notes, plus loin dans cet article.

NO_INFOMSGS
Supprime tous les messages d'information.

TABLOCK
Génère des verrouillages par DBCC CHECKDB 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 accélère l’exécution de DBCC CHECKDB sur une base de données dont la charge est importante, tout en diminuant la concurrence disponible dans 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 Service Broker ne sont pas validées.

ESTIMATEONLY
Affiche une estimation de la quantité d’espace 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 des bases de données volumineuses, 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 ignorera toutes les vérifications des données FILESTREAM.

DATA_PURITY
Génère la vérification de la base de données par DBCC CHECKDB pour les valeurs de colonnes qui ne sont pas valides ou 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. Cette commande identifie aussi des colonnes de type decimal ou numeric approximatif avec des valeurs d’échelle ou de précision qui ne sont pas valides.
Les vérifications d’intégrité sur la base colonne-valeur sont activées par défaut et ne nécessitent pas l’option DATA_PURITY. Pour les bases de données mises à niveau à partir des versions antérieures de SQL Server, les vérifications sur la base colonne-valeur ne sont pas activées par défaut tant que la commande DBCC CHECKDB WITH DATA_PURITY n'est pas 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 les incidences sur CHECKDB suite à une mise à niveau de la base de données à partir de versions antérieures de SQL Server, consultez la section Notes, plus loin dans cette rubrique.

Avertissement

Si PHYSICAL_ONLY est spécifié, l'intégrité des colonnes n'est pas vérifiée.

Les erreurs de validation signalées par cette option ne peuvent pas être corrigées à l'aide des options de réparation 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 (SQL Server 2014 (12.x) SP2 et versions ultérieures).

Remplace l’option de configuration max degree of parallelism de sp_configure pour l’instruction. MAXDOP peut dépasser 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 sont applicables lorsque 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 avec la valeur 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. En l'absence de sérialisation cohérente de type défini par l'utilisateur ordonné par octet, l'erreur 2537 est générée à l'exécution de DBCC CHECKDB. Pour plus d’informations, consultez Configuration requise pour les types définis par l’utilisateur.

Étant donné que la base de données Resource est modifiable uniquement 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) SP2, l’exécution de la commande DBCC CHECKDB n’efface plus le cache du plan pour l’instance de SQL Server. Avant SQL Server 2005 (9.x) SP2, 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écution de 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 égal à 100 (SQL Server 2008) ou supérieur :
  • À moins que l'option NOINDEX soit spécifiée, DBCC CHECKDB effectue des vérifications de cohérence physique et logique sur une table individuelle et 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 très important 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 de l'index satisfont le 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 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, 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 vous ne pouvez créer aucun instantané ou si TABLOCK est spécifié, la commande 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 il est exécuté sur une base de données master s’il n’est pas possible de créer d’instantané de base de données interne. L’exécution de la commande DBCC CHECKDB sur tempdb ne procède à aucune allocation et ne vérifie aucun catalogue. Elle doit acquérir des verrous de table partagés pour vérifier ces tables. En effet, 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 une base de données par instantané interne.

  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 contient trois fichiers E:\Data\my_DB.mdf, E:\Data\my_DB.ndf et E:\Data\my_DB.ldf, la base de données par instantané interne est créée à l’aide des fichiers E:\Data\my_DB.mdf_MSSQL_DBCC11 et E:\Data\my_DB.ndf_MSSQL_DBCC11. Notez que la valeur database_id de l’instantané est database_id + 1. Notez également que les nouveaux fichiers sont créés dans le même dossier suivant la convention d’affectation de noms <nom-fichier.extension>_MSSQL_DBCC<ID-capture-instantanée-base-de-données>. 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 du 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 au cours de la commande DBCC CHECKDB. La taille des nouveaux fichiers est identique à celle du fichier .mdf ou .ndf.

  4. Les nouveaux fichiers sont supprimés à la fin du traitement 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 occupent de l’espace et risquent de provoquer des défaillances lors des exécutions DBCC CHECKDB ultérieures. 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

Dans SQL Server 2012 et versions antérieures, les flux de fichiers nommés étaient utilisés à la place pour créer les fichiers d’instantanés internes. 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 et versions antérieures, 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). Pour plus d’informations, consultez l’article 2974455 de la Base de connaissances Microsoft : Comportement de DBCC CHECKDB quand la base de données SQL Server se trouve sur un volume ReFS.

Vérification et réparation des 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. Lorsque 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 du lien 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 vérifiera 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 nettement le temps d'exécution de DBCC CHECKDB sur des bases de données volumineuses. Nous vous conseillons également d'exécuter régulièrement DBCC CHECKDB sans option. La fréquence à laquelle vous devez effectuer ces exécutions dépend de chaque activité et de son environnement de production.

Vérification des objets en parallèle

DBCC CHECKDB effectue par défaut 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 à l'aide de 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 les vérifications de cohérence parallèles dans la section Gestion de SGBDR de Fonctionnalités prises en charge par les éditions de SQL Server 2016.

Présentation des messages d'erreur de DBCC

Une fois la commande DBCC CHECKDB exécutée, un message est consigné dans le journal d'erreurs de 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 2019-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 plutôt que 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 à l'aide de l'option REPAIR_ALLOW_DATA_LOSS risque de nécessiter que certaines pages, et par conséquent certaines données, soient supprimé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 à partir de versions antérieures de SQL Server risque de révéler des erreurs pré-existantes de valeur-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 adéquate 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ésolution des erreurs en mode urgence dans la base de données

Quand une base de données a été placée en mode urgence à l’aide de l’instruction ALTER DATABASE et que l’option REPAIR_ALLOW_DATA_LOSS est spécifiée, DBCC CHECKDB peut réaliser certaines réparations particulières sur la base de données. 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 uniquement lorsque 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 restaurer celle-ci au terme de l'exécution.

Si la base de données est placée 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 aucune erreur ne s'était produite. 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 au moyen de techniques classiques de récupération basées sur les fichiers journaux.
  • Si, en raison de la corruption du journal des transactions, la récupération de la base de données échoue, le journal de 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é prise en charge de SQL Server. 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 principale méthode pour récupérer suite aux erreurs signalées par DBCC CHECKDB. L’option REPAIR_ALLOW_DATA_LOSS n’est pas une alternative pour une restauration à partir d’une sauvegarde reconnue fiable. Il s’agit d’une option d’urgence de « 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 prend la valeur 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écution de 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 avoir des conséquences sur les bases de données utilisateur (bases de données de publication et d'abonnement) ainsi que sur 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. Il est possible que les actions effectuées par le processus CHECKDB pour réparer les données utilisateur corrompues ne soient pas 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 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 dans le journal, 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 CHECKDB, l'Agent de lecture du journal ne la convertit pas en instruction DELETE ; par conséquent, la modification n'est pas répliquée.
  • Tables de métadonnées de réplication. Pour les actions effectuées par le processus CHECKDB afin de réparer les tables de métadonnées de réplication corrompues, la réplication doit être supprimée puis reconfigurée.

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 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 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 risquent de varier, à moins que les options ESTIMATEONLY, PHYSICAL_ONLY ou NO_INFOMSGS soient 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) si NO_INFOMSGS est spécifié :

 The command(s) completed successfully.

DBCC CHECKDB retourne le jeu de résultats suivant si 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 si 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 serveur fixe sysadmin ou au rôle de base de données fixe db_owner.

Exemples

R. Vérification de la base de données active et d'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 AdventureWorks2012.

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

B. Vérification de la base de données actuelle et suppression des 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

DBCC (Transact-SQL)
Afficher la taille du fichier partiellement alloué d'un instantané de base de données (Transact-SQL)
sp_helpdb (Transact-SQL)
Tables système (Transact-SQL)