Comprendre les statistiques, les plans d'exécution et le «problème clé croissant»

J'essaie de mieux comprendre (conceptuellement) la relation entre les statistiques, les plans d'exécution, l'exécution des procédures stockées.

Ai-je raison de dire que les statistiques ne sont utilisées que lors de la création du plan d'exécution d'une procédure stockée et qu'elles ne sont pas utilisées dans le contexte d'exécution réel? En d'autres termes, si cela est vrai, une fois le plan créé (et en supposant qu'il est correctement réutilisé), quelle est l'importance des statistiques "à jour"?

J'ai été particulièrement motivé par un article que j'ai lu ( Statistiques, estimations de lignes et colonne de date ascendante ) qui décrit un scénario très similaire à celui auquel je suis confronté quotidiennement avec plusieurs bases de données de nos clients.

Nous avons une colonne de date / heure ascendante dans l'une de nos plus grandes tables que nous interrogeons régulièrement à l'aide d'une procédure stockée spécifique.

Comment empêchez-vous les plans d'exécution de devenir obsolètes lorsque vous avez cent mille lignes ajoutées par jour?

Si nous mettons fréquemment à jour les statistiques pour lutter contre ce problème, serait-il judicieux d'utiliser l'indication OPTION (RECOMPILE) sur la requête de cette procédure stockée?

Tout conseil ou recommandation serait apprécié.

Mise à jour : j'utilise SQL Server 2012 (SP1).

Ai-je raison de dire que les statistiques ne sont utilisées que lors de la création du plan d'exécution d'une procédure stockée et qu'elles ne sont pas utilisées dans le contexte d'exécution réel?

Non, ce qui se passe, c'est que le plan d'exécution d'une procédure stockée est mis en cache. En supposant qu'il y ait suffisamment de mémoire disponible pour continuer à conserver le plan, il ne changera pas à moins que l'un des événements suivants se produise (à partir de la mise en cache et de la réutilisation du plan d'exécution dans la documentation SQL Server, soulignement ajouté):

• Modifications apportées à une table ou à une vue référencée par la requête (ALTER TABLE et ALTER VIEW).
• Modifications apportées à une seule procédure, ce qui supprimerait tous les plans de cette procédure du cache (ALTER PROCEDURE).
• Modifications de tous les index utilisés par le plan d'exécution.
• Mises à jour des statistiques utilisées par le plan d'exécution, générées soit explicitement à partir d'une instruction, comme UPDATE STATISTICS, soit générées automatiquement.
• Suppression d'un index utilisé par le plan d'exécution.
• Un appel explicite à sp_recompile.
• Grand nombre de modifications apportées aux clés (générées par les instructions INSERT ou DELETE d'autres utilisateurs qui modifient une table référencée par la requête).
• Pour les tables avec déclencheurs, si le nombre de lignes dans les tables insérées ou supprimées augmente considérablement.
• Exécution d'une procédure stockée à l'aide de l'option WITH RECOMPILE.

Donc, si les statistiques sont mises à jour, le plan mis en cache prendra automatiquement en compte les nouvelles statistiques et sera recompilé.

Comment empêchez-vous les plans d'exécution de devenir obsolètes lorsque vous avez cent mille lignes ajoutées par jour?

Une façon est s'il y a beaucoup de mises à jour du tableau, comme mentionné ci-dessus. Quelques centaines de milliers de lignes modifiées peuvent satisfaire à cette condition. Mais si vous voulez être sûr ou avoir un contrôle plus précis: en mettant à jour vos statistiques. Vous pouvez autoriser SQL Server à créer et à gérer automatiquement des statistiques, ou à le faire manuellement vous-même. Vous pouvez trouver plus d'informations sur les deux méthodes dans les options de mise à jour automatique de SQL Server et de création automatique de statistiques . Lorsque / si vous effectuez une reconstruction hebdomadaire des index, cela déclenchera également la mise à jour des plans. Faites des tests pour voir ce qui vous est le plus avantageux, car la mise à jour trop fréquente des statistiques peut ne pas produire de résultats de performances réels.

Si nous mettons fréquemment à jour les statistiques pour lutter contre ce problème, serait-il judicieux d'utiliser l'indication OPTION (RECOMPILE) sur la requête de cette procédure stockée?

Vous n'avez pas besoin d'utiliser RECOMPILE, car sur la base de l'extrait ci-dessus, vous pouvez voir que le plan d'exécution est mis à jour de manière appropriée chaque fois que de nouvelles statistiques sont disponibles. Vous pouvez être d'accord avec une mise à jour des statistiques de fin de journée (si vous êtes vraiment inquiet), mais je ne pense pas que ce soit explicitement un besoin basé sur ce que vous avez dit jusqu'à présent. Encore une fois, cependant, je le testerais pour voir quel impact cela pourrait avoir sur les performances de votre procédure stockée et planifier en conséquence.

Ai-je raison de dire que les statistiques ne sont utilisées que lors de la création du plan d'exécution

Non, les statistiques obsolètes peuvent entraîner une recompilation liée à l'optimalité de l'instruction affectée.

Nous avons une colonne date / heure ascendante dans l'un de nos plus grands tableaux que nous interrogeons régulièrement

Les plans d'exécution sous-optimaux causés par des valeurs de prédicat en dehors (spécifiquement au-dessus) de la plage de valeurs stockées dans l'histogramme statistique correspondant est connu sous le nom de problème de clé ascendante . La reconstruction des statistiques est une solution possible, mais elle peut être très gourmande en ressources. Les alternatives incluent:

• Indicateurs de trace 2389 et 2390 . Cela nécessite qu'un index existe avec la colonne problématique comme clé principale. Il ne fonctionne pas avec les tables partitionnées et n'est efficace dans SQL Server 2014 que si l'estimateur de cardinalité d'origine est utilisé. L'indicateur de trace 4139 peut également être requis si l'objet statistique est marqué comme stationnaire.

• Mise à niveau vers SQL Server 2014. Le nouvel estimateur de cardinalité inclut une logique pour estimer au-delà de l'histogramme à l'aide des informations de densité moyenne. Cela peut être moins précis que les indicateurs de trace 2389/2390 dans certaines circonstances importantes.

• Activez des mises à jour automatiques des statistiques plus fréquentes pour les grandes tables avec l' indicateur de trace 2371 . Avec cet indicateur de trace, au lieu de mettre à jour après 20% + 500 changements, seules les SQRT(1000 * Table rows)modifications sont requises. Ce n'est pas une solution aussi complète que celles mentionnées précédemment, car les mises à jour peuvent ne pas être déclenchées assez souvent.

Si la source de votre problème n'est pas tant des compilations de plans fréquentes basées sur des valeurs de prédicat au-delà de l'histogramme, mais davantage sur les effets de la mise en cache occasionnelle d'un tel mauvais plan à la suite d'un reniflage de paramètres, vous pouvez également envisager:

• Désactivation du reniflage de paramètres à l'aide de l' indicateur de trace 4136
• Utilisation OPTIMIZE FOR (@parameter = value)pour compiler un plan pour une valeur représentative connue
• Utiliser OPTIMIZE FOR (@parameter UNKNOWN)pour optimiser en utilisant la distribution moyenne
• Utilisation OPTIMIZE FOR UNKNOWN(identique à 4136, mais par requête)
• Utiliser OPTION (RECOMPILE)pour compiler à chaque fois, renifler la valeur particulière. Si la grande majorité des valeurs d'exécution se trouvent dans l'histogramme, cela peut être efficace.

Pour plus d'informations sur le reniflage de paramètres, l'incorporation et les options de recompilation, consultez mon article sur SQLperformance.com.