DBCC CHECKDB (Transact-SQL)

• 12/14/2017
• 22 minutes de lecture
• • p
  • M

  .

  • m
  • M
  • P
  • +3

S’applique à : SQL Server (toutes les versions prises en charge) Azure SQL Database

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 de la base de données.
• Valide la cohérence au niveau des liens entre les métadonnées des tables et les répertoires et fichiers du système de fichiers lors du stockage de données varbinaires(max) dans le système de fichiers à l’aide de FILESTREAM.
• Valide les données du courtier de services dans la base de données.

Cela signifie que les commandes DBCC CHECKALLOC, DBCC CHECKTABLE ou DBCC CHECKCATALOG ne doivent pas être exécutées séparément de DBCC CHECKDB. Pour des informations plus détaillées sur les contrôles effectués par ces commandes, consultez les descriptions de ces commandes.

Conventions de la syntaxe Transact-SQL

Syntaxe

DBCC CHECKDB ) ] } ] ] 

Arguments

nom_de_la_base | id_de_la_base | 0
C’est le nom ou l’ID de la base de données pour laquelle il faut exécuter des contrôles d’intégrité. S’il n’est pas spécifié, ou si 0 est spécifié, la base de données actuelle est utilisée. Les noms de base de données doivent respecter les règles relatives aux identificateurs.

NOINDEX
Précise que les vérifications intensives des index non groupés pour les tables utilisateur ne doivent pas être effectuées. Cela diminue le temps d’exécution global. 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 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 une certaine perte de données.

REPAIR_FAST
Maintient la syntaxe pour la compatibilité ascendante uniquement. Aucune action de réparation n’est effectuée.

REPAIR_REBUILD
Exécute des réparations qui n’ont aucune possibilité de perte de données. Cela peut inclure des réparations rapides, telles que la réparation des lignes manquantes dans les index non groupés, et des réparations plus longues, telles que la reconstruction d’un index.
Cet argument ne répare pas les erreurs impliquant des données FILESTREAM.

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 l’omission de cette option n’a aucun effet. Les messages d’erreur sont triés par ID d’objet, sauf pour les 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 contrôles de cohérence logique sur une vue indexée, des index XML et des index spatiaux, lorsqu’ils sont présents.
Pour plus d’informations, voir Exécution de contrôles de cohérence logique sur les index, dans la section Remarques plus loin dans cette rubrique.

NO_INFOMSGS
Supprime tous les messages d’information.

TABLOCK
Cause DBCC CHECKDB d’obtenir des verrous au lieu d’utiliser un instantané interne de la base de données. Cela inclut un verrou exclusif (X) à court terme sur la base de données. TABLOCK fera en sorte que DBCC CHECKDB s’exécute plus rapidement sur une base de données soumise à une forte charge, mais diminue la concurrence disponible sur la base de données pendant l’exécution de DBCC CHECKDB.

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

PHYSICAL_ONLY
Limite la vérification à l’intégrité de la structure physique des en-têtes de page et d’enregistrement et à la cohérence d’allocation de la base de données. Cette vérification est conçue pour fournir un petit contrôle de surcharge de la cohérence physique de la base de données, mais elle peut également détecter les pages déchirées, les échecs de somme de contrôle et les défaillances matérielles courantes qui peuvent compromettre les données d’un utilisateur.
Une exécution complète de DBCC CHECKDB peut prendre considérablement plus de temps que les versions précédentes. Ce comportement se produit parce que :

• Les vérifications logiques sont plus complètes.
• Certaines des structures sous-jacentes à vérifier sont plus complexes.
• De nombreuses nouvelles vérifications 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 grandes bases de données et est recommandée pour une utilisation fréquente sur les systèmes de production. Nous recommandons toujours qu’une exécution complète de DBCC CHECKDB soit effectuée périodiquement. La fréquence de ces exécutions dépend de facteurs propres aux entreprises individuelles et aux environnements de production.
  Cet argment implique toujours NO_INFOMSGS et n’est autorisé avec aucune des options de réparation.

DATA_PURITY
Cause DBCC CHECKDB de vérifier la base de données pour les valeurs de colonne qui ne sont pas valides ou hors de portée. Par exemple, DBCC CHECKDB détecte les colonnes dont les valeurs de date et d’heure sont supérieures ou inférieures à la plage acceptable pour le type de données datetime ; ou les colonnes de type de données décimales ou approximatives-numériques dont les valeurs d’échelle ou de précision ne sont pas valides.
Les contrôles d’intégrité des valeurs de colonne sont activés par défaut et ne nécessitent pas l’option DATA_PURITY. Pour les bases de données mises à niveau à partir de versions antérieures de SQL Server, les contrôles de valeurs de colonnes ne sont pas activés par défaut tant que DBCC CHECKDB WITH DATA_PURITY n’a pas été exécuté sans erreur sur la base de données. Après cela, DBCC CHECKDB vérifie l’intégrité des valeurs de colonne par défaut. Pour plus d’informations sur la façon dont CHECKDB pourrait être affecté par la mise à niveau de la base de données à partir de versions antérieures de SQL Server, consultez la section Remarques plus loin dans cette rubrique.

Les erreurs de validation signalées par cette option ne peuvent pas être corrigées par les options de réparation DBCC. Pour plus d’informations sur la correction manuelle de ces erreurs, consultez l’article 923247 de la base de connaissances : Troubleshooting DBCC error 2570 in SQL Server 2005 and later versions.

MAXDOP
Applications à : SQL Server ( SQL Server 2014 (12.x) SP2 et versions ultérieures).

Passe l’option de configuration de degré de parallélisme max de sp_configure pour l’instruction. Le 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 degré de parallélisme max sont applicables lorsque vous utilisez l’indice de requête MAXDOP. Pour plus d’informations, voir Configurer l’option de configuration du serveur degré maximal de parallélisme.

Remarques

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

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. Le fait de ne pas avoir une sérialisation cohérente des types définis par l’utilisateur ordonnés par octet provoque l’erreur 2537 lorsque DBCC CHECKDB est exécuté. Pour plus d’informations, consultez la section Exigences relatives aux types définis par l’utilisateur.

Parce que la base de données Resource n’est modifiable qu’en mode mono-utilisateur, la commande DBCC CHECKDB ne peut pas être exécutée directement sur celle-ci. Cependant, lorsque DBCC CHECKDB est exécutée contre la base de données principale, un second CHECKDB est également exécuté en interne sur la base de données Resource. Cela signifie que DBCC CHECKDB peut renvoyer des résultats supplémentaires. La commande renvoie des ensembles de résultats supplémentaires lorsqu’aucune option n’est définie, ou lorsque l’option PHYSICAL_ONLY ou ESTIMATEONLY est définie.

À partir de SQL Server 2005 (9.x) SP2, l’exécution de DBCC CHECKDB ne vide plus le cache de plan pour l’instance de SQL Server. Avant SQL Server 2005 (9.x) SP2, l’exécution de DBCC CHECKDB efface le cache des plans. L’effacement du cache des plans entraîne la recompilation de tous les plans d’exécution ultérieurs et peut provoquer une diminution soudaine et temporaire des performances des requêtes.

Exécution de contrôles de cohérence logique sur les index

Le contrôle de cohérence logique sur les index varie en fonction du niveau de compatibilité de la base de données, comme suit :

• Si le niveau de compatibilité est de 100 (SQL Server 2008) ou supérieur :
• Sans que NOINDEX soit spécifié, DBCC CHECKDB exécute des contrôles de cohérence physique et logique sur une seule table et sur tous ses index non groupés. Cependant, sur les index XML, les index spatiaux et les vues indexées, seuls les contrôles de cohérence physique sont effectués par défaut.
• Si WITH EXTENDED_LOGICAL_CHECKS est spécifié, les contrôles logiques sont effectués sur une vue indexée, les index XML et les index spatiaux, lorsqu’ils sont présents. Par défaut, les contrôles de cohérence physique sont effectués avant les contrôles 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 croisent la table d’index interne de l’objet index avec la table utilisateur qu’il référence. Pour trouver les lignes aberrantes, une requête interne est construite pour effectuer une intersection complète des tables interne et utilisateur. L’exécution de cette requête peut avoir un effet très élevé sur les performances, et sa progression ne peut pas être suivie. Par conséquent, nous vous recommandons de spécifier WITH EXTENDED_LOGICAL_CHECKS uniquement si vous suspectez des problèmes d’index qui ne sont pas liés à une corruption physique, ou si les checksums de niveau page ont été désactivés et que vous suspectez une corruption matérielle de niveau colonne.

• Si l’index est un index filtré, DBCC CHECKDB effectue des contrôles de cohérence pour vérifier que les entrées de l’index satisfont au prédicat du filtre.
• Si le niveau de compatibilité est de 90 ou moins, à moins que NOINDEX ne soit spécifié, DBCC CHECKDB effectue des contrôles de cohérence physique et logique sur une seule table ou vue indexée et sur tous ses index non groupés et XML. Les index spatiaux ne sont pas pris en charge.
• À partir 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 pour éviter les évaluations d’expression coûteuses. Cette modification réduit considérablement la durée de CHECKDB contre les bases de données contenant ces objets. Cependant, les contrôles de cohérence physique de ces objets sont toujours terminés. Ce n’est que lorsque l’option EXTENDED_LOGICAL_CHECKS est spécifiée que les évaluations d’expression seront effectuées en plus des vérifications logiques déjà présentes (vue indexée, index XML et index spatiaux) dans le cadre de l’option EXTENDED_LOGICAL_CHECKS.

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

• Voir ou modifier le niveau de compatibilité d’une base de données

Cliché interne de la base de données

DBCC CHECKDB utilise un cliché interne de la base de données pour la cohérence transactionnelle nécessaire à l’exécution de ces contrôles. Cela permet d’éviter les problèmes de blocage et de concurrence lors de l’exécution de ces commandes. Pour plus d’informations, consultez la section Afficher la taille du fichier épars d’un instantané de base de données (Transact-SQL) et la section Utilisation de l’instantané interne de base de données de DBCC (Transact-SQL). 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 exclusif de la base de données est nécessaire pour effectuer les contrôles d’allocation, et des verrous de table partagés sont nécessaires pour effectuer les contrôles de table.DBCC CHECKDB échoue lorsqu’il est exécuté contre master si un instantané de base de données interne ne peut pas être créé.L’exécution de DBCC CHECKDB contre tempdb n’effectue aucun contrôle d’allocation ou de catalogue et doit acquérir des verrous de table partagés pour effectuer les contrôles de table. Ceci est dû au fait 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.Dans Microsoft SQL Server 2012 ou une version antérieure de SQL Server, vous pouvez rencontrer des messages d’erreur lorsque vous exécutez la commande DBCC CHECKDB pour une base de données dont les fichiers sont situés sur un volume formaté ReFS. Pour plus d’informations, consultez l’article 2974455 de la base de connaissances : comportement de DBCC CHECKDB lorsque la base de données SQL Server est située sur un volume ReFS.

Vérification et réparation des données FILESTREAM

Lorsque FILESTREAM est activé pour une base de données et une table, vous pouvez éventuellement stocker des objets binaires volumineux (BLOB) varbinary(max) dans le système de fichiers. Lorsqu’il utilise DBCC CHECKDB sur une base de données qui stocke des 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 vérifie qu’il existe une correspondance biunivoque entre les répertoires et les fichiers du système de fichiers et les lignes, les colonnes et les valeurs des colonnes de la table. DBCC CHECKDB peut réparer la corruption si vous spécifiez l’option REPAIR_ALLOW_DATA_LOSS. Pour réparer la corruption FILESTREAM, DBCC supprimera toutes les lignes de table auxquelles il manque des données de système de fichiers.

Best Practices

Nous vous recommandons d’utiliser l’option PHYSICAL_ONLY pour une utilisation fréquente sur les systèmes de production. L’utilisation de PHYSICAL_ONLY peut considérablement réduire la durée d’exécution de DBCC CHECKDB sur les grandes bases de données. Nous vous recommandons également d’exécuter périodiquement DBCC CHECKDB sans options. La fréquence à laquelle vous devez effectuer ces exécutions dépend des entreprises individuelles et de leurs environnements de production.

Vérification 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éterminé par le processeur de requêtes. Le degré maximal de parallélisme est configuré tout comme 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, voir Configurer le degré maximal de parallélisme – Option de configuration du serveur. La vérification du parallélisme peut être désactivée en utilisant l’indicateur de suivi 2528. Pour plus d’informations, voir Drapeaux de trace (Transact-SQL).

Comprendre les messages d’erreur DBCC

Après la fin de la commande DBCC CHECKDB, un message est écrit dans le journal des erreurs de SQL Server. Si la commande DBCC s’exécute avec succès, le message indique le succès et la durée d’exécution de la commande. Si la commande DBCC s’arrête avant la fin de la vérification en raison d’une erreur, le message indique que la commande a été interrompue, une valeur d’état et le temps d’exécution de la commande. Le tableau suivant liste et décrit les valeurs d’état qui peuvent être incluses dans le message.

State	Description
0	L’erreur numéro 8930 a été soulevée. Cela indique une corruption des métadonnées qui a mis fin à la commande DBCC.
1	L’erreur numéro 8967 a été soulevée. Il y a eu une erreur interne DBCC.
2	Une défaillance s’est produite pendant la réparation de la base de données en mode d’urgence.
3	Cela indique une corruption des métadonnées qui a mis fin à la commande DBCC.
4	Une violation d’assertion ou d’accès a été détectée.
5	Une erreur inconnue s’est produite qui a mis fin à la commande DBCC.

Rapport d’erreurs

Un fichier de vidage (SQLDUMP*nnnn*.txt) est créé dans le répertoire LOG du serveur SQL chaque fois que DBCC CHECKDB détecte une erreur de corruption. Lorsque les fonctions de collecte de données d’utilisation des fonctionnalités et de rapport d’erreurs sont activées pour l’instance de SQL Server, le fichier est automatiquement transmis à Microsoft. Les données collectées sont utilisées pour améliorer les fonctionnalités de SQL Server. Le fichier dump contient les résultats de la commande DBCC CHECKDB et des sorties 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 de l’administrateur local. La commande DBCC n’échoue pas si le processus de collecte de données échoue.

Résolution des erreurs

Si des erreurs sont signalées par DBCC CHECKDB, nous recommandons de restaurer la base de données à partir de la sauvegarde de la base de données au lieu d’exécuter REPAIR avec l’une des options REPAIR. Si aucune sauvegarde n’existe, l’exécution de REPAIR corrige les erreurs signalées. L’option de réparation à utiliser est spécifiée à la fin de la liste des erreurs signalées. Cependant, la correction des erreurs à l’aide de l’option REPAIR_ALLOW_DATA_LOSS peut nécessiter la suppression de certaines pages, et donc de certaines données.

Dans certaines circonstances, des valeurs peuvent être entrées dans la base de données qui ne sont pas valides ou hors limites en fonction du type de données de la colonne. DBCC CHECKDB peut détecter les valeurs de colonne qui ne sont pas valides pour tous les types de données de colonne. Par conséquent, l’exécution de DBCC CHECKDB avec l’option DATA_PURITY sur des bases de données qui ont été mises à niveau à partir de versions antérieures de SQL Server peut révéler des erreurs de valeurs de colonnes préexistantes. Comme SQL Server ne peut pas réparer automatiquement ces erreurs, la valeur de la colonne doit être mise à jour manuellement. Si CHECKDB détecte une telle erreur, il renvoie un avertissement, le numéro d’erreur 2570 et des informations permettant d’identifier la ligne affectée et de corriger manuellement l’erreur.

La réparation peut être effectuée sous une transaction utilisateur pour laisser l’utilisateur annuler les modifications apportées. Si les réparations sont annulées, la base de données contiendra toujours des erreurs et devra être restaurée à partir d’une sauvegarde. Une fois les réparations terminées, sauvegardez la base de données.

Résolution des erreurs en mode d’urgence de la base de données

Lorsqu’une base de données a été mise en mode d’urgence à l’aide de 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 à des bases de données normalement irrécupérables d’être remises en ligne dans un état physiquement cohérent. Ces réparations doivent être utilisées en dernier recours et uniquement lorsque vous ne pouvez pas restaurer la base de données à partir d’une sauvegarde. Lorsque la base de données est définie en mode d’urgence, elle est marquée READ_ONLY, la journalisation est désactivée et l’accès est limité aux membres du rôle de serveur fixe sysadmin.

Lorsque la base de données est en mode d’urgence et que DBCC CHECKDB avec la clause REPAIR_ALLOW_DATA_LOSS est exécutée, les actions suivantes sont prises :

• DBCC CHECKDB utilise les pages qui ont été marquées inaccessibles en raison d’erreurs d’E/S ou de somme de contrôle, comme si les erreurs ne s’étaient pas produites. En faisant cela, vous augmentez les chances de récupération des données de la base de données.
• DBCC CHECKDB tente de récupérer la base de données en utilisant des techniques de récupération régulières basées sur le journal.
• 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 la perte de la cohérence transactionnelle.

Si la commande DBCC CHECKDB réussit, la base de données est dans un état de cohérence physique et l’état de la base de données est défini sur ONLINE. Cependant, la base de données peut contenir une ou plusieurs incohérences transactionnelles. Nous vous recommandons d’exécuter la commande 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 la commande DBCC CHECKDB avec l’option REPAIR_ALLOW_DATA_LOSS dans les 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) et la base de données de distribution utilisée par la réplication. Les bases de données de publication et d’abonnement comprennent des tables publiées et des tables de métadonnées de réplication. Soyez conscient des problèmes potentiels suivants dans ces bases de données :

• Tables publiées. Les actions effectuées par le processus CHECKDB pour réparer les données utilisateur corrompues peuvent ne pas être répliquées :
• La réplication par fusion utilise des déclencheurs pour suivre les modifications des tables publiées. Si des lignes sont insérées, mises à jour ou supprimées par le processus CHECKDB, les déclencheurs ne se déclenchent pas ; par conséquent, la modification n’est pas répliquée.
• La réplication transactionnelle utilise le journal des transactions pour suivre les modifications apportées aux tables publiées. L’agent de lecture du journal déplace ensuite ces modifications vers la base de données de distribution. Certaines réparations DBCC, bien que consignées, ne peuvent pas être répliquées par l’agent de lecture de journaux. Par exemple, si une page de données est désallouée par le processus CHECKDB, l’agent Log Reader ne traduit pas cela en une instruction DELETE ; par conséquent, la modification n’est pas répliquée.
• Tables de métadonnées de réplication. Les actions effectuées par le processus CHECKDB pour réparer les tables de métadonnées de réplication corrompues nécessitent de supprimer et de reconfigurer 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 une base de données de distribution :

1. Quivez le système : Arrêtez l’activité sur la base de données et sur toutes les autres bases de données de la topologie de réplication, puis essayez de synchroniser tous les nœuds. Pour plus d’informations, consultez la section Mise en veille d’une topologie de réplication (programmation Transact-SQL de réplication).
2. Exécutez DBCC CHECKDB.
3. Si le rapport DBCC CHECKDB inclut des réparations pour toute table de la base de données de distribution ou toute table 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 la section Désactiver la publication et la distribution.
4. Si le rapport DBCC CHECKDB inclut des réparations pour toute table répliquée, effectuez une validation des données pour déterminer s’il existe des différences entre les données des bases de données de publication et d’abonnement.

Jeux de résultats

DBCC CHECKDB renvoie le jeu de résultats suivant. Les valeurs peuvent varier sauf lorsque 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 renvoie l’ensemble de résultats (message) suivant lorsque NO_INFOMSGS est spécifié :

 The command(s) completed successfully.

DBCC CHECKDB renvoie le jeu de résultats suivant lorsque 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 renvoie le jeu de résultats suivant lorsque 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.

Permissions

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

Exemples

A. Vérification de la base de données actuelle 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, 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)
Voir la taille du fichier épars d’un instantané de base de données (Transact-SQL)
sp_helpdb (Transact-SQL)
Tables système (Transact-SQL)

.