DBCC CHECKALLOC (Transact-SQL)
Mis à jour : 17 novembre 2008
Vérifie la cohérence des structures d'allocation de l'espace disque pour une base de données spécifiée.
Conventions de syntaxe Transact-SQL
Syntaxe
DBCC CHECKALLOC
[
( database_name | database_id | 0
[ , NOINDEX
| , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
)
[ WITH
{
[ ALL_ERRORMSGS ]
[ , NO_INFOMSGS ]
[ , TABLOCK ]
[ , ESTIMATEONLY ]
}
]
]
Arguments
database_name | database_id | 0
Nom ou ID de la base de données sur laquelle l'allocation et l'utilisation des pages sont vérifiées. 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 se conformer aux règles en vigueur pour les identificateurs.
NOINDEX
Indique que la vérification ne doit pas tenir compte des index non-cluster dans les tables utilisateurs.Remarque : NOINDEX est conservé seulement pour la compatibilité descendante, et n'affecte pas DBCC CHECKALLOC.
REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Indique que DBCC CHECKALLOC doit réparer les erreurs trouvées. database_name doit être en mode mono-utilisateur.- REPAIR_ALLOW_DATA_LOSS
Tente de réparer toutes les erreurs trouvées. Ces réparations peuvent entraîner des pertes de données. REPAIR_ALLOW_DATA_LOSS est la seule option qui permet de réparer les erreurs d'allocation.
- REPAIR_FAST
La syntaxe n'est conservée que pour la compatibilité descendante. Aucune réparation n'est effectuée.
- REPAIR_REBUILD
Non applicable.
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
- WITH
Autorise la spécification d'options.
- ALL_ERRORMSGS
Affiche tous les messages d'erreur. 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, ainsi que le rapport sur l'espace utilisé.
- TABLOCK
Permet à la commande DBCC d'obtenir un verrou de base de données exclusif.
- ESTIMATE ONLY
Affiche une estimation de la quantité d'espace tempdb requise pour exécuter DBCC CHECKALLOC lorsque toutes les autres options sont spécifiées.
Jeux de résultats
Les tableaux qui suivent décrivent les informations retournées par DBCC CHECKALLOC.
Élément | Description |
---|---|
FirstIAM |
À usage interne uniquement |
Root |
À usage interne uniquement |
Dpages |
Nombre de pages de données. |
Pages utilisées (Pages used) |
Pages allouées. |
Extensions dédiées (Dedicated extents) |
Extensions allouées à l'objet En cas d'utilisation de pages d'allocation mixtes, certaines pages allouées peuvent n'avoir aucune extension. |
DBCC CHECKALLOC fournit aussi un résumé de l'allocation pour chaque index et partition de chaque fichier. Ce résumé décrit la distribution des données.
Élément | Description |
---|---|
Pages réservées (Reserved pages) |
Pages allouées à l'index et pages inutilisées dans les extensions allouées. |
Pages utilisées (Used pages) |
Pages allouées et utilisées par l'index. |
ID de partition (Partition ID) |
À usage interne uniquement |
ID d'unité d'allocation |
À usage interne uniquement |
Données dans la ligne (In-row data) |
Les pages contiennent des données de segment de mémoire ou d'index. |
Données LOB (LOB data) |
Les pages contiennent des données de type varchar(max), nvarchar(max), varbinary(max), text, ntext, xml et image. |
Données de dépassement de capacité de ligne |
Les pages contiennent des données de colonne de longueur variable qui ont été envoyées hors ligne. |
DBCC CHECKALLOC retourne le jeu de résultats suivant (les valeurs peuvent varier), sauf lorsque ESTIMATEONLY ou NO_INFOMSGS est spécifié.
DBCC results for 'master'.
************************************************************* Table sysobjects Object ID 1. Index ID 1 FirstIAM (1:11) Root (1:12) Dpages 22. Index ID 1. 24 pages used in 5 dedicated extents. Index ID 2 FirstIAM (1:1368) Root (1:1362) Dpages 10. Index ID 2. 12 pages used in 2 dedicated extents. Index ID 3 FirstIAM (1:1392) Root (1:1408) Dpages 4. Index ID 3. 6 pages used in 0 dedicated extents. Total number of extents is 7. ************************************************************* '...' ************************************************************* Table spt_server_info Object ID 1938105945. Index ID 1 FirstIAM (1:520) Root (1:508) Dpages 1. Index ID 1. 3 pages used in 0 dedicated extents. Total number of extents is 0. ************************************************************* Processed 52 entries in sysindexes for database ID 1. File 1. Number of extents = 210, used pages = 1126, reserved pages = 1280. File 1 (number of mixed extents = 73, mixed pages = 184). Object ID 1, Index ID 0, data extents 5, pages 24, mixed extent pages 9. '...' Object ID 1938105945, Index ID 0, data extents 0, pages 3, mixed extent pages 3. Total number of extents = 210, used pages = 1126, reserved pages = 1280 in this database. (number of mixed extents = 73, mixed pages = 184) in this database. CHECKALLOC found 0 allocation errors and 0 consistency errors in database 'master'. DBCC results for 'master'. ************************************************************* Table sys.sysrowsetcolumns Object ID 4. Index ID 1, partition ID 262144, alloc unit ID 262144 (type In-row data). FirstIAM (1:98). Root (1:94). Dpages 7. Index ID 1, partition ID 262144, alloc unit ID 262144 (type In-row data). 9 pages used in 1 dedicated extents. Index ID 1, partition ID 262144, alloc unit ID 262398 (type Row-overflow data). FirstIAM (0:0). Root (0:0). Dpages 0. Index ID 1, partition ID 262144, alloc unit ID 262398 (type Row-overflow data). 0 pages used in 0 dedicated extents. Total number of extents is 1. ... ************************************************************* Processed 201 entries in system catalog for database ID 1. File 1. Number of extents = 44, used pages = 300, reserved pages = 345. File 1 (number of mixed extents = 29, mixed pages = 225). Object ID 4, index ID 1, partition ID 262144, alloc unit ID 262144 (type In-row data), data extents 1, pages 9, mixed extent pages 8. Object ID 5, index ID 1, partition ID 327680, alloc unit ID 327680 (type In-row data), data extents 0, pages 2, mixed extent pages 2. Object ID 7, index ID 1, partition ID 458752, alloc unit ID 458752 (type In-row data), data extents 0, pages 5, mixed extent pages 5. Object ID 8, index ID 0, partition ID 524288, alloc unit ID 524288 (type In-row data), data extents 0, pages 2, mixed extent pages 2. Object ID 13, index ID 1, partition ID 851968, alloc unit ID 851968 (type In-row data), data extents 1, pages 9, mixed extent pages 8. Object ID 15, index ID 1, partition ID 983040, alloc unit ID 983040 (type In-row data), data extents 0, pages 2, mixed extent pages 2. Object ID 26, index ID 1, partition ID 281474978414592, alloc unit ID 1703937 (type In-row data), data extents 0, pages 3, mixed extent pages 3. Object ID 27, index ID 1, partition ID 281474978480128, alloc unit ID 1769473 (type In-row data), data extents 0, pages 3, mixed extent pages 3. Object ID 27, index ID 2, partition ID 562949955190784, alloc unit ID 1769474 (type In-row data), index extents 0, pages 3, mixed extent pages 3. ... Object ID 1179151246, index ID 1, partition ID 72057594038845440, alloc unit ID 13435136 (type In-row data), data extents 2, pages 18, mixed extent pages 8. Object ID 1179151246, index ID 2, partition ID 72057594038910976, alloc unit ID 13566208 (type In-row data), index extents 1, pages 16, mixed extent pages 8. Object ID 1911677858, index ID 0, partition ID 72057594039631872, alloc unit ID 15073536 (type In-row data), data extents 0, pages 2, mixed extent pages 2. Total number of extents = 41, used pages = 289, reserved pages = 323 in this database. (number of mixed extents = 27, mixed pages = 211) in this database. CHECKALLOC found 0 allocation errors and 0 consistency errors in database 'master'. DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Lorsque ESTIMATEONLY est spécifié, DBCC CHECKALLOC retourne le jeu de résultats suivant.
Estimated TEMPDB space needed for CHECKALLOC (KB)
-------------------------------------------------
34
(1 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Notes
DBCC CHECKALLOC vérifie l'allocation de toutes les pages de la base de données, quel que soit le type de page ou le type d'objet auquel elles appartiennent. Il valide également les différentes structures internes qui sont utilisées pour garder la trace de ces pages et des relations entre elles.
Si NO_INFOMSGS n'est pas spécifié, DBCC CHECKALLOC collecte les informations d'utilisation de l'espace pour tous les objets de la base de données. Ces informations sont ensuite imprimées avec les erreurs détectées.
Remarque : |
---|
La fonctionnalité DBCC CHECKALLOC est incluse dans DBCC CHECKDB et DBCC CHECKFILEGROUP. Il n'est donc pas nécessaire d'exécuter DBCC CHECKALLOC indépendamment de ces instructions. |
Capture instantanée de base de données interne
DBCC CHECKALLOC utilise une capture instantanée interne de la base de données pour assurer la cohérence transactionnelle nécessaire pour l'exécution de ces vérifications. S'il n'est pas possible de créer une capture instantanée, ou si TABLOCK est spécifié, DBCC CHECKALLOC tente d'acquérir un verrou exclusif sur la base de données pour obtenir la cohérence nécessaire. Pour plus d'informations sur les verrous, consultez Modes de verrouillage.
Remarque : |
---|
Dans SQL Server 2005, l'exécution de DBCC CHECKALLOC sur tempdb n'effectue aucune vérification. Ceci parce que, pour des raisons de 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. Arrêtez et démarrez le service MSSQLSERVER pour résoudre les problèmes d'allocation de tempdb. Cette action supprime la base de données tempdb puis la recrée. |
Présentation des messages d'erreur de DBCC
Une fois la commande DBCC CHECKALLOC 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 CHECKALLOC 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 CHECKALLOC 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\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 DBCC CHECKALLOC signale des erreurs, nous vous recommandons de restaurer la base de données à partir de la sauvegarde de la base de données plutôt que d'exécuter une réparation. S'il n'existe pas de sauvegarde, l'exécution d'une réparation peut corriger les erreurs signalées ; cependant, la correction de ces erreurs risque de nécessiter la suppression de plusieurs pages, et donc de données.
Une réparation peut être exécutée dans une transaction utilisateur. Ceci permet d'annuler les modifications. Si des modifications sont annulé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.
Autorisations
Requiert l'appartenance au rôle serveur fixe sysadmin ou au rôle de base de données fixe db_owner.
Exemples
L'exemple qui suit exécute DBCC CHECKALLOC
pour la base de données actuelle et pour la base de données AdventureWorks
.
-- Check the current database.
DBCC CHECKALLOC;
GO
-- Check the AdventureWorks database.
DBCC CHECKALLOC (AdventureWorks);
GO
Voir aussi
Référence
Autres ressources
Organisation des tables et des index
Gestion de l'espace utilisé par les objets
Aide et Informations
Assistance sur SQL Server 2005
Historique des modifications
Version | Historique |
---|---|
17 novembre 2008 |
|
14 avril 2006 |
|
5 décembre 2005 |
|