Bonjour à tous,

Je recontre beaucoup de situation au seins desquelles j'ai l'impression que le "pouvoir" du DBCC CHECKDB reste un chose mystérieuse.
Il y a les "adorateurs", qui lancent la commande un peu n'importe quand, l'incluent dans les chaines d'ingestion de données.
Il y a les "détracteurs". Ce sont en général ceux qui sont proches de l'importance de la "PROD" et de sa disponibilité opérationnelle.
Il y a les "inconscients", qui ne savent pas que cette commande existe.
Je pense qu'il faille remettre l'église au centre du village.

Le problème est le combo temps-impact de la commande DBCC CHECKDB sur les bases de prod, les VLDB en particulier.
Donc pour moi cela se traduit par : "quelle est la stratégie minimale incluant une prise de risque rationnelle ?"

Le soucis est que la BOL n'est pas très compréhensible ; La distinction de sens de ces 2 phrases vous est évidente ?
  • Vérifie l'intégrité de toute les pages et structures qui composent la table ou la vue indexée
  • Vérifie la cohérence des structures d'allocation de l'espace disque pour une base de données spécifiée.


La BOL : https://learn.microsoft.com/fr-fr/sq...l-server-ver16
Une note d'attention :
Cela signifie que les commandes DBCC CHECKALLOC, DBCC CHECKTABLE et DBCC CHECKCATALOG ne doivent pas être exécutéesséparément de DBCC CHECKDB.
Il est déconseillé d'executer les commandes sous jacentes unitairement, car certains contrôles ne seraient pas fait.
les Bonnes pratiques
Nous vous recommandons d'utiliser l'option PHYSICAL_ONLY pour une utilisation fréquente sur des systèmes de production. L’utilisation de PHYSICAL_ONLY permet de raccourcir fortement le temps d’exécution de DBCC CHECKDB sur les grandes bases de données. Nous vous recommandons aussi d’exécuter régulièrement DBCC CHECKDB sans options. La fréquence à laquelle vous devez effectuer ces exécutions dépend de chaque activité et de son environnement de production.

Les options de la commandes permettent de :
Rédéfinir le volume à traiter (NOINDEX,EXTENDED_LOGICAL_CHECKS,PHYSICAL_ONLY,DATA_PURITY)
Réparer (REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD)
Informer (ALL_ERRORMSGS, NO_INFOMSGS
Agir sur le comportement (TABLOCK,MAXDOP)
Prévoir l'impact sur la tempDB (ESTIMATEONLY)

Réparer les problèmes ne se planifient pas !
Du coup cela implique qu'on peut se passer de planifier les contrôles de ce qu'on peut réparer ; la probilité de la panne et faible et on a une remédiation.

Si on est en Always On, ou en log shipping, le support de stockage devrait être distinct (!)
Du coup la probabilté d'incident physico-logique sur les 2 instances deviennent très faible.
On imagine pouvboir réparer l'un avec l'autre (dans le cas de AO, la réparation des pages défaillante est automatique)

Du coup on fait quoi ?
  • on associe le CHECKDB aux seules opérations de backup (ou de restore ?) ?
  • on utilise PHYSICAL_ONLY toutes les heures ? et sans option tous les jours ?



Merci de vos retours éclairés