DBCC CHECKDB (Transact-SQL)
Mis à jour : 17 novembre 2008
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 dans la base de données.
- Valide les données Service Broker dans la base de données.
Cela signifie que l'exécution des commandes DBCC CHECKALLOC, DBCC CHECKTABLE ou DBCC CHECKCATALOG ne doit pas être distincte de celle de DBCC CHECKDB. Pour plus d'informations sur les vérifications réalisées par ces commandes, consultez les descriptions des commandes.
.gif "Icône Lien de rubrique")
Conventions de syntaxe Transact-SQL
Syntaxe
DBCC CHECKDB
[
[ ( database_name | database_id | 0
[ , NOINDEX
| , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
) ]
[ WITH
{
[ ALL_ERRORMSGS ]
[ , NO_INFOMSGS ]
[ , TABLOCK ]
[ , ESTIMATEONLY ]
[ , { PHYSICAL_ONLY | DATA_PURITY } ]
}
]
]
Arguments
- database_name | database_id | 0
Nom ou ID de la base de données pour laquelle vous exécutez des vérifications d'intégrité. En l'absence de spécification, ou si 0 est spécifié, la base de données actuelle est utilisée. Les noms de base de données doivent suivre les règles applicables aux identificateurs.
- 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. NOINDEX n'affecte pas les tables système car les vérifications d'intégrité sont toujours effectuées sur leurs index.
REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Spécifie que DBCC CHECKDB répare les erreurs trouvées. La base de données spécifiée ** doit être en mode mono-utilisateur pour pouvoir 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 des pertes de données.
- REPAIR_FAST
Conserve la syntaxe pour une compatibilité descendante uniquement. 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.
.gif "ms176064.note(fr-fr,SQL.90).gif")
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 la commande DBCC CHECKDB 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 la commande DBCC CHECKDB avec cette option. - REPAIR_ALLOW_DATA_LOSS
ALL_ERRORMSGS
Affiche toutes les erreurs signalées 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é. Les messages d'erreur sont triés par ID d'objet, à l'exception des messages générés à partir de la base de données tempdb.Dans SQL Server Management Studio, le nombre maximal de messages d'erreur retournés s'élève à 1000. Lorsque vous utilisez Management Studio, il peut être nécessaire d'exécuter DBCC CHECKDB plusieurs fois afin d'obtenir une liste complète des erreurs si ALL_ERRORMSGS est spécifié. Nous vous conseillons d'exécuter la commande DBCC en utilisant l'utilitaire sqlcmd ou en planifiant un travail de l'Agent SQL Server pour exécuter la commande et envoyer la sortie vers un fichier. En utilisant l'une ou l'autre de ces méthodes, il vous suffit d'exécuter la commande une seule fois pour obtenir tous les messages d'erreur.
- NO_INFOMSGS
N'affiche plus les messages d'information.
TABLOCK
Génère des verrouillages par DBCC CHECKDB au lieu d'utiliser une capture instantanée de base de données interne. Cette opération comprend un verrou exclusif sur la base de données. TABLOCK accélère l'exécution de DBCC CHECKDB 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 CHECKDB. Pour plus d'informations sur les verrous, consultez Modes de verrouillage.TABLOCK limite les vérifications effectuées ; DBCC CHECKCATALOG n'est pas exécutée sur la base de données et les données Service Broker ne sont pas validées.
- ESTIMATEONLY
Affiche une estimation de la quantité d'espace tempdb qui est requise pour exécuter DBCC CHECKDB avec toutes les autres options spécifiées. La vérification de la base de données actuelle n'est pas effectuée.
- PHYSICAL_ONLY
Limite la nature de la vérification à l'intégrité de la structure physique sur la page et les en-têtes d'enregistrement, à l'intégrité de la structure physique des arborescences binaires et à l'intégrité de la cohérence d'allocation de la base de données. Cette vérification, qui vise à contrôler la cohérence physique de la base de données, inclut par ailleurs la détection des pages endommagées, des échecs de somme de contrôle et des erreurs matérielles courantes, susceptibles de compromettre les données utilisateur. PHYSICAL_ONLY implique toujours NO_INFOMSGS et n'est pas autorisé avec une option de réparation quelle qu'elle soit.
DATA_PURITY
Génère la vérification de la base de données par DBCC CHECKDB pour les valeurs de colonnes qui ne sont pas valides ou hors limite. Par exemple, DBCC CHECKDB 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, les vérifications sur la base colonne-valeur 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, DBCC CHECKDB vérifie l'intégrité sur la base colonne-valeur par défaut. Pour plus d'informations sur les incidences sur CHECKDB suite à une mise à niveau de la base de données à partir de versions antérieures de SQL Server, consultez la section Notes, plus loin dans cette rubrique.
Si PHYSICAL_ONLY est spécifié, l'intégrité des colonnes n'est pas vérifiée.
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).
Jeux de résultats
DBCC CHECKDB retourne le jeu de résultats suivant. Les valeurs risquent de varier, à moins que les options ESTIMATEONLY, PHYSICAL_ONLY ou NO_INFOMSGS soient 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 retourne le jeu de résultats suivant (message) si NO_INFOMSGS est spécifié :
The command(s) completed successfully.
DBCC CHECKDB retourne le jeu de résultats suivant si 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 retourne le jeu de résultats suivant si 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.
Notes
Dans les versions antérieures de SQL Server, les valeurs pour le nombre de lignes par table et par index ainsi que le nombre de page peuvent être incorrectes. Dans certains cas, une ou plusieurs valeurs risquent de devenir négatives. Dans SQL Server 2005, ces valeurs sont toujours gérées correctement. Par conséquent, les bases de données créées dans SQL Server 2005 ne doivent jamais présenter de décomptes incorrects ; toutefois, les bases de données mises à niveau vers SQL Server 2005 le peuvent. Il ne s'agit pas d'une corruption des données stockées dans la base de données. DBCC CHECKDB a été améliorée pour détecter les valeurs négatives de ces nombres. Lors d'une telle détection, la sortie de DBCC CHECKDB contient un avertissement et une recommandation relatifs à l'exécution de DBCC UPDATEUSAGE afin de corriger le problème. Bien qu'il semble que la mise à niveau de la base de données vers SQL Server 2005 soit à l'origine du problème, les décomptes incorrects existaient déjà avant la procédure de mise à niveau.
DBCC CHECKDB n'examine pas les index désactivés. Pour plus d'informations sur les index désactivés, consultez Désactivation d'index.
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. En l'absence de sérialisation cohérente de type défini par l'utilisateur ordonné par octet, l'erreur 2537 est générée à l'exécution de DBCC CHECKDB. Pour plus d'informations, consultez User-Defined Type Requirements.
Étant donné que la base de données des ressources est modifiable uniquement en mode mono-utilisateur, vous ne pouvez pas y exécuter la commande DBCC CHECKDB directement. Cependant, lors de l'exécution de DBCC CHECKDB sur la base de données master, une deuxième commande CHECKDB est également exécutée en interne sur la base de données Ressources. Cela signifie que DBCC CHECKDB peut retourner des résultats supplémentaires. La commande retourne des jeux de résultats supplémentaires lorsqu'aucune option n'est définie ou lorsque l'option PHYSICAL_ONLY ou ESTIMATEONLY est définie.
Dans les versions de SQL Server 2005 antérieures au Service Pack 2, l'exécution de la commande DBCC CHECKDB efface la mémoire cache des plans pour l'instance de SQL Server. Cette opération entraîne la recompilation de tous les plans d'exécution ultérieurs et peut entraîner une baisse temporaire et brutale des performances des requêtes. Dans Service Pack 2, l'exécution de la commande DBCC CHECKDB n'efface pas la mémoire cache des plans.
Capture instantanée de base de données interne
DBCC CHECKDB utilise une capture instantanée de base de données interne pour la cohérence transactionnelle nécessaire à la réalisation de ces vérifications. Ceci évite les problèmes de blocage et d'accès simultané lors de l'exécution de ces commandes. 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 vous ne pouvez créer aucune capture instantanée ou si TABLOCK est spécifié, la commande DBCC CHECKDB acquiert des verrous pour obtenir la cohérence requise. 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.
DBCC CHECKDB échoue lorsqu'il est exécuté sur une base de données master s'il n'est pas possible de créer de capture instantanée interne de la base de données.
L'exécution de la commande DBCC CHECKDB sur tempdb ne procède à aucune allocation et ne vérifie aucun catalogue. Elle doit acquérir des verrous de table partagés pour vérifier ces tables. En effet, pour des raisons liées aux performances, les captures instantanées de base de données ne sont pas disponibles sur tempdb. Ceci signifie qu'il n'est pas possible d'obtenir la cohérence transactionnelle nécessaire.
Meilleures pratiques
Dans SQL Server 2005, l'exécution de DBCC CHECKDB sans option 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 introduites sont plus complètes.
- Certaines structures sous-jacentes sont plus complexes à vérifier.
- des vérifications supplémentaires ont été introduites pour inclure les nouvelles fonctionnalités de SQL Server 2005.
Par conséquent, l'option PHYSICAL_ONLY est recommandée pour une utilisation fréquente sur des systèmes de production. L'utilisation de PHYSICAL_ONLY permet de raccourcir nettement le temps d'exécution de DBCC CHECKDB sur des bases de données volumineuses. Nous vous conseillons également d'exécuter régulièrement DBCC CHECKDB sans option. La fréquence à laquelle vous devez effectuer ces exécutions dépend de chaque activité et de son environnement de production.
Vérification des objets en parallèle
DBCC CHECKDB 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).
Présentation des messages d'erreur de DBCC
Une fois la commande DBCC CHECKDB 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 arrêté 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 arrêté 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, un fichier de vidage (SQLDUMPnnnn.txt) est créé dans le répertoire LOG de SQL Server lorsque DBCC CHECKDB 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 CHECKDB ainsi que des éléments supplémentaires de diagnostic. 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 des données échoue.
Résolution des erreurs
Si des erreurs sont signalées par DBCC CHECKDB, nous vous recommandons de restaurer la base de données à partir de sa sauvegarde plutôt que d'exécuter REPAIR avec une des options correspondantes. En cas d'absence de sauvegarde, la réparation corrige les erreurs détectées. Cette option de réparation est spécifiée à la fin de la liste des erreurs signalées. Néanmoins, la correction des erreurs à l'aide de l'option REPAIR_ALLOW_DATA_LOSS risque de nécessiter que certaines pages, et par conséquent certaines données, soient supprimées.
Dans de telles circonstances, des valeurs risquent d'être entrées dans la base de données, alors qu'elles ne sont pas valides ou hors limite en fonction du type de données de la colonne. Dans SQL Server 2000, DBCC CHECKDB ne vérifie pas l'intégrité ou la plage sur ces valeurs de colonne. Cependant, dans SQL Server 2005, DBCC CHECKDB peut détecter des valeurs de la colonne non valides pour tous les types de données de cette colonne. Ainsi, l'exécution de DBCC CHECKDB avec l'option DATA_PURITY sur des bases de données mises à niveau à partir de versions antérieures de SQL Server risque de révéler des erreurs pré-existantes de valeur-colonne. Étant donné que SQL Server 2005 ne peut pas effectuer de réparation automatique de ces erreurs, vous devez mettre à jour la valeur de la colonne manuellement. Si CHECKDB détecte une telle erreur, CHECKDB retourne un avertissement, le numéro d'erreur 2570 et des informations pour identifier la ligne adéquate et corriger l'erreur manuellement.
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 restaurées, la base de données contiendra encore des erreurs et il faudra donc la restaurer à partir d'une sauvegarde. Une fois les réparations effectuées, sauvegardez la base de données.
Résolution des erreurs en mode urgence dans la base de données
Lorsqu'une base de données a été placée en mode urgence à l'aide de l'instruction ALTER DATABASE et que l'option REPAIR_ALLOW_DATA_LOSS est spécifiée, DBCC CHECKDB peut réaliser certaines réparations particulières dans la base de données. Ces réparations peuvent éventuellement aboutir à la remise en ligne dans un état physiquement cohérent de bases de données irrécupérables en temps normal. Vous devez utiliser ces réparations en dernier recours et uniquement lorsque vous ne pouvez pas restaurer la base de données à partir d'une sauvegarde. Si la base de données est placée en mode urgence, elle est marquée comme READ_ONLY, l'enregistrement est désactivé et l'accès est limité aux membres du rôle de serveur fixe sysadmin.
| Remarque : |
|---|
| Vous ne pouvez pas exécuter la commande DBCC CHECKDB en mode urgence dans une transaction utilisateur puis restaurer celle-ci au terme de l'exécution. |
Si la base de données est placée en mode urgence et que DBCC CHECKDB est exécutée avec la clause REPAIR_ALLOW_DATA_LOSS, les actions suivantes se produisent :
- DBCC CHECKDB utilise les pages marquées comme inaccessibles en raison d'erreurs d'E/S ou de somme de contrôle, comme si aucune erreur ne s'était produite. Cette procédure améliore les chances de récupérer les données de la base de données.
- DBCC CHECKDB tente de récupérer la base de données au moyen de techniques classiques de récupération basées sur les fichiers journaux.
- Si, en raison de la corruption du journal des transactions, la récupération de la base de données échoue, le journal de transactions est reconstruit. La reconstruction du journal des transactions peut nuire à la cohérence transactionnelle.
Si la commande DBCC CHECKDB réussit, la base de données est physiquement cohérente et son état prend la valeur ONLINE. Toutefois, la base de données peut contenir une ou plusieurs incohérences transactionnelles. Il est recommandé d'exécuter DBCC CHECKCONSTRAINTS afin d'identifier tout défaut de logique métier et de sauvegarder la base de données immédiatement.
Si la commande DBCC CHECKDB échoue, la base de données ne peut pas être réparée.
Exécution de DBCC CHECKDB avec REPAIR_ALLOW_DATA_LOSS dans des bases de données répliquées
L'exécution de la commande DBCC CHECKDB avec l'option REPAIR_ALLOW_DATA_LOSS peut avoir des conséquences sur les bases de données utilisateur (bases de données de publication et d'abonnement) ainsi que sur la base de données de distribution utilisée par la réplication. Les bases de données de publication et d'abonnement incluent des tables publiées et des tables de métadonnées de réplication. Sachez que les problèmes suivants peuvent se poser dans ces bases de données :
- Tables publiées. Il est possible que les actions effectuées par le processus CHECKDB pour réparer les données utilisateur corrompues ne soient pas répliquées :
- La réplication de fusion utilise des déclencheurs pour assurer le suivi des modifications apportées aux tables publiées. Si des lignes sont insérées, mises à jour ou supprimées par le processus CHECKDB, les déclencheurs ne sont pas activés : la modification n'est donc pas répliquée.
- La réplication transactionnelle utilise le journal des transactions pour assurer le suivi des modifications apportées aux tables publiées. L'Agent de lecture du journal place ensuite ces modifications dans la base de données de distribution. Certaines réparations de DBCC, bien qu'elles soient consignées dans le journal, ne peuvent pas être répliquées par l'Agent de lecture du journal. Par exemple, si une page de données est désallouée par le processus CHECKDB, l'Agent de lecture du journal ne la convertit pas en instruction DELETE ; par conséquent, la modification n'est pas répliquée.
- Tables de métadonnées de réplication. Pour les actions effectuées par le processus CHECKDB afin de réparer les tables de métadonnées de réplication corrompues, la réplication doit être supprimée puis reconfigurée.
Si vous devez exécuter la commande DBCC CHECKDB avec l'option REPAIR_ALLOW_DATA_LOSS sur une base de données utilisateur ou de distribution :
- Suspendez le système : arrêtez l'activité sur la base de données et toutes les autres bases de données appartenant à la topologie de réplication, puis tentez de synchroniser tous les nœuds. Pour plus d'informations, consultez How to: Quiesce a Replication Topology (Replication Transact-SQL Programming).
- Exécutez DBCC CHECKDB.
- Si le rapport DBCC CHECKDB inclut des réparations pour des tables de la base de données de distribution ou des tables 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 Suppression de la réplication.
- Si le rapport DBCC CHECKDB inclut des réparations pour des tables répliquées, procédez à une validation des données pour déterminer s'il existe des différences entre les données de la base de données de publication et celles de la base de données d'abonnement. Pour plus d'informations, consultez Les données du serveur de publication et de l'Abonné ne concordent pas.
Autorisations
Requiert l'appartenance au rôle serveur fixe sysadmin ou au rôle de base de données fixe db_owner.
Exemples
A. Vérification de la base de données actuelle et de celle d'AdventureWorks
L'exemple qui suit exécute DBCC CHECKDB pour la base de données actuelle et pour la base de données AdventureWorks.
-- Check the current database.
DBCC CHECKDB;
GO
-- Check the AdventureWorks database without nonclustered indexes.
DBCC CHECKDB (AdventureWorks, NOINDEX);
GO
B. Vérification de la base de données actuelle et 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
Référence
DBCC (Transact-SQL)
sp_helpdb (Transact-SQL)
Tables système (Transact-SQL)
Autres ressources
Architecture de bases de données physiques
Tailles des fichiers fragmentés dans les captures instantanées de bases de données
Résolution des erreurs DBCC dans les vues indexées
Optimisation des performances DBCC CHECKDB
Aide et Informations
Assistance sur SQL Server 2005
Historique des modifications
| Version | Historique |
|---|---|
17 novembre 2008 |
|
12 décembre 2006 |
|
17 juillet 2006 |
|
14 avril 2006 |
|
5 décembre 2005 |
|