DBCC CHECKFILEGROUP (Transact-SQL)

Mis à jour : 17 novembre 2008

Vérifie l'allocation et l'intégrité de la structure de toutes les tables et vues indexées dans le groupe de fichiers spécifié de la base de données active.

Conventions de syntaxe Transact-SQL

Syntaxe

DBCC CHECKFILEGROUP 
[
    [ ( { filegroup | filegroup_id | 0 } 
        [ , NOINDEX ] 
    ) ]
    [ WITH 
        { 
            [ ALL_ERRORMSGS | NO_INFOMSGS ] 
            [ , TABLOCK ] 
            [ , ESTIMATEONLY ]
            [ , PHYSICAL_ONLY ]  
        } 
    ]
]

Arguments

• filegroup_name
  Nom du groupe de fichiers, dans la base de données active, pour lequel l'allocation de table et l'intégrité de la structure doivent être vérifiées. Si vous ne définissez pas cet argument ou que vous lui attribuez la valeur 0, le groupe de fichiers primaire est utilisé par défaut. Les noms de groupe de fichier doivent suivre les règles applicables aux identificateurs.

• filegroup_id
  Numéro d'identification (ID) du groupe de fichiers, dans la base de données active, pour lequel l'allocation de table et l'intégrité de la structure sont vérifiées.

• NONINDEX
  Indique qu'il ne faut pas effectuer de vérifications intensives des index non-cluster pour les tables utilisateur. Cela diminue la durée d'exécution globale. L'argument NOINDEX n'affecte pas les tables système car DBCC CHECKFILEGROUP vérifie toujours tous les index des tables système.

• ALL_ERRORMSGS
  Affiche un nombre illimité d'erreurs par objet. 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
  Indique à DBCC CHECKFILEGROUP d'obtenir des verrous au lieu d'utiliser une capture instantanée de base de données interne.

• ESTIMATE ONLY
  Affiche une estimation de la quantité d'espace tempdb requise pour exécuter DBCC CHECKFILEGROUP 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 une vérification à faible charge de la cohérence physique du groupe de fichiers, cette vérification peut également détecter des pages endommagées et des erreurs matérielles courantes susceptibles de compromettre les données. Une exécution complète de CHECKFILEGROUP 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.

  Par conséquent, l'utilisation de l'option PHYSICAL_ONLY étant susceptible de réduire considérablement l'exécution de DBCC CHECKFILEGROUP sur des groupes de fichiers volumineux, 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 CHECKFILEGROUP. 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 pas autorisé avec une option de réparation quelle qu'elle soit.

  Remarque   La spécification de PHYSICAL_ONLY permet à DBCC CHECKFILEGROUP d'ignorer toutes les vérifications des données FILESTREAM.

Jeux de résultats

DBCC CHECKFILEGROUP retourne le jeu de résultats suivant (les valeurs peuvent varier) :

• sauf lorsque ESTIMATEONLY ou NO_INFOMSGS est spécifié ;
• pour la base de données active, si aucune base de données n'est spécifiée, que des options soient ou non définies (sauf NOINDEX).

DBCC results for 'master'.
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 2340 rows in 16 pages for object 'spt_values'.
DBCC results for 'MSreplication_options'.
There are 2 rows in 1 pages for object 'MSreplication_options'.
CHECKFILEGROUP found 0 allocation errors and 0 consistency errors in database 'master'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Si NO_INFOMSGS est spécifié, DBCC CHECKFILEGROUP retourne le résultat suivant :

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Si ESTIMATEONLY est spécifié, DBCC CHECKFILEGROUP retourne le résultat suivant (les valeurs peuvent varier) :

Estimated TEMPDB space needed for CHECKALLOC (KB) 
------------------------------------------------- 
15

(1 row(s) affected)

Estimated TEMPDB space needed for CHECKTABLES (KB) 
-------------------------------------------------- 
207

(1 row(s) affected)

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Notes

DBCC CHECKFILEGROUP et DBCC CHECKDB sont des commandes DBCC similaires. La principale différence réside dans le fait que la commande DBCC CHECKFILEGROUP est limitée au groupe de fichiers unique spécifié et aux tables requises.

DBCC CHECKFILEGROUP exécute les commandes suivantes :

• DBCC CHECKALLOC du groupe de fichiers ;
• DBCC CHECKTABLE de chaque table et vue indexée dans le groupe de fichiers.

L'exécution de DBCC CHECKALLOC ou DBCC CHECKTABLE indépendamment de DBCC CHECKFILEGROUP n'est pas requise.

Capture instantanée de base de données interne

DBCC CHECKFILEGROUP utilise une capture instantanée de base de données interne pour fournir la cohérence transactionnelle nécessaire à la réalisation de ces vérifications. Pour plus d'informations, consultez Tailles des fichiers fragmentés dans les captures instantanées de bases de données et la section "Utilisation de la capture instantanée de base de données interne de DBCC" de DBCC (Transact-SQL).

Si aucune capture instantanée ne peut être créée ou que l'option TABLOCK est spécifiée, DBCC CHECKFILEGROUP acquiert des verrous pour obtenir la cohérence nécessaire. Dans ce cas, un verrou de base de données exclusif est requis pour réaliser les vérifications d'allocation, tandis que des verrous de table partagés sont nécessaires pour effectuer des vérifications de table. TABLOCK accélère l'exécution de DBCC CHECKFILEGROUP sur une base de données dont la charge est importante, tout en diminuant la concurrence disponible dans cette dernière pendant l'exécution de DBCC CHECKFILEGROUP.

Remarque :

Dans SQL Server 2005, l'exécution de DBCC CHECKFILEGROUP sur tempdb n'effectue aucune vérification d'allocation et doit acquérir des verrous de table partagés pour réaliser les vérifications de table. En effet, pour des raisons liées aux performances, 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 CHECKFILEGROUP 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 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).

Index non-cluster sur des groupes de fichiers distincts

Si un index non-cluster dans le groupe de fichiers spécifié est associé à une table dans un autre groupe de fichiers, l'index n'est pas vérifié car la table de base n'est pas disponible pour être validée. Il s'agit d'une différence de comportement dans SQL Server 2005. Dans les versions antérieures de SQL Server, l'index non-cluster et la table de base de l'autre groupe de fichiers étaient vérifiés. Pour vérifier à la fois les index non-cluster et les tables de base, exécutez DBCC CHECKDB.

Si une table dans le groupe de fichiers spécifié possède un index non-cluster dans un autre groupe de fichiers, l'index non-cluster n'est pas vérifié pour les raisons suivantes :

• La structure de la table de base n'est pas dépendante de la structure d'un index non-cluster. Les index non-cluster n'ont pas à être analysés pour permettre la validation de la table de base.
• La commande DBCC CHECKFILEGROUP valide les objets uniquement dans le groupe de fichiers spécifié.

Un index cluster et une table ne peuvent pas se trouver dans des groupes de fichiers différents ; par conséquent, les considérations précédentes ne peuvent s'appliquer qu'aux index non-cluster.

Tables partitionnées sur des groupes de fichiers séparés

Dans les versions de SQL Server 2005 antérieures au Service Pack 2 (SP2), DBCC CHECKFILEGROUP vérifie une table partitionnée uniquement si la table complète est sur le groupe de fichiers spécifié. Si la table porte sur plusieurs groupes de fichiers, l'ensemble de celle-ci est ignoré. Dans le Service Pack 2, lorsqu'une table partitionnée existe sur plusieurs groupes de fichiers, DBCC CHECKFILEGROUP vérifie les ensembles de lignes de partition présents sur le groupe de fichiers spécifiés et ignore les ensembles de lignes dans les autres groupes de fichiers. Le message d'information 2594 indique les partitions qui n'ont pas été vérifiées. Les index non-cluster qui ne figurent pas sur le groupe de fichiers spécifiés ne sont pas vérifiés.

Présentation des messages d'erreur de DBCC

Une fois la commande DBCC CHECKFILEGROUP 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 mini-fichier de vidage (SQLDUMPnnnn.txt) est créé dans le répertoire LOG de SQL Server à chaque fois que DBCC CHECKFILEGROUP 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 CHECKFILEGROUP 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 des erreurs sont signalées par DBCC CHECKFILEGROUP, il est recommandé de restaurer la base de données à partir d'une sauvegarde de base de données. Les options de réparation ne peuvent pas être spécifiées à DBCC CHECKFILEGROUP.

Si aucune sauvegarde n'existe, l'exécution de DBCC CHECKDB avec une option de réparation spécifiée corrige les erreurs signalées. L'option de réparation à utiliser est spécifiée à la fin de la liste des erreurs signalées. 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.

Autorisations

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

Exemples

A. Vérification du groupe de fichiers PRIMARY dans la base de données AdventureWorks

L'exemple suivant vérifie le groupe de fichiers primaire de la base de données AdventureWorks.

USE AdventureWorks;
GO
DBCC CHECKFILEGROUP;
GO

B. Vérification du groupe de fichiers PRIMARY de la base de données AdventureWorks sans les index non-cluster

Cet exemple contrôle le groupe de fichiers primaire de la base de données AdventureWorks (à l'exception des index non-cluster) en spécifiant le numéro d'identification du groupe de fichiers primaire et NOINDEX.

USE AdventureWorks;
GO
DBCC CHECKFILEGROUP (1, NOINDEX);
GO

C. Vérification du groupe de fichiers PRIMARY avec des options

L'exemple suivant vérifie le groupe de fichiers primaire de la base de données master et spécifie l'option ESTIMATEONLY.

USE master;
GO
DBCC CHECKFILEGROUP (1)
WITH ESTIMATEONLY;

Voir aussi

Référence

DBCC (Transact-SQL)
FILEGROUP_ID (Transact-SQL)
sp_helpfile (Transact-SQL)
sp_helpfilegroup (Transact-SQL)
sys.sysfilegroups (Transact-SQL)
DBCC CHECKDB (Transact-SQL)
DBCC CHECKALLOC (Transact-SQL)
DBCC CHECKTABLE (Transact-SQL)

Autres ressources

Architecture de bases de données physiques

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 : Dans la section Remarques, ajout de la sous-section « Tables partitionnées sur des groupes de fichiers séparés ». Cette section décrit les nouvelles fonctionnalités de SP2.
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 : Ajout de l'exemple C. Contenu modifié : La syntaxe a été corrigée. Dans la section Remarques, des informations ont été ajoutées concernant les messages qui sont consignés dans le journal d'erreurs de SQL Server, de même que des descriptions des valeurs d'état. La section concernant les index non-cluster sur des groupes de fichiers distincts a été corrigée afin de refléter le comportement de SQL Server 2005.