Database
 sql >> Base de données >  >> RDS >> Database

Présentation de la fonction DBCC CheckDB

Introduction

La maintenance régulière de la base de données est une partie importante du travail d'un administrateur de base de données qui permet de s'assurer que les systèmes d'importance critique fonctionnent normalement. L'un des moyens les plus simples d'y parvenir consiste à automatiser les tâches liées à DBCC CheckDB. Quelle que soit la version de SQL Server que vous utilisez, il n'y aura jamais de base de données qui ne nécessite aucune maintenance. Vous devrez planifier l'entretien pour qu'il se produise régulièrement afin de pouvoir couvrir vos arrières surtout lors d'un véritable scénario catastrophe.

DBA est toujours le coupable

Chaque fois qu'il y a un problème de base de données, tous les yeux sont tournés vers le DBA. Que le problème ait été causé par la pluie ou qu'un développeur écrive un code malveillant entraînant une lenteur de la base de données, le DBA est toujours censé réparer le désordre. Et vous pouvez imaginer le genre de pression à laquelle vous devez faire face si on vous demande de restaurer rapidement une base de données en utilisant la dernière sauvegarde disponible qui, comme vous le découvrez au cours du processus, n'est pas valide et l'intégrité de la base de données a déjà été compromise quelques mois depuis. C'est là que réside la différence entre un DBA proactif et un DBA réactif. En réalité, votre stratégie de récupération est beaucoup plus critique que la stratégie de sauvegarde. À quoi peuvent servir les sauvegardes quotidiennes de la base de données si elles ne sont d'aucune utilité au moment de la restauration ?

Pourquoi la maintenance est-elle importante ?

Avec la croissance sans précédent des technologies de base de données et les nouvelles fonctionnalités apparaissant à chaque version, il est impératif pour vous, en tant qu'administrateur de bases de données, de garder une longueur d'avance et de vous assurer que vous suivez les meilleures pratiques du secteur en matière de maintenance de la base de données.

DBCC CheckDB et comment nous pouvons l'exécuter

DBCC CheckDB - ce nom est assez descriptif de la fonctionnalité. En termes simples, il vérifie les bases de données. Ceci est important pour s'assurer que la base de données fonctionne comme prévu. Fondamentalement, DBCC CheckDB vérifie l'intégrité logique et physique de tous les objets de la base de données. C'est ce que DBCC CheckDB fait sous le capot selon le officiel Documentation Microsoft :

  • Exécute DBCC CHECKALLOC sur la base de données - la cohérence des allocations d'espace disque

  • Exécute DBCC CHECKTABLE sur chaque table et vue de la base de données ; c'est l'intégrité de toutes les pages et structures qui composent la table ou la vue indexée.

  • Exécute DBCC CHECKCATALOG sur la base de données – ceci vérifie la cohérence du catalogue dans la base de données spécifiée.

  • Valide le contenu de chaque vue indexée dans la base de données.

  • Valide la cohérence au niveau des liens entre les métadonnées de la table et les répertoires/fichiers du système de fichiers lors du stockage des données varbinary(max) dans le système de fichiers à l'aide de FILESTREAM.

  • Valide les données Service Broker dans la base de données.

Lorsque vous exécutez la commande DBCC CheckDB explicitement ou via une tâche, elle effectue essentiellement tout ce qui précède.

Exécuter DBCC CheckDB directement sur une base de données

Vous pouvez exécuter la commande DBCC CheckDB directement sur une base de données et vérifier les résultats. Vérifiez la sortie de la commande comme indiqué sur la capture d'écran ci-dessous. La sortie affiche les détails des lignes dans les tableaux et le nombre de pages utilisées par ces lignes.

Si vous regardez attentivement, vous verrez plus de détails spécifiques aux objets de la base de données. Par exemple, sur la base de données "VLDB", je peux voir la sortie suivante :

« ID d'objet 1179151246 (objet 'Warehouse.ColdRoomTemperatures') :l'opération n'est pas prise en charge avec les tables à mémoire optimisée. Cet objet a été ignoré et ne sera pas traité."

Comme le montre cette sortie, DBCC CheckDB n'est pas pris en charge avec les tables optimisées en mémoire. Les tables à mémoire optimisée ont été introduites pour la première fois dans SQL Server 2014 en tant que fonctionnalité réservée aux entreprises. Cependant, au fil des ans, ils sont devenus une fonctionnalité populaire et répandue dans SQL Server.

Vous remarquerez également que DBCC Check a validé les données du courtier de services dans la base de données, comme indiqué ci-dessous.

"Résultats DBCC pour 'VLDB'.Service Broker Msg 9675, État 1 : Types de message analysés :14.Service Broker Msg 9676, État 1 : Contrats de service analysés :6.Service Broker Msg 9667, État 1 :Services analysés :3.Service Broker Msg 9668, État 1 :Files d'attente de service analysées :3.Service Broker Msg 9669, État 1 :Points de terminaison de conversation analysés :0.Service Broker Msg 9674, État 1 :Groupes de conversation analysés :0.Service Broker Msg 9670, État 1 :Liaisons de service à distance analysées :0. Service Broker Msg 9605, État 1 :Priorités de conversation analysées :0."

Enfin, une fois la commande DBCC CheckDB exécutée avec succès, vous verrez la sortie suivante :

Que se passe-t-il si des erreurs sont signalées après l'exécution de DBCC CheckDB ?

Dans l'exemple ci-dessus, vous pouvez voir que DBCC CheckDB s'est terminé sans aucune erreur. Cependant, si vous n'êtes pas aussi chanceux, vous pouvez rencontrer des erreurs de cohérence - et ce sera le moment où vous devrez prendre des décisions critiques. Si vous rencontrez des problèmes sur une base de données de production, il est préférable d'en informer les propriétaires d'entreprise ou votre directeur des opérations pour jouer cartes sur table. Vous pouvez soit leur donner la possibilité de restaurer la base de données à partir de la dernière sauvegarde disponible, soit essayer d'exécuter des commandes DBCC CheckDB avec des options supplémentaires.

Les messages d'erreur DBCC peuvent ressembler à celui ci-dessous :

Erreur de table :ID d'objet 36, ID d'index 1, ID de partition, ID d'unité d'allocation (type Données de ligne). Clés hors service sur la page (1:107), emplacements 6 et 9. CHECKDB a trouvé 0 erreur d'allocation et 1 erreurs de cohérence dans la table 'sys.syk' (ID d'objet 36).CHECKDB a trouvé 0 erreurs d'allocation et 1 erreurs de cohérence dans la base de données 'VLDB'.repair_rebuild est le niveau de réparation minimum pour les erreurs trouvées par DBCC CHECKDB (VLDB). 

Dans le message d'erreur, vous pouvez voir un message d'erreur soigneusement rédigé :"repair_rebuild est le minimum niveau de réparation des erreurs trouvées par DBCC CHECKDB ” – vous suggérant d'exécuter DBCC CheckDB avec l'option repair_rebuild. Regardez simplement le mot mis en surbrillance - "minimum". Cela signifie qu'avec l'option repair_rebuild, il n'y a aucune possibilité réelle de perte de données et SQL Server fait quelques correctifs rapides sous le capot. Veuillez vous référer à la commande ci-dessous pour exécuter DBCC CheckDB avec l'option repair_rebuild. Assurez-vous de placer la base de données en mode mono-utilisateur.

Selon la documentation Microsoft, l'option REPAIR_REBUILD est la version la plus inoffensive car il ne peut y avoir aucune perte de données. Cependant, si REPAIR_REBUILD ne corrige toujours pas les erreurs de cohérence, il existe une autre option :activer REPAIR_ALLOW_DATA_LOSS. En regardant le nom, nous savons qu'il y aurait une possibilité de perte de données si nous activions cette option. Pour cette raison, Microsoft nous avertit de l'utiliser avec une extrême prudence car il peut y avoir des conséquences inattendues lors de l'exécution de DBCC CheckDB avec REPAIR_ALLOW_DATA_LOSS. La commande DBCC CheckDB dans ce cas aura l'aspect suivant :

Points à considérer avant d'utiliser l'option de réparation avec DBCC CheckDB

  • Dans quelle mesure la base de données en question est-elle critique ?

  • La base de données se trouve-t-elle dans un environnement de production ou de test ?

  • Quelle est la taille de la base de données ?

  • Avez-vous une bonne stratégie de récupération au cas où des problèmes surviendraient ?

  • Avez-vous validé vos sauvegardes de base de données ?

En fonction de la situation et des réponses aux questions ci-dessus, essayez de prendre une décision en gardant à l'esprit les meilleurs intérêts du client.

Automatisation des tâches DBCC CheckDB sur SQL Server à l'aide de plans de maintenance de base de données

Eh bien, vous n'avez pas besoin d'exécuter toutes ces commandes manuellement sur vos serveurs. C'est pourquoi nous avons mis en place des plans de maintenance. Assurez-vous de programmer un cycle de maintenance régulier pour toutes vos bases de données à l'aide des plans de maintenance de base de données. C'est une tâche plutôt simple et directe. Sous les "Tâches du plan de maintenance", sélectionnez la "Tâche de vérification de l'intégrité de la base de données".

Cela ajoutera une sous-tâche à votre plan de maintenance pour programmer des contrôles d'intégrité pour vos bases de données. Assurez-vous de sélectionner les bases de données requises comme indiqué.

Veuillez vous assurer d'exécuter toutes les vérifications de la base de données pendant une période creuse de la semaine. Habituellement, les fenêtres de maintenance ont lieu les week-ends lorsque le serveur est moins occupé par rapport aux autres jours de la semaine. Cependant, cela varie d'un serveur à l'autre et dépend de l'application. Sur les systèmes de base de données critiques, des alertes sont généralement affichées chaque fois que DBCC CheckDB ou des contrôles d'intégrité sont manqués. De cette façon, les administrateurs de bases de données peuvent vérifier de manière proactive et s'assurer qu'ils ont terminé les contrôles d'intégrité pour éviter les surprises par la suite.

Automatisation des tâches DBCC CheckDB sur SQL Server à l'aide de scripts personnalisés ou d'autres scripts populaires

Les plans de maintenance SQL Server n'ont pas besoin d'être utilisés en permanence pour effectuer des tâches de maintenance sur votre instance SQL Server. Il existe d'autres scripts personnalisés disponibles que vous pouvez utiliser. L'un des outils de maintenance gratuits les plus populaires est la solution de maintenance d'Ola Hallengren. Vous pouvez installer l'ensemble de la solution de maintenance qui comprend des tâches de sauvegarde, d'optimisation, etc., ou vous pouvez télécharger uniquement les scripts pertinents liés aux contrôles d'intégrité. Dans cette démo, nous allons essayer d'installer les scripts spécifiques aux contrôles d'intégrité des bases de données.

Cliquez sur l'option DatabaseIntegrityCheck.sql comme indiqué pour télécharger les procédures stockées qui vérifient l'intégrité de la base de données. Après avoir exécuté ces procédures stockées sur la base de données master, je suis tombé sur ces messages d'avertissement :

"Le module 'DatabaseIntegrityCheck' dépend de l'objet manquant 'dbo.CommandExecute'. Le module sera toujours créé; cependant, il ne peut pas s'exécuter correctement tant que l'objet n'existe pas. 

Si vous exécutez la procédure stockée pour effectuer des vérifications d'intégrité, vous obtiendrez l'erreur suivante :

Comme l'indique l'erreur, vous pouvez télécharger le code manquant ici. Une fois cela fait, vous pouvez commencer à essayer les contrôles d'intégrité de la base de données.

Vous pouvez régler diverses options à l'aide des paramètres de commande DBCC supplémentaires. Vous pouvez trouver plus de détails et des exemples ici.

Cependant, dans cette démo, nous allons vérifier quelques exemples pour voir à quel point ces scripts sont vraiment simples et conviviaux.

Pour exécuter DBCC CheckDB sur toutes les bases de données utilisateur , vous devrez exécuter ce qui suit :

EXECUTE dbo.DatabaseIntegrityCheck@Databases ='USER_DATABASES',@CheckCommands ='CHECKDB'

Vous pouvez voir la commande qui a été exécutée et l'état du résultat qui confirme que DBCC CheckDB s'est terminé avec succès.

Pour exécuter DBCC Check uniquement pour les bases de données système, exécutez cette commande :

EXECUTE dbo.DatabaseIntegrityCheck@Databases ='SYSTEM_DATABASES',@CheckCommands ='CHECKDB'

Sur la capture d'écran, vous pouvez voir que le DBCC CheckDB a été effectué avec succès pour les bases de données système.

Pour exécuter DBCC CheckDB uniquement pour une base de données spécifique, exécutez ce qui suit :

EXECUTE dbo.DatabaseIntegrityCheck@Databases ='VLDB', -- votre nom de base de données spécifique@CheckCommands ='CHECKDB'

Dans l'exemple ci-dessus, vous avez vu quelques façons d'utiliser les paramètres. Cependant, il existe un certain nombre d'autres filtres que vous pouvez sélectionner en fonction de vos préférences. De plus, comme déjà mentionné, vous pouvez vous référer à ce lien pour une meilleure compréhension des scripts d'Ola Hallengren. Juste pour réitérer, j'utilise les scripts d'Ola Hallengren sur les serveurs que je gère et c'est fortement recommandé et reconnu au sein de la communauté SQL Server. Vous pouvez planifier les procédures stockées en fonction de vos paramètres préférés et les exécuter comme un travail SQL pendant les heures creuses. De cette façon, vous n'avez pas vraiment besoin d'exécuter l'un de ces scripts manuellement, vous pouvez donc vous concentrer sur d'autres tâches importantes.

Conclusion

  • Grâce à cet article, vous avez découvert DBCC CheckDB et comment il peut être utilisé
  • Vous avez également compris l'importance d'exécuter régulièrement DBCC CheckDB sur toutes vos bases de données importantes
  • Vous avez également appris l'importance d'avoir une stratégie de sauvegarde testée :il est recommandé de restaurer vos bases de données à l'aide d'une bonne sauvegarde au lieu de résoudre les erreurs de cohérence à l'aide des options de réparation DBCC
  • Vous avez également vu à quel point il est facile de configurer et d'automatiser des scripts à l'aide de plans de maintenance SQL Server ou de scripts personnalisés, par exemple celui d'Ola Hallengren
  • Vous avez également appris les risques de ne pas planifier DBCC CheckDB sur votre infrastructure prise en charge
  • Vous avez également appris que, quel que soit le serveur sur lequel vous vous trouvez ou l'infrastructure que vous utilisez, il ne peut y avoir de base de données qui ne nécessite aucune maintenance
  • Enfin, assurez-vous de garder vos bases de données en bonne santé et, dans tous les cas, soyez prêt pour les jours OFF qui peuvent ne pas être sous votre contrôle