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

MISES À JOUR des statistiques

Les dernières versions de SQL Server ont introduit une multitude de nouvelles fonctionnalités, ainsi que des améliorations dans les fonctionnalités existantes. Un domaine du moteur qui est facile à négliger est celui des statistiques. Après tout, les statistiques sont toujours créées de la même manière, elles vous renseignent toujours sur la distribution des données, elles sont toujours utilisées par l'optimiseur de requête... qu'est-ce qui est différent ? La fonction de base des statistiques reste la même, mais la façon dont elles sont utilisées par l'optimiseur de requête change en fonction de l'estimateur de cardinalité que vous utilisez. Il existe également plusieurs changements notables liés à la mise à jour des statistiques et de nouvelles fonctionnalités ont été ajoutées autour de l'affichage des informations statistiques. Dans l'ensemble, ces changements dans les dernières versions peuvent entraîner une variation du comportement de SQL Server à laquelle vous ne vous attendiez pas.

Remarque :Ce message s'applique principalement à SQL Server 2012 et versions ultérieures, mais certains détails concernant les versions précédentes sont inclus à titre de référence (et pour le plaisir).

SQL Server 7.0

  • Le nombre d'étapes dans un histogramme est limité à 300. Dans SQL Server 6.5 et les versions antérieures, un histogramme aurait le nombre d'étapes pouvant tenir sur une page de 2 Ko, en fonction de la taille de la première colonne de la clé.
  • L'option de base de données "mettre à jour automatiquement les statistiques" est introduite ; auparavant, les statistiques n'étaient mises à jour que manuellement.

SQL Server 2000

  • Le nombre d'étapes dans l'histogramme est réduit de 300 à 200 (techniquement 201, si vous incluez l'étape pour NULL, en supposant que la première colonne de la clé autorise les valeurs NULL).

SQL Server 2005

  • Les mises à jour des statistiques qui utilisent FULLSCAN peuvent s'exécuter en parallèle.
  • Les indicateurs de suivi 2389 et 2390 ont été introduits dans le SP1 pour résoudre le problème de clé croissante, décrit dans l'article Clés croissantes et statistiques de correction rapide automatique. Un exemple détaillé de ce scénario est fourni dans mon article Trace Flag 2389 et le nouvel estimateur de cardinalité.
  • L'option d'instance "Mettre automatiquement à jour les statistiques de manière asynchrone" est introduite. Notez que pour que cela soit effectif, l'option "Mettre à jour automatiquement les statistiques" doit également être activée. Si vous ne savez pas exactement ce que fait cette option, consultez la documentation dans Options ALTER DATABASE SET. C'est un paramètre que Glenn recommande (comme indiqué dans son article référencé ci-dessous), mais je pense qu'il est important d'être conscient des problèmes potentiels, comme indiqué dans Comment les mises à jour automatiques des statistiques peuvent affecter les performances des requêtes.

    Remarque : Il existe une fuite de mémoire liée à ce paramètre dans SQL Server 2008 à SQL Server 2012; veuillez consulter le message de Glenn Important Hotfix for SQL Server 2008 pour plus de détails.

SQL Server 2008

  • Des statistiques filtrées sont introduites, et celles-ci peuvent être créées séparément d'un index filtré. Il existe certaines limitations autour des index filtrés en ce qui concerne l'optimiseur de requête (voir le post de Tim Chapman The Pains of Filtered Indexes et le post de Paul White Optimizer Limitations with Filtered Indexes), et il est important de comprendre le comportement du compteur qui suit les modifications (et peut donc déclencher des mises à jour automatiques). Voir le post de Kimberly Les index filtrés et les statistiques filtrées pourraient devenir sérieusement obsolètes pour plus de détails, et je recommande également de consulter sa procédure stockée qui analyse le biais des données et recommande où vous pouvez créer des statistiques filtrées pour fournir plus d'informations à l'optimiseur de requête. J'ai implémenté cela pour plusieurs gros clients qui ont des ALV et une distribution asymétrique dans les colonnes fréquemment utilisées dans les prédicats.
  • Deux nouvelles vues de catalogue, sys.stats et sys.stats_columns, ont été ajoutées pour fournir un aperçu plus simple des statistiques et des colonnes incluses. Utilisez ces deux vues au lieu de sp_helpstats, qui est obsolète et fournit moins d'informations.

SQL Server 2008R2 SP1

  • Trace Flag 2371 est mis à disposition, ce qui peut être utilisé pour réduire le nombre de modifications requises pour que les mises à jour automatiques des statistiques se produisent. Pour rappel, je suis fan de la mise à jour régulière des statistiques via une tâche planifiée et de l'activation de la mise à jour automatique par mesure de sécurité.

SQL Server 2008R2 SP2

  • La fonction sys.dm_db_stats_properties est incluse, qui fournit les mêmes informations que celles trouvées dans l'en-tête de DBCC SHOW_STATISTICS, ainsi qu'une colonne de modification qui pourrait être utilisée pour suivre les modifications et déterminer par programmation si une mise à jour était nécessaire. Vous souvenez-vous de ma préférence pour l'utilisation d'un travail pour mettre à jour les statistiques ? Ce travail est devenu beaucoup plus intelligent avec ce DMF… maintenant je peux voir combien de données ont été modifiées et mettre à jour les statistiques UNIQUEMENT si un certain pourcentage de données a changé. Lisse.

SQL Server 2012

  • La mise à jour des statistiques n'entraînera pas l'invalidation des plans SI aucune ligne n'a été modifiée. C'est celui qui surprend beaucoup de gens, et Kimberly a un post amusant, Qu'est-ce qui a fait que ce plan a horriblement mal tourné - devriez-vous mettre à jour les statistiques ?, qui parcourt son aventure pour comprendre cela.

SQL Server 2012 SP1

  • DBCC SHOW_STATISTICS ne nécessite que l'autorisation SELECT. Auparavant, il fallait qu'un utilisateur soit membre de sysadmin ou membre du rôle de base de données db_owner ou db_ddladmin. Cela peut être globalement désactivé avec l'indicateur de trace 9485.
  • Inclut sys.dm_db_stats_properties (voir la note 2008R2 SP2 ci-dessus)

SQL Server 2012 SP2

  • La mise à jour cumulative 1 introduit un correctif lié au fait que les clés ascendantes ne sont pas correctement identifiées, même avec les indicateurs de trace 2389 et 2390 en cours d'utilisation. Cela nécessite l'indicateur de trace 4139 en plus de CU1, comme indiqué dans KB 2952101.

SQL Server 2014

  • Le nouvel estimateur de cardinalité est introduit, implémenté en définissant le mode de compatibilité de la base de données sur 120, ou en utilisant l'indicateur de trace 2312. Si vous n'avez rien lu sur le nouveau CE, je vous recommande de commencer par la documentation Estimation de cardinalité, puis de lire Joe Livre blanc de Sack, Optimisation de vos plans de requête avec l'estimateur de cardinalité SQL Server 2014, pour des détails approfondis.
  • Le comportement des indicateurs de suivi 2389 et 2390 pour les clés croissantes est désormais implémenté via le mode de compatibilité de la base de données. Si le mode de compatibilité de vos bases de données est défini sur 120 (ou supérieur dans les versions ultérieures), vous n'avez pas besoin d'utiliser les indicateurs de trace 2389 et 2390 pour SQL Server pour identifier les statistiques qui ont des clés croissantes.
  • Des statistiques incrémentielles sont introduites pour les partitions et peuvent être consultées via le nouveau DMF sys.dm_db_incremental_stats_properties. Les statistiques incrémentielles permettent de mettre à jour les statistiques d'une partition sans les mettre à jour pour la table entière. Toutefois, les informations statistiques supplémentaires provenant des statistiques incrémentielles ne sont pas utilisées par l'optimiseur de requête, mais elles sont intégrées dans l'histogramme principal de la table.
  • CU2 inclut le même correctif mentionné ci-dessus pour SQL Server 2012 SP2 qui nécessite également l'indicateur de trace 4139.

SQL Server 2014 SP1

  • L'indicateur de trace 7471 est rétroporté vers CU6, initialement disponible dans SQL Server 2016, comme indiqué ci-dessous.

SQL Server 2016

  • L'indicateur de trace 2371 n'est plus nécessaire pour réduire le seuil des mises à jour automatiques des statistiques si le mode de compatibilité de la base de données est défini sur 130. Consultez Contrôle du comportement d'Autostat (AUTO_UPDATE_STATISTICS) dans SQL Server.
  • Les mises à jour des statistiques peuvent s'exécuter en parallèle lors de l'utilisation de SAMPLE, et pas seulement de FULLSCAN. Ceci est lié au mode de compatibilité (doit être 130), mais peut potentiellement fournir des mises à jour plus rapides et ainsi réduire les fenêtres de maintenance. Aaron Bertrand parle de cette amélioration dans son article, Une amélioration potentielle pour les mises à jour des statistiques :MAXDOP.
  • L'indicateur de trace 7471 est introduit dans CU1 pour permettre à plusieurs commandes UPDATE STATISTICS de s'exécuter simultanément pour une seule table et Jonathan fournit d'excellents exemples de la façon dont cela peut être utilisé dans son article Prise en charge améliorée des reconstructions de statistiques parallèles.

SQL Server 2016 SP1

  • L'option d'indicateur de requête ENABLE_HIST_AMENDMENT_FOR_ASC_KEYS est introduite, ainsi que l'argument FOR HINT, qui est l'équivalent de l'indicateur de trace 4139.
  • Le DMF sys.dm_db_stats_histogram est exposé dans CU2, qui est une alternative à la sortie d'histogramme de DBCC SHOW_STATISTICS. Les informations dans les deux sont les mêmes, utilisez ce qui est plus facile pour vous ou correspond mieux au problème que vous devez résoudre.
  • L'option PERSIST_SAMPLE_PERCENT est introduite dans CU4, qui peut être utilisée pour forcer l'utilisation du même taux d'échantillonnage à chaque fois qu'une statistique est mise à jour, et des exemples de ce comportement peuvent être trouvés dans l'article, Taux d'échantillonnage des statistiques persistantes.

SQL Server 2017

  • L'option PERSIST_SAMPLE_PERCENT est disponible dans CU1 (voir l'entrée 2016 SP1 pour plus d'informations).
  • Les attributs StatsInfoType et OptimizerStatsUsageType sont ajoutés au plan de requête, qui répertorie les statistiques utilisées lors de l'optimisation de la requête. Ceci est disponible dans CU3 et est lié à la version CE (120 et supérieure). C'est plutôt cool ! Je n'ai pas encore eu l'occasion de jouer avec cela, mais pour obtenir ces informations auparavant, vous deviez utiliser des indicateurs de trace non documentés.
  • CU3 a également introduit l'option MAXDOP pour CREATE STATISTICS et UPDATE STATISTICS, qui peut être utilisée pour remplacer la valeur MAXDOP pour l'instance ou la base de données.
  • Un autre ajout dans CU3 :les attributs UdfCpuTime et UdfElapsedTime se trouvent dans le plan de requête, qui représentent les statistiques d'exécution pour les UDF à valeur scalaire.

Résumé

Si vous souhaitez effectuer une mise à niveau vers une version plus récente ou si vous avez récemment mis à niveau, notez l'impact de ces modifications sur votre solution. De nombreux clients nous ont contactés après la mise à niveau de 2005/2008/2008R2 vers 2014 ou 2016, se plaignant de problèmes de performances. Dans de nombreux cas, des tests adéquats n'ont pas été effectués avant la mise à niveau.

C'est quelque chose sur lequel nous nous concentrons vraiment lorsque nous aidons un client à se mettre à niveau. Au-delà des étapes pour déplacer une instance de production d'une version à une autre avec peu de temps d'arrêt, nous voulons nous assurer que le lendemain de la mise à niveau est ennuyeux pour les DBA et les développeurs.

Nous ne testons pas simplement le processus de mise à niveau, nous testons à quoi ressemble le système après la mise à niveau. Les mêmes indicateurs de trace de l'ancien environnement sont-ils nécessaires dans le nouveau ? Quels paramètres de base de données doivent être ajustés ? Les performances des requêtes changent-elles, pour le meilleur ou pour le pire ? Si vous ne connaissez pas les réponses à ces questions avant de mettre à niveau la production, vous vous préparez pour un à plusieurs jours de lutte contre les incendies, les appels de Sev 1, les repas à votre bureau, le manque de sommeil et qui sait quoi d'autre .

Prenez le temps de comprendre l'impact des nouvelles fonctionnalités et des modifications apportées aux fonctionnalités répertoriées ci-dessus, planifiez la mise à niveau et testez autant que possible.