Opportunité d'utiliser STATISTICS_NORECOMPUTE

Je me suis récemment impliqué dans la maintenance d'un ensemble de bases de données avec des problèmes d'index intéressants. L'un des facteurs qui m'aggrave le plus est la différence d'indices entre les machines de développement, de test, de modèle et de production. Étant donné que les différences rendent le réglage des requêtes assez difficile, leur synchronisation est l'un de mes premiers projets.

En comparant les environnements de test et de modèle, j'ai remarqué que la plupart des index de l'environnement de modèle ont STATISTICS_NORECOMPUTEla valeur ONtandis que ceux de test ne le sont pas. Dans tous les environnements, un travail de nuit met à jour les statistiques de toutes les bases de données.

Je n'ai jamais traité STATISTICS_NORECOMPUTEauparavant, alors voici mes questions. Existe-t-il des meilleures pratiques pour gérer ce paramètre? Si je fais des mises à jour de statistiques à la fin de la journée, est-il préférable d'activer STATISTICS_NORECOMPUTEtous les environnements sur tous les index? Ou y a-t-il une bonne raison de ne pas le faire?

EDIT: J'ai trouvé un des blogs de Kimberly Tripp sur le sujet ici qui semble suggérer que STATISTICS_NORECOMPUTEdevrait être utilisé avec parcimonie au mieux. Mais je suis toujours préoccupé de le désactiver à l'échelle mondiale. Quelqu'un a-t-il essayé cela et qu'ont-ils vécu?

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 FULLSCANpé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.