DBCC CHECKDB non exécuté récemment

Lorsque SQL Server écrit des données sur vos disques, il suppose que tout va bien jusqu’à ce qu’il ait besoin de relire les données.

Malheureusement, en cas de corruption du stockage, celui-ci n’a pas la gentillesse d’alerter SQL Server. Et parfois, SQL Server est même connu pour se corrompre lui-même.

Nous devons vérifier périodiquement que les données sur le disque ont toujours un sens, et c’est là que DBCC CHECKDB intervient. Il vérifie à la fois les erreurs d’allocation et les erreurs de cohérence. De plus, s’il y a des problèmes, les messages d’erreur reviendront avec des informations concernant l’endroit où les erreurs existent, la gravité de l’erreur ainsi que l’option de réparation suggérée.

Il est essentiel d’exécuter CHECKDB sur une base régulière pour trouver les erreurs si elles existent car s’il y a une corruption, nous devons la réparer avant que nos dernières bonnes sauvegardes ne disparaissent.

Pour trouver le problème, nous vérifions chaque base de données pour nous assurer que DBCC CHECKDB a effectué une vérification réussie au cours des deux dernières semaines.

Vous ne le croyez pas ?

« Mais j’exécute CHECKDB tout le temps », pourriez-vous dire – eh bien, découvrons-le :

C’est tout. Mais la sortie est un cauchemar. C’est environ 80 lignes de trucs dont vous ne vous soucierez probablement jamais. Autour de la ligne 50, c’est ce que vous cherchez.

Hi, je suis un non-sens.

Et c’est probablement ce que vous allez voir ! Une date de 1900-01-01 etc. Cela signifie jamais. Si vous exécutez DBCC CHECKDB sur la base de données, peut-être comme ceci :

Et ensuite ré-exécuter la commande DBCC DBINFO, notre date est maintenant mise à jour à la date actuelle :

OK HOW HOW MUCH FUN WE’RE HAVING

Si la date n’est pas mise à jour, cela signifie une des deux choses suivantes : SQL Server ne peut pas écrire dans la base de données (comme si elle était en lecture seule), ou il trouve des erreurs (hoowee, pas bon.)

Pour résoudre le problème

Décidez si vous souhaitez utiliser des plans de maintenance intégrés, ou un outil gratuit comme les scripts CHECKDB gratuits d’Ola Hallengren. Quelques considérations:

• Les plans de maintenance ont une interface graphique, au cas où vous ne connaissez pas T-SQL.
• Les scripts gratuits d’Ola Hallengren prennent en charge des options plus fines, comme l’exécution automatique des contrôles de pureté des données (ce qui est une bonne chose).

Comment configurer la maintenance régulière pour vérifier la corruption

Option 1 : utiliser un plan de maintenance pour exécuter DBCC CHECKDB

Si vous utilisez des plans de maintenance, vous pouvez modifier les plans de maintenance dans SQL Server Management Studio sous Management, Maintenance Plans. Votre serveur peut avoir plusieurs plans de maintenance qui exécutent CHECKDB pour différents types de bases de données, comme un pour les bases de données système et un pour les bases de données utilisateur.

Développez le nœud Gestion dans SSMS, faites un clic droit sur Plans de maintenance et sélectionnez Nouveau plan.

Depuis la fenêtre de la boîte à outils, qui est parfois cachée sur la gauche, faites glisser la tâche de vérification de l’intégrité des bases de données sur l’onglet Plan de maintenance.

Lorsque vous double-cliquez sur la case de la tâche de vérification de l’intégrité des bases de données dans l’onglet Plan de maintenance, vous pourrez choisir les bases de données que vous voulez faire vérifier pendant le processus.

À partir de là, il ne reste plus qu’à l’ordonnancer, ce qui est tout comme l’ordonnancement d’une tâche d’agent.

Après avoir enregistré et fermé le plan de maintenance, assurez-vous de trouver la tâche connexe dans l’agent SQL Server et de définir les propriétés de notification pour informer un opérateur en cas d’échec.

Option 2 : Configurer les tâches de l’agent SQL pour exécuter DBCC CHECKDB en utilisant les scripts gratuits d’Ola Hallengren

Si vous mettez en œuvre des contrôles d’intégrité pour la première fois, envisagez d’utiliser les scripts de maintenance gratuits d’Ola Hallengren. Ils ne sont pas tout à fait aussi faciles que les plans de maintenance, mais ils sont beaucoup plus flexibles. Ils permettent également de diviser les opérations DBCC en petits morceaux pour les grandes bases de données. Sur les très grandes bases de données, CHECKDB peut prendre beaucoup de temps et de ressources – l’option WITH PHYSICAL_ONLY est plus rapide, mais omet les vérifications logiques.

Une fois que les tâches de l’agent sont en place, vous pouvez les programmer pour qu’elles s’exécutent aussi simplement que les plans de maintenance, ou vous pouvez les affiner avec les options supplémentaires documentées ici.