C'est vraiment une situation que vous souhaitez examiner par table ou par index, et vous devez vraiment savoir ce qui est en production avant de prendre toute mesure. En cas de doute, utilisez également ce qui est en production dans les autres environnements, même si cela signifie utiliser un tas de paramètres fous. Vous ne pouvez tout simplement pas avoir une bonne idée du comportement de la production si les choses sont différentes en test ou en développement.
Quoi qu'il en soit, la recommandation générale de laisser les statistiques de mise à jour automatique activées ( STATISTICS_NORECOMPUTE = OFF
, qui est la valeur par défaut) est pour des raisons de sécurité, car si cela est désactivé et que rien ne met à jour manuellement les statistiques, le résultat pourrait être des plans d'exécution vraiment horribles qui ne changent jamais. après leur première création (et ne seront pas invalidés pour d'autres raisons plus tard).
Vous avez dit les statistiques mise à jour automatique est désactivée pour la plupart des indices (je pense d' abord mal lu que tous , non plus ). Pour les index dont les statistiques de mise à jour automatique sont toujours activées, ce paramètre est-il logique compte tenu de l'activité sur ces tables? Je m'attendrais à ce que ce soient des tables à activité plus élevée. Il est possible que beaucoup de travail ait été fait pour le déterminer, et cela peut valoir la peine de conserver (ou de bien réfléchir) ces paramètres. À tout le moins, notez de quelles statistiques il s'agit, car ces informations pourraient être utiles en cours de route.
En y réfléchissant davantage, je dirai que la stratégie actuelle a du sens. Est-ce mieux que de laisser les statistiques de mise à jour automatique activées pour tout? Il semble que quelqu'un l'ait pensé, au point que cela valait le compromis de la facilité de gestion d'avoir un travail SQL Agent associé.
Si l'idée était d'avoir de nouvelles statistiques disponibles sans bloquer les requêtes (comme celle-ci ), vous pourriez envisager de réactiver la mise à jour automatique pour tout, puis de l'activer AUTO_UPDATE_STATISTICS_ASYNC
également. Ensuite, modifiez probablement le calendrier des travaux pour qu'il s'exécute une fois par semaine au lieu de tous les jours, car vous souhaitez toujours que les statistiques soient mises à jour WITH FULLSCAN
périodiquement.
Je pourrais simplement le laisser, car vous avez probablement de plus gros poissons à faire frire si les index eux-mêmes sont différents entre les environnements et que les reconstructions de statistiques ne sont pas trop douloureuses. Ce qui existe maintenant a du sens; il vous suffit de rendre les choses cohérentes dans tous les environnements. C'est probablement légèrement meilleur que les paramètres plus simples que j'ai suggérés, au détriment de plus de travail. Mais découvrez ce qui est en production, tenez à l'utiliser et passez à des choses plus importantes; revisitez cela lorsque vous êtes sur le point d'avoir besoin de régler plus finement les performances - les meilleures statistiques du monde ne sauveront pas une requête qui manque un index critique.