DBCC CHECKDB : Guide complet de MS SQL Server Santé de la base de données (2025)

DBCC CHECKDB est SQL ServerOutil principal d'intégrité des bases de données. Découvrez comment l'utiliser avec des exemples, corriger les corruptions et optimiser les performances.

3. Exécution de DBCC CHECKDB : étape par étape

Pré-requis 3.1

Vous trouverez ci-dessous la liste de contrôle avant d'exécuter toute opération DBCC CHECKDB :

• Sauvegarde complète de la base de données – Créez une sauvegarde complète avant d’exécuter des contrôles d’intégrité comme filet de sécurité si une corruption est découverte ou si des opérations de réparation deviennent nécessaires.
• Autorisations appropriées – Vous avez besoin des autorisations sysadmin ou db_owner pour exécuter les commandes DBCC CHECKDB
• Ressources système suffisantes :
  • Mémoire : 25 % de la taille de la base de données
  • Espace Tempdb : 10 à 15 % de la taille de la base de données
  • CPU : disponibilité de 50 à 70 % pendant la maintenance
  • E/S : attendez-vous à des opérations de lecture lourdes
• Accessibilité de la base de données – Vérifiez que votre base de données est accessible et non dans un état restreint, car CHECKDB nécessite un accès en lecture à toutes les pages de la base de données

3.2 Commande de base

Le most La commande DBCC CHECKDB de base comprend trois variantes courantes :

(1) Vérifiez la base de données actuelle (aucun paramètre) :

DBCC CHECKDB

(2) Vérifier une base de données par nom :

DBCC CHECKDB ('YourDatabaseName')

(3) en anglais Vérifier une base de données par ID :

DBCC CHECKDB(5)  -- Replace 5 with your database ID

Cette commande fondamentale effectue un contrôle d'intégrité complet de la base de données spécifiée, en examinant toutes les tables, index et structures système. Pour les bases de données dont le nom standard ne contient pas d'espaces, vous pouvez omettre les guillemets. La commande s'exécute jusqu'à la fin, affichant des messages de progression et les résultats finaux. Cette syntaxe simple est idéale pour les bases de données de petite taille ou lorsque vous disposez d'un temps de maintenance important.

Ci-dessous, une capture d'écran de l'exécution de DBCC CHECKDB dans SQL Server Studio de gestion (SSMS) :

3.3 Options complètes

Vous trouverez ci-dessous les options complètes pour DBCC CHECKDB :

Catégorie	Option	Description	Exemple DBCC CHECKDB
Options de réparation	REPAIR_REBUILD	Réparations sans perte de données (par exemple, reconstructions d'index)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Aucune réparation. Rétrocompatibilité uniquement.	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Répare toutes les erreurs (peut entraîner une perte de données)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Contrôle de la portée	NOINDEX	Ignore les vérifications d'index non clusterisés	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Vérifie uniquement l'intégrité du stockage physique (pages/enregistrements)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Vérifie les erreurs de valeur de colonne logique (par exemple, les dates non valides)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Vérifications logiques approfondies (vues indexées, index XML/spatiaux)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Contrôle de sortie	ALL_ERRORMSGS	Affiche toutes les erreurs (par défaut : 200 par objet)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Masque les messages d'information	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
Performances	TABLOCK	Utilise des verrous de table (réduit l'utilisation de TempDB mais bloque les écritures)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Remplace les paramètres de parallélisme	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Services Publics	ESTIMATEONLY	Estime l'espace TempDB nécessaire. (pas de vérification réelle)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Comprendre vos résultats

DBCC CHECKDB produira des résultats différents selon que son exécution est réussie ou non. Expliquons-les en détail.

4.1 L'exécution de CHECKDB se termine avec succès

Si l'exécution de DBCC CHECKDB se termine avec succès, elle signalera différents types de résultats en fonction de l'état de santé de votre base de données.

4.1.1 Aucun problème détecté

Si DBCC CHECKDB ne détecte aucun problème, vous verrez une sortie similaire à :

CHECKDB found 0 allocation errors and 0 consistency errors in database 'YourDatabase'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Ce résultat indique que votre base de données maintient une intégrité parfaite dans toutes les structures vérifiées.

4.1.2 Erreurs de corruption détectées

Chaque fois que DBCC CHECKDB détecte une erreur de corruption, il signale un message d'erreur avec la structure suivante :
Guide des niveaux de gravité :

• Niveau 16-19 XNUMX: Erreurs corrigibles par l'utilisateur, souvent une corruption mineure
• Niveau 20-24 XNUMX: Erreurs système, corruption grave nécessitant une attention immédiate
• Niveau 25: Erreurs fatales, la base de données peut être inaccessible

Les erreurs courantes incluent :

• Échecs de somme de contrôle de page (message 824)
• Erreurs d'allocation (message 8928)
• Problèmes de cohérence d'index (message 8964)

Comprendre la structure du message permet de hiérarchiser les actions de réponse et de déterminer les stratégies de récupération appropriées.

4.1.3 Messages d'information et d'avertissement courants

Les résultats de DBCC CHECKDB n'indiquent pas tous des problèmes graves. Ils peuvent également afficher des messages d'information et d'avertissement, notamment :

• Déclarations de réparation – Messages suggérant des commandes de réparation pour résoudre des problèmes mineurs
• Avertissements d'allocation – Avertissements concernant l’allocation d’espace qui n’affectent pas l’accès aux données
• Recommandations de performance – Suggestions pour la maintenance et l’optimisation des index
• Avis d'information – Messages d’état généraux qui ne nécessitent pas d’action immédiate

Ces messages fournissent des conseils de maintenance précieux tout en faisant la distinction entre une corruption critique nécessitant une action immédiate et des problèmes mineurs qui peuvent être résolus pendant les fenêtres de maintenance régulières.

Exemple de message d'avertissement :

DBCC results for 'InventoryDatabase'.
Msg 2570, Level 16, State 3, Line 1
Page (2:8452), slot 17 in object ID 485577333, index ID 0, partition ID 72057594038845456, 
alloc unit ID 72057594042515968 (type "In-row data").
Column "ProductPrice" value is out of range for data type "decimal". Update column to a legal value.
There are 45892 rows in 1247 pages for object "Products".
CHECKDB found 0 allocation errors and 1 consistency errors in table 'Products' (object ID 485577333).
CHECKDB found 0 allocation errors and 1 consistency errors in database 'InventoryDatabase'.

4.2 Abandons d'exécution de CHECKDB

Si CHECKDB s'interrompt pendant son exécution pour diverses raisons, il signalera un message d'erreur et ajoutera un journal d'erreurs avec le code d'état ci-dessous :

État	Description
0	L'erreur numéro 8930 a été générée. Cela indique une corruption des métadonnées ayant mis fin à la commande DBCC.
1	L'erreur numéro 8967 a été 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 d'urgence.
3	Cela indique une corruption des métadonnées qui a mis fin à la commande DBCC.
4	Une violation d'assertion ou d'accès a été détectée.
5	Une erreur inconnue s'est produite qui a mis fin à la commande DBCC.

Exemple de message d'erreur :

Failed:(-1073548784) Executing the query "DBCC CHECKDB('InventoryDB') WITH NO_INFOMSGS" failed with the following error: "There is insufficient system memory to run this query.Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.

ou

2024-11-18 09:52:41.38 spid35 I/O error (bad page ID) detected during read at offset 0x00000024886000 in file 'C:\Data\MSSQL\DATA\SalesDatabase.mdf'.

Exemple de journal d'erreurs :

11/15/2024 09:23:17,spid52,Unknown,DBCC CHECKDB (SalesDatabase) WITH all_errormsgs no_infomsgs executed by CORP\dbadmin terminated abnormally due to error state 3. Elapsed time: 1 hours 32 minutes 18 seconds.

Dans un tel cas, vous pouvez essayer des options avancées alternatives telles que DataNumen SQL Recovery pour réparer la corruption dans votre base de données.

5. Correction des erreurs de corruption

5.1 Sauvegarde et restauration : la solution la plus sûre

Lorsque DBCC CHECKDB identifie des erreurs de corruption, la restauration à partir d'une sauvegarde propre représente la méthode la plus sûre et la plus efficace.ost Solution fiable. Cette approche garantit l'intégrité des données tout en éliminant les causes de corruption sous-jacentes. Avant la restauration, vérifiez l'intégrité de la sauvegarde à l'aide de RESTAURER LA VÉRIFICATION UNIQUEMENT Commandes et envisagez des options de récupération instantanée pour minimiser la perte de données. Documentez les détails de la corruption pour analyser les causes profondes, car les problèmes matériels ou les bugs logiciels peuvent nécessiter une attention particulière pour éviter qu'ils ne se reproduisent.

5.2 Solutions de corruption au niveau de la page

Pour une corruption de page isolée affectant de petites portions de données, SQL Server L'édition Entreprise offre des fonctionnalités de restauration de pages qui réparent des pages endommagées spécifiques sans restauration complète de la base de données. Cette technique avancée nécessite un modèle de récupération complet et des sauvegardes de journaux à jour.

Processus de restauration de page étape par étape :

1. Identifier la page corrompue à partir du message d'erreur CHECKDB (par exemple, page 1:256)
2. Effectuer une sauvegarde actuelle du journal pour capturer les transactions récentes :

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Log.trn'

3. Restaurer la page corrompue du most sauvegarde complète récente :

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Full.bak'

4. Appliquer une sauvegarde différentielle (si disponible):

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Diff.bak'

5. Appliquer toutes les sauvegardes de journaux en séquence, y compris celui qui vient d'être créé :

RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log1.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log2.trn'
-- Continue for all log backups in order
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log.trn'

6. Effectuez une sauvegarde finale du journal et restaurez-le pour mettre la page à jour :

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Final.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Final.trn'

Alternative pour les données non critiques : Si la corruption affecte des données non critiques, vous pouvez exporter les lignes non affectées vers de nouvelles tables avant de reconstruire les structures corrompues :

-- Export good data to a new table
SELECT * INTO YourTable_Backup 
FROM YourTable 
WHERE NOT EXISTS (SELECT 1 FROM corrupt_page_list WHERE page_id = target_page)

-- Drop and recreate the corrupted table
DROP TABLE YourTable
-- Recreate table structure and reload clean data

5.3 Corrections rapides pour la corruption d'index

La corruption d'index répond souvent bien aux opérations de reconstruction qui recréent les structures d'index sans affecter les données de table sous-jacentes :

ALTER INDEX ALL ON YourTable REBUILD

Cette approche fonctionne particulièrement bien pour la corruption d'index non clusterisé, car la reconstruction régénère les pages d'index à partir des données de la table source, éliminant ainsi efficacement la corruption tout en préservant toutes les informations d'origine.

6. Utilisez REPAIR_REBUILD et REPAIR_ALLOW_DATA_LOSS

Si les méthodes précédentes échouent toutes ou ne sont pas réalisables, vous pouvez utiliser les options REPAIR_REBUILD et REPAIR_ALLOW_DATA_LOSS pour réparer la base de données.

6.1 RÉPARATION_RECONSTRUCTION (Option plus sûre) :

• Utiliser pour: Corruption d'index et erreurs d'allocation mineures
• Sécurité des données : Tente de corriger la corruption sans supprimer les données
• Niveau de risque: Faible – aucune perte de données prévue
• Scénarios typiques : Corruption d'index non clusterisé, problèmes mineurs de métadonnées
• Exemple de commande : DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (Dernier recours) :

• Utiliser pour: Corruption grave lorsque les sauvegardes ne sont pas disponibles
• Sécurité des données : Peut supprimer les données corrompues pour restaurer les fonctionnalités de la base de données
• Niveau de risque: Élevé – perte permanente de données possible
• Scénarios typiques : Corruption de page, dommages à la table système, erreurs de chaîne d'allocation
• Exemple de commande : DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Meilleures pratiques pour ces options :

• Toujours tester opérations de réparation sur les copies de bases de données lorsque cela est possible
• Toujours sauvegarder avant d'exécuter ces options
• Documenter tous les changements à des fins de conformité et de dépannage
• Définir la base de données en mode mono-utilisateur avant d'exécuter les opérations de réparation

Normalement, nous devrions essayer RÉPARATION_RECONSTRUCTION option d'abord. Si cela échoue, essayez REPAIR_ALLOW_DATA_LOSS option.

6.4 Résultats de REPAIR_ALLOW_DATA_LOSS

6.4.1 La réparation réussit malgré la perte de données

Parfois, la REPAIR_ALLOW_DATA_LOSS l'option réussira, mais certaines données sont lost après la réparation.

Vous trouverez ci-dessous quelques exemples de messages :

CHECKDB found 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
CHECKDB fixed 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Msg 8909, Level 16, State 1, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 45035996309880832 (type Unknown), page ID (1:553) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
The error has been repaired.
Msg 8939, Level 16, State 98, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 111464090777419776 (type Unknown), page (0:0). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 2057 and -1.
Could not repair this error.

C'est parce que DBCC CHECKDB corrige la base de données en abandonnant certains enregistrements endommagés, mais en fait, most d'entre eux peuvent encore être récupérés via DataNumen SQL Recovery.

Exemples de fichiers :

SQL Server version	Fichier MDF corrompu	Fichier MDF fixé par DataNumen SQL Recovery
SQL Server 2014	Erreur10_1.mdf (Msg 8909 suivi de Msg 8939) (600 enregistrements lost avec REPAIR_ALLOW_DATA_LOSS)	Erreur10_1_fixed.mdf (Aucun enregistrement lost)
SQL Server 2014	Erreur10_2.mdf (Msg 8909 suivi de Msg 8939) (6000 enregistrements (50 %) lost avec REPAIR_ALLOW_DATA_LOSS)	Erreur10_2_fixed.mdf (Seulement 100 enregistrements lost)
SQL Server 2014	Error7.mdf (100 enregistrements lost avec REPAIR_ALLOW_DATA_LOSS)	Erreur7_fixe.mdf (Un seul enregistrement lost)

6.4.2 Échec de la réparation – Envisager une solution professionnelle

If REPAIR_ALLOW_DATA_LOSS échoue, il affichera un ou plusieurs messages d'erreur.

Voici quelques exemples :

DBCC results for ‘MyDatabase’.
CHECKDB found 0 allocation errors and 0 consistency errors in database ‘MyDatabase’.
Msg 824, Level 24, State 2, Line 8
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xea8a9a2f; actual: 0x37adbff8). It occurred during a read of page (1:28) in database ID 39 at offset 0x00000000038000 in file ‘MyDatabase.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Msg 7909, Level 20, State 1, Line 8
The emergency-mode repair failed.You must restore from backup.

Msg 8992, Level 16, State 1, Line 8
Check Catalog Msg 3852, State 1: Row (object_id=69) in sys.objects (type=S ) does not have a matching row (object_id=69,column_id=1) in sys.columns.

Msg 8945, Level 16, State 1, Line 8
Table error: Object ID 41, index ID 1 will be rebuilt.
Could not repair this error.

Msg 2510, Level 16, State 17, Line 8
DBCC checkdb error: This system table index cannot be recreated.
Repair: The Nonclustered index successfully rebuilt for the object “sysidxstats” in database “MyDatabase”.

Msg 8921, Level 16, State 1, Line 8
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Msg 8998, Level 16, State 2, Line 8
Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID 39 pages from (1:0) to (1:8087). See other errors for cause.
CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object.
Msg 2575, Level 16, State 1, Line 8
The Index Allocation Map (IAM) page (1:157) is pointed to by the next pointer of IAM page (0:0) in object ID 3, index ID 1, partition ID 196608, alloc unit ID 196608 (type In-row data), but it was not detected in the scan.
Could not repair this error.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘sys.sysrscols’ (object ID 3).

Msg 8948, Level 16, State 3, Line 8
Database error: Page (1:295) is marked with the wrong type in PFS page (1:1). PFS status 0x70 expected 0x60.
The error has been repaired.
Msg 8905, Level 16, State 1, Line 8
Extent (1:296) in database ID 39 is marked allocated in the GAM, but no SGAM or IAM has allocated it.
The error has been repaired.

Msg 5028, Level 16, State 4, Line 4
The system could not activate enough of the database to rebuild the log.

Msg 5125, Level 24, State 2, Line 2
File ‘C:Program FilesMicrosoft SQL ServerMSSQL12.SQL2014MSSQLDATASalesDatabase.mdf’ appears to have been truncated by the operating system. Expected size is 5120 KB but actual size is 5112 KB.
Msg 3414, Level 21, State 1, Line 2
An error occurred during recovery, preventing the database ‘SalesDatabase’ (39:0) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

Msg 3313, Level 21, State 1, Line 2
During redoing of a logged operation in database ‘SalesDatabase’, an error occurred at log record ID (135:752:2). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.

Dans ces scénarios, vous devez utiliser une solution professionnelle telle que DataNumen SQL Recovery pour réparer votre base de données.

Exemples de fichiers

SQL Server version	Fichier MDF corrompu	Fichier MDF fixé par DataNumen SQL Recovery
SQL Server 2014	Erreur1_3.mdf (Message unique 824)	Erreur1_3_fixed.mdf
SQL Server 2014	Erreur1_1.mdf (Erreurs continues Msg 824)	Erreur1_1_fixed.mdf
SQL Server 2014	Erreur1_2.mdf ((Msg 824 suivi de Msg 7909)	Erreur1_2_fixed.mdf
SQL Server 2014	Erreur4_1.mdf (Msg 8992 suivi de Msg 3852)	Erreur4_1_fixed.mdf
SQL Server 2014	Erreur4_2.mdf (Msg 8992 suivi de Msg 3852)	Erreur4_2_fixed.mdf
SQL Server 2014	Erreur5.mdf (Message 8945)	Erreur5_fixe.mdf
SQL Server 2014	Erreur6.mdf (Message 2510)	Erreur6_fixe.mdf
SQL Server 2014	Erreur2.mdf (Message 2575)	Erreur2_fixe.mdf
SQL Server 2014	Erreur11.mdf (Message 8905)	Erreur11_fixe.mdf
SQL Server 2014	Erreur3.mdf (Message 5028)	Erreur3_fixe.mdf
SQL Server 2014	Error8.mdf (Message 5125)	Error8_fixed.mdf
SQL Server 2014	Erreur9.mdf (Message 3313)	Erreur9_fixe.mdf

7. Meilleures pratiques

7.1 Planification des opérations CHECKDB régulières

Implémentez l'exécution hebdomadaire de DBCC CHECKDB pour les bases de données de production critiques, avec des vérifications quotidiennes pour les systèmes à fort trafic. Planifiez les opérations pendant les périodes de faible utilisation afin de minimiser l'impact sur les performances, et envisagez une rotation entre les vérifications complètes et les options PHYSICAL_ONLY en fonction de la taille de la base de données et des fenêtres de maintenance. Planification automatisée via SQL Server L'agent assure une exécution cohérente tout en offrant des capacités de surveillance et d'alerte centralisées.

7.2 Gestion de l'impact sur les performances

Les opérations DBCC CHECKDB consomment des ressources système importantes, ce qui peut affecter l'activité simultanée des utilisateurs. Surveillez l'utilisation du processeur, la consommation de mémoire et les E/S disque pendant les vérifications afin de comprendre les modèles d'impact sur les performances. Envisagez d'utiliser les options NOINDEX pour les vérifications de routine, en réservant la validation complète aux fenêtres de maintenance mensuelles. Mettez en œuvre des extensions de délai d'expiration des requêtes et des stratégies de communication avec les utilisateurs pour gérer les attentes pendant les périodes de vérification d'intégrité.

7.3 Planification de la fenêtre de maintenance

Coordonnez la planification de DBCC CHECKDB avec les autres activités de maintenance, telles que les sauvegardes, la reconstruction d'index et les mises à jour de statistiques. Évitez le chevauchement d'opérations gourmandes en ressources, susceptibles d'entraîner une dégradation des performances ou des problèmes de délai d'attente. Planifiez les fenêtres de maintenance en fonction des prévisions de croissance de la base de données, afin de garantir un délai suffisant pour une vérification complète de l'intégrité à mesure que le volume de données augmente.

7.4 Surveillance et alerte automatisées

Configurez SQL Server Alertes d'agent pour informer immédiatement les administrateurs lorsque DBCC CHECKDB détecte une corruption. Mettez en œuvre des solutions d'analyse des journaux qui extraient et catégorisent les résultats des contrôles d'intégrité, permettant ainsi l'analyse des tendances et l'identification proactive des problèmes. Créez des procédures d'escalade définissant les délais de réponse et les responsables des différents niveaux de corruption.

8. DBCC CHECKTABLE : l'alternative légère

8.1 Quand utiliser CHECKTABLE au lieu de CHECKDB

DBCC CHECKTABLE fournit une vérification d'intégrité ciblée pour les tables individuelles, ce qui le rend idéal pour tarDépannage et maintenance d'objets de base de données spécifiques. Utilisez CHECKTABLE pour analyser les problèmes de performances de tables spécifiques, valider des tables métier critiques entre deux vérifications complètes de la base de données ou lorsque des contraintes de temps empêchent une validation complète de la base de données. Cette approche s'avère particulièrement utile dans les bases de données volumineuses où les opérations CHECKDB complètes dépassent les fenêtres de maintenance disponibles.

8.2 Syntaxe et exemples de DBCC CHECKTABLE

La commande de base CHECKTABLE tarobtient des tables spécifiques :

DBCC CHECKTABLE('YourTable')

Comme CHECKDB, CHECKTABLE prend en charge diverses options, dont NOINDEX pour l'optimisation des performances et les paramètres de réparation pour la résolution des corruptions. Vous pouvez également spécifier des noms de schéma pour une identification précise des tables :

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

Ce tarL'approche geted permet une vérification granulaire de l'intégrité tout en maintenant les performances du système pendant les heures ouvrables.

8.3 Avantages en termes de performances pour les grandes bases de données

Les opérations CHECKTABLE sont nettement plus rapides que les vérifications complètes de la base de données, ce qui permet des vérifications d'intégrité plus fréquentes des tables critiques. Cette approche permet une validation quotidienne des tables métier essentielles, tout en réservant les opérations CHECKDB complètes à des planifications hebdomadaires ou mensuelles. Grâce à une consommation de ressources réduite, CHECKTABLE est parfaitement adapté à une exécution en environnement de production avec un impact minimal sur l'utilisateur.

9. Lorsque CHECKDB échoue

DBCC CHECKDB échouera dans divers scénarios, notamment :

• Exécution de DBCC CHECKDB se termine anormalement
• L'exécution de DBCC CHECKDB se termine avec succès, mais le options de réparation échec de la réparation de la base de données.

Dans ces scénarios, nous avons besoin d’un outil plus professionnel pour nous aider à corriger les corruptions dans la base de données.

9.1 Introduction à DataNumen SQL Recovery

DataNumen SQL Recovery offre des fonctionnalités plus avancées :

• Meilleur taux de récupération dans l'industrie.
• Récupérez les fichiers de base de données gravement corrompus.
• Récupérez tous les objets de base de données, y compris les tables, les index, les vues, les déclencheurs, les règles et les valeurs par défaut.
• Récupérez les procédures stockées, les fonctions scalaires, les fonctions table en ligne et les fonctions table à plusieurs instructions.
• Récupérer les enregistrements supprimés définitivement.
• Décrypter les objets cryptés dans SQL Server bases de données.
• Réparer les fichiers MDF par lots.
• Options de réparation complètes.
• Journalisation et rapports avancés.
• Support pour tous SQL Server versions.
• Disponibilité du support technique
• Mises à jour et améliorations régulières

9.2 Comparaison des taux de réussite

Les taux de réussite de la récupération diffèrent considérablement :

• DBCC CHECKDB et CHECKTABLE : 1.27% taux de récupération moyen
• DataNumen: 92.6% taux de récupération

Vous trouverez ci-dessous une comparaison concurrentielle complète :

9.3 Récupération après une corruption grave

Capacités avancées pour les cas graves :

• Récupération après un stockage physiquement endommagé
• Récupération à partir de disques formatés ou de systèmes en panne
• Récupérer à partir d'images de disque, de fichiers de sauvegarde, de fichiers de disque de machine virtuelle, de temporary fichiers, etc.

9.4 Quand envisager des solutions professionnelles

• Aucune sauvegarde récente disponible
• Échec de DBCC CHECKDB
• Scénarios de corruption grave
• Traitement des données commerciales critiques
• Quand le temps est critique
• Quand une récupération maximale est essentielle

10. FAQ

11. Conclusion

11.1 Résumé des points clés

11.1.1 Récapitulatif des commandes DBCC CHECKDB essentielles

Maîtrisez la syntaxe de base DBCC CHECKDB pour une vérification complète de la base de données, utilisez les options NOINDEX et PHYSICAL_ONLY pour l'optimisation des performances et comprenez CHECKTABLE pour tarVérification des tables geted. Ces commandes fondamentales constituent le fondement de la maintenance proactive des bases de données, permettant une détection précoce des corruptions et une surveillance systématique de l'intégrité.

11.1.2 Rappel des meilleures pratiques critiques

Maintenez toujours des sauvegardes à jour avant d'effectuer des contrôles d'intégrité, planifiez des opérations CHECKDB régulières en fonction de la criticité de la base de données et implémentez une surveillance automatisée pour détecter immédiatement les alertes de corruption. N'oubliez pas que la prévention par une surveillance régulière surpasse les approches réactives, et les solutions de récupération professionnelles offrent des options de sauvegarde précieuses lorsque les outils standards s'avèrent insuffisants.

11.2 Quand utiliser DBCC CHECKDB par rapport aux solutions avancées

Utilisez DBCC CHECKDB pour la surveillance régulière de l'intégrité et la résolution des corruptions mineures, tout en réservant les outils de récupération professionnels aux scénarios de corruption grave, au-delà des capacités de réparation intégrées. Le cadre décisionnel doit prendre en compte la disponibilité des sauvegardes, la criticité des données, les contraintes de temps et la gravité de la corruption. Les administrateurs de bases de données performants combinent une surveillance régulière de CHECKDB avec des stratégies de sauvegarde complètes et une connaissance des options de récupération avancées lorsque les approches standard s'avèrent insuffisantes.

11.3 Liste de contrôle de santé quotidienne rapide pour les administrateurs de bases de données

Au-delà de l'exécution de DBCC CHECKDB, maintenez une santé optimale de la base de données grâce à ces pratiques quotidiennes essentielles :

1. Vérifier l'intégrité de la sauvegarde

• Confirmer que les sauvegardes planifiées ont été effectuées avec succès
• Utilisez RESTORE VERIFYONLY pour vérifier la lisibilité de la sauvegarde
• Assurez-vous que les copies hors site sont synchronisées et accessibles

Vous pouvez également obtenir plus d'informations auprès de notre guide complet sur SQL Server sauvegarde.

2. Vérifier l'état de cohérence

• Vérifiez les résultats automatisés DBCC CHECKDB des exécutions nocturnes
• Écran tactile SQL Server journaux d'erreurs pour les avertissements de corruption
• Enquêter immédiatement sur toute défaillance d’intégrité

3. Surveiller la santé du serveur

• Vérifiez les métriques du processeur, de la mémoire et des E/S du disque
• Vérifier la disponibilité de l'espace tempdb
• Identifier les processus bloqués et les requêtes de longue durée

4. Suivre l'activité de blocage

• Examiner les graphiques de blocage des événements de santé du système
• Identifier les requêtes problématiques et optimiser avec les équipes de développement
• Surveiller le nombre de victimes de blocage et l'impact sur l'entreprise

Rappels importants

• Évitez les réductions fréquentes de la base de données – Cela augmente la fragmentation et dégrade les performances. Ne réduisez la taille de la mémoire qu'après des suppressions de données importantes, lorsque cela est vraiment nécessaire.
• Automatiser les tâches de surveillance grâce à SQL Server Tâches d'agent ou plans de maintenance avec alertes pour les problèmes critiques.
• Tester les procédures de reprise après sinistre hebdomadairement pour garantir que les sauvegardes sont restaurables et que les objectifs de récupération restent atteignables.

En combinant cette liste de contrôle quotidienne avec les opérations DBCC CHECKDB régulières, vous créez une protection complète pour votre environnement de base de données grâce à une surveillance proactive et une réponse rapide aux problèmes.

12. Références

1. Microsoft Learn. « DBCC CHECKDB (Transact-SQL) ». SQL Server Documentation. Microsoft Corporation.
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn. « Résoudre les erreurs de cohérence de base de données signalées par DBCC CHECKDB. » SQL Server Documentation. Microsoft Corporation.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors