DBCC CHECKTABLE (Transact-SQL)

Article
04/26/2023

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

Vérifie l'intégrité de toute les pages et structures qui composent la table ou la vue indexée.

Syntaxe

DBCC CHECKTABLE
(
    table_name | view_name
    [ , { NOINDEX | index_id }
     | , { 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

table_name | view_name

Table ou vue indexée pour laquelle exécuter des vérifications d'intégrité. Les noms de table ou de vue doivent suivre les règles applicables aux identificateurs.

NOINDEX

Spécifie de ne pas faire de vérifications intensives des index non cluster pour les tables utilisateur. Cela 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 tous les index des tables système.

index_id

Numéro d’identification (ID) de l’index pour lequel effectuer des vérifications d’intégrité. Si index_id est spécifié, DBCC CHECKTABLE exécute les vérifications d’intégrité uniquement sur cet index, en même temps que le segment de mémoire ou l’index cluster.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

Spécifie que DBCC CHECKTABLE répare les erreurs trouvées. Pour utiliser une option de réparation, la base de données doit être en mode Utilisateur unique.

REPAIR_ALLOW_DATA_LOSS

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

La syntaxe n'est conservée que pour la compatibilité descendante. Aucune réparation n'est effectuée.
REPAIR_REBUILD

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

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

Important

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

ALL_ERRORMSGS

Affiche un nombre illimité d'erreurs. Tous les messages d'erreur sont affichés par défaut. La spécification ou non de cette option n'a aucun effet.

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 Faire des 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

Quand cette option est spécifiée, DBCC CHECKTABLE obtient un verrou de table partagé au lieu d’utiliser un instantané de base de données interne. TABLOCK accélère l'exécution de DBCC CHECKTABLE sur une table dont la charge est importante, tout en diminuant la concurrence possible sur la table pendant l'exécution de DBCC CHECKTABLE.

ESTIMATEONLY

Affiche une estimation de la quantité d’espace tempdb nécessaire pour exécuter DBCC CHECKTABLE avec toutes les autres options spécifiées.

PHYSICAL_ONLY

Limite la vérification à l'intégrité de la structure physique de la page, des en-têtes d'enregistrement et de la structure physique des arbres B (B-trees). Conçue pour effectuer un léger contrôle de la cohérence physique de la table, cette vérification peut également détecter les pages endommagées et les erreurs matérielles courantes susceptibles de compromettre les données. Une exécution complète de DBCC CHECKTABLE peut prendre beaucoup plus de temps que dans les versions antérieures. Ce comportement se produit pour les raisons suivantes :

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.

Notes

De manière générale, la documentation SQL Server utilise le terme B-tree en référence aux index. Dans les index rowstore, SQL Server implémente une structure B+. Cela ne s’applique pas aux index columnstore ou aux magasins de données en mémoire. Pour plus d’informations, consultez le Guide de conception et d’architecture d’index SQL Server et Azure SQL.

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 CHECKTABLE sur les tables 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 CHECKTABLE. La fréquence de ces exécutions dépend de facteurs spécifiques à chaque entreprise et à chaque environnement de production. PHYSICAL_ONLY implique toujours NO_INFOMSGS et n’est autorisé avec aucune des options de réparation.

Notes

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

DATA_PURITY

Quand cette option est spécifiée, DBCC CHECKTABLE vérifie si la table contient des valeurs de colonne non valides ou hors limites. Par exemple, DBCC CHECKTABLE détecte les colonnes où des valeurs de date et heure sont en dehors de la plage acceptable pour le type de données DateHeure, ou encore les colonnes de type de données décimal ou numérique approximatif qui contiennent des valeurs d’échelle ou de précision non valides.

Les vérifications d’intégrité des valeurs de colonne sont activées par défaut et ne requièrent pas l’option DATA_PURITY. Pour les bases de données mises à niveau à partir d’une version antérieure de SQL Server, vous pouvez utiliser DBCC CHECKTABLE WITH DATA_PURITY pour détecter et corriger les erreurs sur une table spécifique. Toutefois, les vérifications des valeurs de colonne sur la table 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 et DBCC CHECKTABLE vérifient l’intégrité des valeurs de colonne par défaut.

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

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

MAXDOP

S’applique à : SQL Server 2014 (12.x) Service Pack 2 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 utilise la valeur MAXDOP de Resource Governor, décrite dans ALTER WORKLOAD GROUP (Transact-SQL). 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.

Notes

Si MAXDOP est défini avec la valeur zéro, le serveur choisit le degré maximal de parallélisme.

Notes

Pour exécuter DBCC CHECKTABLE sur chaque table de la base de données, utilisez DBCC CHECKDB.

Pour la table spécifiée, DBCC CHECKTABLE vérifie les points suivants :

si les pages de données d'index, dans la ligne, LOB et de dépassement de capacité de ligne sont correctement liées ;
l'ordre de tri des index est correct ;
les pointeurs sont cohérents ;
chaque page contient une quantité raisonnable de données, y compris les colonnes calculées ;
les décalages de page sont acceptables ;
chaque ligne de la table de base possède une ligne correspondante dans chaque index non-cluster, et vice-versa ;
chaque ligne d'une table ou d'un index partitionné figure dans la partition correcte.
la cohérence au niveau du lien entre le système de fichiers et la table lors du stockage de données varbinary(max) dans le système de fichiers à l’aide de FILESTREAM.

Faire 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 supérieur ou égal à 100 (SQL Server 2008 (10.0.x)) :
- Sauf si NOINDEX est spécifié, DBCC CHECKTABLE effectue les vérifications de la cohérence physique et logique sur une table ainsi que sur tous ses index non cluster. Toutefois, seules des vérifications de cohérence physique sont effectuées par défaut sur les index XML, les index spatiaux et les vues indexées.
- Si WITH EXTENDED_LOGICAL_CHECKS est spécifié, des vérifications logiques sont effectuées sur une vue indexée, des index XML et des index spatiaux, là où ils sont présents. Par défaut, les vérifications de cohérence physique sont effectuées avant les vérifications de cohérence logique. Si NOINDEX est également spécifié, seules les vérifications logiques sont effectuées.
  
  Ces vérifications de cohérence logique effectuent une vérification croisée de la table d'index interne de l'objet d'index avec la table utilisateur à laquelle il fait référence. Pour rechercher les lignes excentrées, une requête interne est construite pour effectuer l'intersection complète de la table interne et de la table utilisateur. L'exécution de cette requête peut avoir un large impact sur les performances. Par ailleurs, le suivi de sa progression n’est pas possible. 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 CHECKTABLE effectue des vérifications de cohérence pour vérifier que les entrées d’index satisfont au prédicat du filtre.
À compter de SQL Server 2016 (13.x), les vérifications supplémentaires sur les colonnes calculées persistantes, les colonnes UDT et les index filtrés ne sont pas exécutées par défaut afin d’éviter les évaluations d’expressions coûteuses. Ce changement réduit considérablement la durée de CHECKTABLE sur les bases de données contenant ces objets. Cependant, les vérifications de cohérence physique de ces objets sont toujours effectuées. Les évaluations des expressions sont effectuées uniquement quand l’option EXTENDED_LOGICAL_CHECKS est spécifiée, en plus des vérifications logiques (vue indexée, index XML et index spatiaux) déjà définies avec l’option EXTENDED_LOGICAL_CHECKS.
Si le niveau de compatibilité est égal ou inférieur à 90 (SQL Server 2005 (9.x)) et si l’option NOINDEX n’est pas spécifiée, DBCC CHECKTABLE effectue à la fois des vérifications de la cohérence physique et logique sur une table ou une vue indexée et sur tous les index XML et non cluster associés. Les index spatiaux ne sont pas pris en charge.

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

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

Instantané de base de données interne

DBCC CHECKTABLE utilise un instantané de base de données interne pour fournir la cohérence transactionnelle nécessaire pour effectuer ces vérifications. Pour plus d’informations, consultez Voir la taille du fichier partiellement alloué d’un instantané de base de données (Transact-SQL) et la section Utilisation d’un instantané de base de données interne DBCC dans DBCC (Transact-SQL).

Si un instantané ne peut pas être créé ou si TABLOCK est spécifié, DBCC CHECKTABLE acquiert un verrou de table partagé pour obtenir la cohérence requise.

Notes

Si DBCC CHECKTABLE est exécuté sur tempdb, il doit acquérir un verrou de table partagé. 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.

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 CHECKTABLE sur une table qui stocke des objets Blob dans le système de fichiers, DBCC vérifie la cohérence au niveau des liens entre le système de fichiers et la base de données.

Par exemple, si une table contient une colonne varbinary(max) qui utilise l’attribut FILESTREAM, DBCC CHECKTABLE va vérifier qu’il existe un mappage un-à-un entre les répertoires et fichiers du système de fichiers et les lignes, colonnes et valeurs de colonne dans la table. DBCC CHECKTABLE peut réparer l’altération si vous spécifiez l’option REPAIR_ALLOW_DATA_LOSS. Pour réparer l'altération de FILESTREAM, DBCC supprimera toutes les lignes de la table où il manque des données du système de fichiers, et supprimera tous les répertoires et fichiers qui ne sont pas mappés à une ligne, colonne ou valeur de colonne dans la table.

Vérifier des objets en parallèle

Par défaut, DBCC CHECKTABLE 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é maximal de parallélisme est configuré de la même manière que celui des requêtes parallèles. Pour limiter le nombre maximal de processeurs disponibles pour la vérification DBCC, utilisez sp_configure. Pour plus d’informations, consultez Configurer l’option de configuration du serveur max degree of parallelism.

La vérification parallèle peut être désactivée avec l’indicateur de trace 2528. Pour plus d’informations, consultez Indicateurs de trace (Transact-SQL).

Notes

Pendant une opération DBCC CHECKTABLE, les octets stockés dans une colonne de type défini par l'utilisateur ordonné par octet doivent être identiques à la sérialisation calculée de la valeur du type défini par l'utilisateur. Dans le cas contraire, la routine DBCC CHECKTABLE signalera une erreur de cohérence.

Notes

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

Comprendre les messages d’erreur de DBCC

Une fois la commande DBCC CHECKTABLE 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 et 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 provoqué l'arrêt de 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 provoqué l'arrêt de 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.

Rapport d’erreurs

Un fichier minidump (SQLDUMP<nnnn>.txt) est créé dans le répertoire LOG de SQL Server chaque fois que DBCC CHECKTABLE 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 CHECKTABLE ainsi que des informations de diagnostic supplémentaires. Ce fichier contient des listes de contrôle d'accès discrétionnaire (DACL, Discretionary Access Control Lists) avec accès restreint. 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 en cas d’échec du processus de collecte des données.

Résolution des erreurs

Si DBCC CHECKTABLE signale des erreurs, nous vous recommandons de restaurer la base de données à partir de sa sauvegarde au lieu d’exécuter REPAIR avec une des options correspondantes. S'il n'existe aucune sauvegarde, l'exécution de REPAIR peut corriger les erreurs qui sont signalées. L'option REPAIR à utiliser est spécifiée à la fin de la liste des erreurs signalées. Cependant, la correction des erreurs avec l'option REPAIR_ALLOW_DATA_LOSS peut nécessiter la suppression de certaines pages et, par conséquent, de certaines données.

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 annulées, la base de données contiendra encore des erreurs et il faudra donc la restaurer à partir d'une sauvegarde. Une fois toutes les réparations effectuées, sauvegardez la base de données.

Jeux de résultats

DBCC CHECKTABLE retourne le jeu de résultats suivant. Le même jeu de résultats est retourné si vous spécifiez uniquement le nom de la table ou l'une des options.

DBCC results for 'HumanResources.Employee'.
There are 288 rows in 13 pages for object 'Employee'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKTABLE retourne le jeu de résultats suivant si l'option ESTIMATEONLY est spécifiée :

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

Autorisations

L’utilisateur doit être propriétaire de la table ou être membre du rôle serveur fixe sysadmin, du rôle de base de données fixe db_owner ou du rôle de base de données fixe db_ddladmin.

Exemples

R. Vérifier une table spécifique

L’exemple suivant vérifie l’intégrité des pages de données de la table HumanResources.Employee dans la base de données AdventureWorks2022.

DBCC CHECKTABLE ('HumanResources.Employee');
GO

B. Faire une vérification de faible charge d'une table

L’exemple suivant effectue une vérification de faible charge de la table Employee dans la base de données AdventureWorks2022.

DBCC CHECKTABLE ('HumanResources.Employee') WITH PHYSICAL_ONLY;
GO

C. Vérifier un index spécifique

Cet exemple contrôle un index spécifique obtenu lors de l'accès à sys.indexes.

DECLARE @indid int;
SET @indid = (SELECT index_id
              FROM sys.indexes
              WHERE object_id = OBJECT_ID('Production.Product')
                    AND name = 'AK_Product_Name');
DBCC CHECKTABLE ('Production.Product',@indid);

Partager via

DBCC CHECKTABLE (Transact-SQL)

Syntaxe

Arguments

table_name | view_name

NOINDEX

index_id

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

ALL_ERRORMSGS

EXTENDED_LOGICAL_CHECKS

NO_INFOMSGS

TABLOCK

ESTIMATEONLY

PHYSICAL_ONLY

DATA_PURITY

MAXDOP

Notes

Faire des vérifications de cohérence logique sur des index

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

Instantané de base de données interne

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

Vérifier des objets en parallèle

Comprendre les messages d’erreur de DBCC

Rapport d’erreurs

Résolution des erreurs

Jeux de résultats

Autorisations

Exemples

R. Vérifier une table spécifique

B. Faire une vérification de faible charge d'une table

C. Vérifier un index spécifique

Voir aussi

Commentaires

Ressources supplémentaires