Pourquoi définir les statistiques de mise à jour automatique sur Faux?

Je viens d'hériter d'une vingtaine d'instances de SQL Server, dans le cadre d'un projet d'acquisition plus large. Je suis en train d'évaluer les performances et je n'aime pas la façon dont les plans de maintenance ont été mis en œuvre.

Je vois des reconstructions d'index de couverture quotidiennes (je peux gérer celui-ci) et également une mise à jour manuelle quotidienne des statistiques.

Environ la moitié des bases de données ont été réglées sur Statistiques de mise à jour automatique = Faux, pour des raisons qui ne sont pas claires, sauf si on me dit que c'est pour réduire les `` problèmes de performances '' ...

J'ai toujours pensé et travaillé à la meilleure pratique de définir cela sur True et j'ai estimé que la mise à jour manuelle n'était pas nécessaire si ce paramètre était vrai. Ai-je tort?

Quelqu'un peut-il expliquer quel serait l'avantage d'avoir cet ensemble comme faux, mais de faire une mise à jour manuelle quotidienne à la place?

Je dois mentionner que certaines des bases de données sont hautement transactionnelles (des millions d'insertions, de suppressions, de mises à jour par jour) D'autres sont faibles en termes de taux de transaction, et certaines sont presque en lecture seule. Il n'y a cependant pas de rime ou de raison pour laquelle le paramètre de mise à jour automatique est défini sur False. Il semble que ce soit une loterie.

Vous avez raison, je crois également que dans la plupart des cas, la valeur Auto Update statisticsdoit être définie sur true, nous devons permettre à SQL Server de décider quand mettre à jour les statistiques et croyez-moi, cela fait du bon travail. Lorsque cela est défini sur true, assurez-vous que les statistiques sont mises à jour sur la distribution des données sur le terrain, ce qui pourrait éventuellement aider l'optimiseur à préparer un meilleur plan. La chose importante à noter ici est que les statistiques de mise à jour automatique se déclenchent lorsque 20% des données changent dans le tableau. Donc, vous ne devriez pas sentir que sur une table avec 100 000 lignes, si 10 lignes sont mises à jour, la mise à jour du statut se déclenchera.

Une analyse plus approfondie est effectuée par Paul Randal dans le blog Understanding When Statistics Will Automatically Update . Je n'ai vu aucun inconvénient si cette option est définie sur true. Oui, vous pouvez voir une certaine activité d'E / S lorsque cette option est définie sur true.

La conclusion importante que l'on peut tirer du blog est

Même si une statistique devient obsolète à la suite d'une modification, elle ne sera pas mise à jour automatiquement une fois la modification terminée. La statistique sera automatiquement mise à jour la prochaine fois qu'un plan de requête l'utilisera.

Pour les cas où vous venez de lire uniquement les bases de données ou les bases de données où vous sélectionnez simplement l'opération et il n'y a pas d'opération DML, dans ce cas, vous pouvez conserver l'option false mais, là encore, aucun dommage ne se produira si vous la maintenez vraie. Nous voyons principalement une base de données avec une certaine quantité d'activité.

C'est trop long pour un commentaire, je vais donc carillon dans un autre cas où l'on peut vouloir désactiver les statistiques de mise à jour automatique. J'ai travaillé avec des bases de données prenant en charge des charges de travail OLTP à volume élevé et un SLA de performance de requête stricte en millisecondes. Presque toutes les requêtes étaient triviales avec beaucoup d'attention aux détails de réglage des requêtes et des index et certaines des tables étaient assez grandes. Il n'y avait pas beaucoup de valeur à mettre à jour les statistiques pendant les périodes de pointe dans cette situation et les statistiques de mise à jour automatique violeraient le SLA. Par conséquent, la maintenance a été effectuée en dehors des périodes de pointe via un travail planifié.

Une autre option est d'activer les deux AUTO_UPDATE_STATISTICSet les AUTO_UPDATE_STATISTICS_ASYNCoptions de base de données. Cela permettra aux requêtes de procéder à des plans d'exécution basés sur des statistiques obsolètes plutôt que d'engager la surcharge de mise à jour des statistiques de manière synchrone. Cela est particulièrement approprié pour une charge de travail OLTP tant que le serveur est dimensionné pour accueillir la charge de travail de requête plus la mise à jour des statistiques d'arrière-plan.

En général, je dirais qu'il est avantageux d'avoir des statistiques de mise à jour automatique sur. Mais comme tout paramètre, il existe des raisons pour lesquelles vous pouvez l'activer ou le désactiver.

La première est que certaines tables ont beaucoup de désabonnement, et peut-être que les requêtes ne sont pas très sensibles à des statistiques précises. Pensez à ETL ou à d'autres scénarios en vrac où vous modifiez beaucoup de données, mais que vous ne les lisez pas à partir de là ou que vous ne les lisez pas beaucoup. Il n'y a pas grand-chose à avoir des mises à jour automatiques des statistiques et à provoquer un tas d'E / S pour fournir des statistiques plus précises qui ne seront jamais utilisées.

Vous pouvez également avoir des scénarios dans lesquels vous mettez à jour les données plusieurs fois dans la journée, mais vous ne voulez pas nécessairement mettre à jour les statistiques après chaque mise à jour. (Supposons que les données ne soient interrogées qu'à certaines heures de la journée - pas besoin de mettre à jour les statistiques plusieurs fois lorsque les données ne seront pas interrogées entre-temps de toute façon.)

Ou peut-être que vous avez juste une charge de travail lourde en écriture. Ou les lectures sont généralement des analyses complètes, où les statistiques ne sont pas extrêmement importantes.