DBCC CHECKTABLE (Transact-SQL)

  • Article

Mis à jour : 17 novembre 2008

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

Icône Lien de rubriqueConventions de syntaxe Transact-SQL

Syntaxe

DBCC CHECKTABLE 
(
        table_name | view_name
    [ , { NOINDEX | index_id }
     |, { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } 
    ] 
)
    [ WITH 
        { ALL_ERRORMSGS ]
          [ , 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 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 les petites réparations rapides, telles que la réparation des clés supplémentaires dans les index non-cluster, ainsi que les réparations qui nécessitent beaucoup de temps, telles que la reconstruction des index. Ces réparations peuvent être effectuées sans risque de perte de données.
    ms174338.note(fr-fr,SQL.90).gifRemarque :
    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 la commande DBCC CHECKDB sans option de réparation afin de déterminer le niveau de réparation à utiliser. Si vous devez utiliser le niveau REPAIR_ALLOW_DATA_LOSS, nous vous recommandons de sauvegarder la base de données avant d'exécuter DBCC CHECKDB avec cette option.
  • ALL_ERRORMSGS
    Affiche un nombre illimité d'erreurs. Dans SQL Server 2005 Service Pack 3 (SP3), tous les messages d'erreur s'affichent par défaut. La spécification ou non de cette option n'a aucun effet. Dans les versions antérieures de SQL Server, seuls les 200 premiers messages d'erreur de chaque objet s'affichent lorsque ALL_ERRORMSGS n'est pas spécifié.
  • NO_INFOMSGS
    Supprime tous les messages d'information.
  • TABLOCK
    Fait obtenir à DBCC CHECKTABLE un verrou de table partagé plutôt que d'utiliser une capture instantanée 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 l'accès concurrentiel disponible dans cette dernière 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 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. Dans SQL Server 2005, une exécution complète de DBCC CHECKTABLE peut prendre beaucoup plus de temps que dans les versions précédentes. 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.
    • Un grand nombre de nouvelles vérifications ont été introduites pour inclure les nouvelles fonctionnalités dans SQL Server 2005.

    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.

  • 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, 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 que 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 : Dépannage de l'erreur DBCC 2570 dans SQL Server 2005 (en anglais).

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

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.

Notes

DBCC CHECKTABLE effectue des vérifications de cohérence sur une table ou vue indexée unique et sur tous ses index non-cluster et XML, sauf si l'option NOINDEX est spécifiée. 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 de 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.

Capture instantanée de base de données interne

L'instruction DBCC CHECKTABLE utilise une capture instantanée de base de données interne pour fournir la cohérence transactionnelle dont elle a besoin pur effectuer ces vérifications. Pour plus d'informations, consultez Tailles des fichiers fragmentés dans les captures instantanées de bases de données, ainsi que la section relative à l'utilisation des captures instantanées de base de données interne (« DBCC Internal Database Snapshot Usage ») dans DBCC (Transact-SQL).

S'il est impossible de créer une capture instantanée, ou de spécifier TABLOCK, l'instruction DBCC CHECKTABLE acquiert un verrou de table partagée pour obtenir la cohérence nécessaire.

ms174338.note(fr-fr,SQL.90).gifRemarque :
Si l'instruction DBCC CHECKTABLE est réexécutée sur tempdb, elle doit acquérir un verrou de table partagée. Cela est dû au fait que, pour des raisons de performance, les captures instantanées 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 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 Option max degree of parallelism.

La vérification du parallélisme peut être désactivée à l'aide de l'indicateur de trace 2528. Pour plus d'informations, consultez Indicateurs de trace (Transact-SQL).

ms174338.note(fr-fr,SQL.90).gifRemarque :
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.

État 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

Dans SQL Server 2005 Service Pack 1 (SP1), un petit fichier de vidage (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. Pour plus d'informations, consultez Paramètres de rapports d'erreurs et d'utilisation.

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étionnaires de service (DACL). 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.

Autorisations

L'utilisateur doit posséder la table ou être membre du rôle de serveur fixe sysadmin, du rôle de base de données db_owner ou du rôle de base de données 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 AdventureWorks;
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 AdventureWorks;
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 AdventureWorks;
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)

Autres ressources

Architecture des tables et des index
Résolution des erreurs DBCC dans les vues indexées

Aide et Informations

Assistance sur SQL Server 2005

Historique des modifications

Version Historique

17 novembre 2008
Nouveau contenu :
  • Dans la définition de ALL_ERRORMSGS, description des nouvelles fonctionnalités du SP3.

12 décembre 2006
Nouveau contenu :
  • Ajout de l'option DATA_PURITY aux sections Syntaxe et Arguments.

14 avril 2006
Nouveau contenu :
  • Dans la section Remarques, ajout de la sous-section « Rapport d'erreurs ». Cette section décrit les nouvelles fonctionnalités du SP1.

5 décembre 2005
Nouveau contenu :
  • Une remarque concernant les types définis par l'utilisateur a été ajoutée.
Contenu modifié :
  • La définition de REPAIR_FAST a été corrigée. L'option n'effectue aucune action de réparation.
  • La syntaxe a été corrigée.
  • L'exemple C a été corrigé.