DBCC CHECKTABLE (Transact-SQL)

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

Conventions de la syntaxe de Transact-SQL

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 } ] 
        }
    ]

Arguments

• table_name | view_name
  Table ou vue indexée pour laquelle exécuter des vérifications d'intégrité. Les noms de tables ou de vues doivent respecter les conventions applicables aux identificateurs.

• NOINDEX
  Indique qu'il ne faut pas effectuer de vérifications intensives des index non-cluster pour les tables utilisateur. Cela réduit le temps d'exécution global. NOINDEX n'affecte pas les tables système car les contrôles d'intégrité sont toujours effectués sur tous les index des tables système.

• index_id
  Identificateur d'index pour lequel la vérification de l'intégrité est effectuée. Si index_id est spécifié, DBCC CHECKTABLE exécute uniquement les vérifications d'intégrité sur cet index, en même temps que le segment de mémoire (heap) 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
    Essaie 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.

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

  [!REMARQUE]

  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 soumise à une ou plusieurs contraintes, il est conseillé d'exécuter DBCC CHECKCONSTRAINTS après une opération de 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 envisagez d'utiliser 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 égal à 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ù il est présent.

  Pour plus d'informations, consultez « Exécution de vérifications de cohérence logique sur des index » dans la section « Notes », plus loin dans cette rubrique.

• NO_INFOMSGS
  Supprime tous les messages d'information.

• TABLOCK
  Fait obtenir à DBCC CHECKTABLE un verrou de table partagé plutôt que 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 disponible dans cette dernière pendant l'exécution de DBCC CHECKTABLE.

• ESTIMATEONLY
  Affiche une estimation de la quantité d'espace dans 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 binaires (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.

  Par conséquent, l'utilisation de l'option PHYSICAL_ONLY étant susceptible de réduire considérablement l'exécution de DBCC CHECKTABLE sur des tables volumineuses, elle est recommandée pour une utilisation fréquente sur des systèmes de production. Nous vous recommandons toutefois 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. L'option PHYSICAL_ONLY implique toujours NO_INFOMSGS et n'est autorisée avec aucune des options de réparation.

  [!REMARQUE]

  La spécification de PHYSICAL_ONLY fait que DBCC CHECKTABLE ignorera toutes les vérifications des données FILESTREAM.

• DATA_PURITY
  Génère la vérification de la table par DBCC CHECKTABLE pour les valeurs de colonnes qui ne sont pas valides ou hors limite. Par exemple, DBCC CHECKTABLE détecte des 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 également des colonnes à valeur decimal ou numérique approximative avec des valeurs d'échelle ou de précision qui ne sont pas valides.

  Pour les bases de données créées dans SQL Server 2005 ou version ultérieure, 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, vous pouvez faire appel à DBCC CHECKTABLE WITH DATA_PURITY pour détecter et corriger les erreurs sur une table spécifique ; cependant, les vérifications sur la base colonne-valeur sur la table ne sont pas activées par défaut tant la commande DBCC CHECKDB WITH DATA_PURITY n'est pas exécutée sans erreur sur cette base de données. Ensuite, les commandes DBCC CHECKDB et DBCC CHECKTABLE vérifient l'intégrité sur la base colonne-valeur par défaut.

  Les erreurs de validation signalées par cette option ne peuvent pas être corrigées à l'aide des 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 Microsoft relatif au Dépannage de l'erreur DBCC 2570 dans SQL Server 2005 (page éventuellement en anglais)

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

Notes

[!REMARQUE]

Pour exécuter DBCC CHECKTABLE sur chaque table de la base de données, vous devez utiliser 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.

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 CHECKTABLE 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és 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 l'option NOINDEX est également spécifiée, 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 CHECKTABLE 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.

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

L'instruction DBCC CHECKTABLE utilise un instantané de base de données interne pour fournir la cohérence transactionnelle dont elle a besoin pour effectuer ces vérifications. Pour plus d'informations, consultez Afficher la taille du fichier partiellement alloué d'un instantané de base de données (Transact-SQL) et la section « Utilisation de l'instantané de base de données interne de DBCC » dans DBCC (Transact-SQL).

S'il est impossible de créer un instantané, ou si TABLOCK est spécifié, la commande DBCC CHECKTABLE acquiert un verrou de table partagé pour obtenir la cohérence nécessaire.

[!REMARQUE]

Si l'instruction DBCC CHECKTABLE est réexécutée sur tempdb, elle doit acquérir un verrou de table partagé. 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.

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 BLOB (binary large objects) varbinary(max) dans le système de fichiers. Lorsque 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 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 CHECKTABLE 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 CHECKTABLE peut réparer l'altération si vous spécifiez l'option REPAIR_ALLOW_DATA_LOSS. Pour réparer l'altération FILESTREAM, DBCC supprimera toutes les lignes de la table auxquelles il manque des données du système de fichiers et supprimera tous les répertoires et les fichiers qui ne sont pas mappés à une ligne, à une colonne ni à une valeur de colonne de la table.

Vérification des objets en parallèle

DBCC CHECKTABLE effectue par défaut une vérification parallèle des objets. Le degré de parallélisme est défini automatiquement 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 Degré maximal de parallélisme.

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

[!REMARQUE]

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.

Présentation des messages d'erreur de DBCC

Une fois la commande DBCC CHECKTABLE 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.

Création de rapports d'erreurs

Un fichier minidump (SQLDUMPnnnn.txt) est créé dans le répertoire LOG de SQL Server chaque fois que DBCC CHECKTABLE détecte une erreur d'altération. Lorsque les fonctions de collecte des données d'utilisation des fonctionnalités et de rapport d'erreurs 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\Administrateurs et du groupe de l'administrateur local. La commande DBCC n'échoue pas si le processus de collecte des données échoue.

Résolution des erreurs

Si DBCC CHECKTABLE signale des erreurs, il est recommandé de restaurer la base de données à partir de la sauvegarde plutôt que d'exécuter REPAIR avec l'une des options REPAIR. 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 à l'aide de 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

L'instruction 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 posséder 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

A.Vérification d'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 AdventureWorks .

USE AdventureWorks2012;
GO
DBCC CHECKTABLE ("HumanResources.Employee");
GO

B.Exécution d'une vérification à faible charge d'une table

L'exemple suivant effectue une vérification à faible charge de la table Employee dans la base de données AdventureWorks.

USE AdventureWorks2012;
GO
DBCC CHECKTABLE ("HumanResources.Employee") WITH PHYSICAL_ONLY;
GO

C.Vérification d'un index spécifique

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

USE AdventureWorks2012;
GO
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);

Voir aussi

Référence

DBCC (Transact-SQL)

DBCC CHECKDB (Transact-SQL)