Database
 sql >> Base de données >  >> RDS >> Database

Suivi des mises à jour automatiques des statistiques

Lorsque vous créez une nouvelle base de données dans SQL Server, l'option Mise à jour automatique des statistiques est activée par défaut. Il est généralement recommandé de laisser cette option activée. Idéalement, les statistiques sont gérées par une tâche planifiée et l'option automatique est utilisée comme un filet de sécurité - disponible pour mettre à jour les statistiques dans le cas où une mise à jour planifiée ne se produit pas ou n'inclut pas accidentellement toutes les statistiques existantes.

Certains DBA s'appuient uniquement sur les mises à jour automatiques pour gérer les statistiques, et tant qu'il n'existe aucun problème de performances lié à des statistiques obsolètes ou mal échantillonnées, cela est acceptable. Si vous comptez sur cette option pour gérer vos statistiques et que vous avez de très grandes tables, il peut être utile d'implémenter l'indicateur de trace 2371. Comme pour tout indicateur de trace, assurez-vous de tester avec une charge de travail représentative avant de l'implémenter en production. Vous savez peut-être déjà qu'il y a des moments où une mise à jour automatique peut affecter les performances du système. Par exemple, la mise à jour d'une statistique peut introduire un pic de CPU ou d'E/S lors de la lecture des données de la table ou de l'index, ainsi que retarder l'exécution de la requête pendant la mise à jour. Il existe une autre option de base de données que vous pouvez activer pour résoudre ce délai de requête, et je l'aborderai plus tard dans cet article.

La question que l'on me pose souvent est :"Comment savoir si les mises à jour automatiques des statistiques causent problèmes de performances ?" Une option consiste à les suivre et à lier les mises à jour à un changement de performances. De nombreuses options existent pour suivre les mises à jour, et dans cet article, nous passerons en revue quelques-unes des méthodes disponibles afin que vous puissiez choisir puis option qui correspond le mieux à votre méthode existante de surveillance des problèmes de performances.

Traçage SQL

Si vous exécutez SQL Server 2008 R2 ou une version antérieure dans votre environnement, SQL Trace est une méthode que vous pouvez utiliser pour capturer les mises à jour automatiques. Le script de définition de trace utilisé ci-dessous ne capture que l'événement Auto Stats, qui intercepte lorsqu'une statistique se met à jour automatiquement et lorsqu'une statistique se crée automatiquement. Une fois que cette trace a été exécutée pendant un certain temps dans votre environnement, vous pouvez la charger dans une table, puis interroger la sortie pour voir quelles mises à jour se sont produites. Le script inclus ci-dessous présente un exemple utilisant l'exemple de base de données de statistiques de baseball.

Événements étendus

Si vous exécutez SQL Server 2012 ou une version ultérieure, je vous recommande d'utiliser les événements étendus pour capturer les mises à jour automatiques. Comme le script SQL Trace, le script de définition de session inclus ne capture que les événements Auto Stats - encore une fois, à la fois les mises à jour automatiques et les créations automatiques. Une fois que la session XE a été exécutée pendant un certain temps, vous pouvez charger la sortie dans une table via l'interface utilisateur, puis l'interroger pour voir quelles mises à jour se sont produites. Le script inclus parcourt le même exemple que précédemment, mais cette fois en utilisant des événements étendus pour collecter les données.

sys.dm_db_stats_properties

Une troisième option que vous pourriez envisager pour surveiller les mises à jour des statistiques est le sys.dm_db_stats_properties DMF, disponible uniquement dans SQL Server 2008 R2 SP2 et supérieur, et SQL Server 2012 SP1 et supérieur. Même si j'aime ce DMF, cette solution est plus délicate pour s'assurer que vous avez capturé toutes les données, et l'examen de la sortie demande plus de travail. Avec le DMF, chaque mise à jour automatique n'est pas suivie, nous nous contentons de mettre à jour les informations des statistiques de tendance pour voir quand les mises à jour se produisent.

C'est une tâche simple :vous créez une table pour contenir les informations statistiques, puis les informations d'instantané du DMF vers la table sur une base régulière. La clé ici est de déterminer la fréquence de capture des données. Chaque heure est probablement exagérée, une fois par jour n'est peut-être pas assez fréquent. Je recommande de commencer par un travail de l'Agent SQL qui capture les données DMF toutes les quatre heures. Laissez-le fonctionner pendant quelques jours, puis vérifiez vos données. Si les statistiques sont mises à jour une fois par jour au maximum, vous pouvez augmenter l'intervalle à toutes les huit ou douze heures. Si les statistiques sont facilement mises à jour toutes les quatre heures, réduisez votre intervalle à toutes les deux heures - vous voulez vous assurer que vous capturez chaque mise à jour. Pour cette raison, pour certains systèmes, sys.dm_db_stats_properties cela ne vaut peut-être pas la peine ; une session XE ou Trace pourrait être plus simple.

Un dernier exemple de script présente un exemple d'utilisation de sys.dm_db_stats_properties aux mises à jour des tendances des statistiques. Sachez que ce script ne capture que les informations statistiques d'une seule table. Si vous modifiez le script pour capturer chaque table de la base de données, il y aura beaucoup plus de données à analyser.

Étapes suivantes

Téléchargez les exemples de scripts et décidez de la méthode à utiliser pour suivre les mises à jour des statistiques.

Une fois que vous avez les données qui indiquent quand les mises à jour automatiques se produisent, vous devez les lier aux problèmes de performances connus. En tant que tel, si vous ne suivez aucune mesure de performance, les données de mise à jour des statistiques automatiques ne vous aideront pas avec tout type de corrélation. En supposant que vous ayez des horodatages pour tout problème de performances, vous pouvez le comparer à StartTime et EndTime de Trace, l'timestamp depuis XE, ou last_updated à partir de sys.dm_db_stats_properties DMF, pour déterminer si la mise à jour automatique a affecté les performances du système.

Si vous ne pouvez pas établir de corrélation entre les mises à jour et les problèmes de performances, vous pouvez exclure les mises à jour comme cause du problème et vous concentrer sur un autre domaine. Si les mises à jour sont la cause principale, vous avez deux options :désactiver l'option de mise à jour automatique des statistiques ou activer l'option de mise à jour automatique des statistiques de manière asynchrone. Les deux ont des avantages et des inconvénients que vous, en tant que DBA, devez prendre en compte.

Désactivation des statistiques de mise à jour automatique

Si vous choisissez de désactiver l'option de mise à jour automatique des statistiques, les deux choses les plus importantes à savoir sont :

  1. Vous devez absolument gérer vos statistiques via une tâche de maintenance ou une tâche personnalisée.
  2. Les requêtes ne se recompilent pas lorsque vous mettez à jour les statistiques dans SQL Server 2008 R2 et versions antérieures.

Je considère le deuxième élément comme un plus grand défi - je suis un grand défenseur de la gestion des statistiques et je pense que c'est quelque chose que les administrateurs de bases de données font de toute façon. Le plus gros problème est que, même si la mise à jour des statistiques normalement provoque la recompilation des requêtes (pour tirer parti des statistiques mises à jour), cela pas se produire lorsque l'option de mise à jour automatique des statistiques est désactivée. J'ai déjà écrit à ce sujet et je vous recommande de consulter ces informations si vous n'êtes pas familier avec ce comportement. Voir également un post de suivi pour les options pour y remédier.

En général, ce n'est pas la voie que je recommande. Il existe des cas extrêmes très spécifiques où cela pourrait être approprié, mais je préférerais voir un administrateur de base de données effectuer des mises à jour manuelles (par le biais de tâches planifiées) pour éviter les mises à jour automatiques et laisser l'option activée par mesure de sécurité.

Activer la mise à jour automatique des statistiques de manière asynchrone

Lorsque vous activez l'option Mise à jour automatique des statistiques de manière asynchrone, si une statistique a été invalidée et qu'une requête qui utilise cette statistique est exécutée, la statistique ne sera pas mise à jour tant que la requête ne sera pas terminée - la mise à jour est asynchrone. L'avantage ici est que la mise à jour n'affectera pas la requête qui a été exécutée; l'inconvénient est que la requête utilisera le plan existant, qui peut ne plus être le plan optimal. Le fait que le plan soit toujours optimal dépendra de votre charge de travail (par exemple, une charge de travail de création de rapports avec des requêtes de longue durée). En tant que DBA, vous devez peser le pour et le contre de l'activation de cette option et déterminer ce qui convient le mieux à votre base de données. Notez que si vous exécutez SQL Server 2008 à 2012, une fuite de mémoire est associée à ce paramètre. Microsoft propose des mises à jour cumulatives qui fournissent un correctif, mais si vous ne les avez pas déjà appliquées, vous êtes confronté à une autre décision :appliquez le CU pour pouvoir activer l'option, ou n'appliquez pas le CU et n'activez pas le option.

Résumé

Le seul moyen de savoir si les mises à jour automatiques des statistiques affectent les performances des requêtes est soit de voir une mise à jour se produire en même temps qu'un problème, soit de capturer le moment où des mises à jour se produisent et de corréler les données aux informations supplémentaires que vous capturez sur les problèmes de performances. Cette dernière option vous permet d'être proactif - même si vous ne rencontrez pas de problèmes de performances, il peut être judicieux de savoir à quelle fréquence les mises à jour automatiques se produisent. Des mises à jour fréquentes peuvent signifier que vous devez revoir le travail de l'agent qui gère manuellement les statistiques. En général, laissez l'option de mise à jour automatique des statistiques activée, mais ayez une méthode pour gérer les statistiques et utilisez l'option comme filet de sécurité.