Mauvaise performance des requêtes

10

Nous avons une grande procédure (10 000+ lignes) qui s'exécute généralement en 0,5 à 6,0 secondes selon la quantité de données avec laquelle elle doit travailler. Au cours du mois dernier, il a commencé à prendre plus de 30 secondes après une mise à jour des statistiques avec FULLSCAN. Lorsqu'il ralentit, un sp_recompile "résout" le problème, jusqu'à ce que le travail de statistiques nocturnes s'exécute à nouveau.

En comparant les plans d'exécution lente et rapide, je l'ai réduit à une table / un index spécifique. Lorsqu'il s'exécute lentement, il estime que ~ 300 lignes seront renvoyées à partir d'un index spécifique, lorsqu'il s'exécute rapidement, il estime 1 ligne. Lorsqu'il s'exécute lentement, il utilise une table spool après avoir effectué une recherche sur l'index, lorsqu'il s'exécute rapidement, il ne fait pas la table spool.

En utilisant DBSS SHOW_STATISTICS, j'ai tracé graphiquement l'histogramme d'index dans Excel. Je m'attendrais normalement à ce que le graphique soit plus "vallonné", mais à la place, il ressemble à une montagne, le point le plus élevé étant 2x-3x plus élevé que la plupart des autres valeurs du graphique.

Histogramme d'index

Si je mets à jour des statistiques dessus, sans FULLSCAN, cela semble plus normal. Si je l'exécute à nouveau avec FULLSCAN, cela ressemble à ce que j'ai décrit ci-dessus.

Cela ressemble à un problème de reniflement de paramètres, et spécifiquement lié à la distribution d'index (apparemment) étrange ci-dessus.

Le proc prend un paramètre de valeur de table, un reniflement de paramètre peut-il se produire sur un paramètre de valeur de table?

EDIT: Le proc prend également 12 autres paramètres, dont certains sont facultatifs, dont deux sont une date de début et de fin.

L'histogramme est-il étrange ou aboie-t-il le mauvais arbre?

Je suis certainement à l'aise pour essayer d'ajuster la requête et / ou d'essayer d'ajuster mon indexation. Si c'est le correctif qui est génial, à ce stade, ma question concerne davantage l'histogramme asymétrique.

Je dois mentionner qu'il s'agit d'un index cluster PK IDENTITY. Nous avons deux systèmes qui se parlent, un système hérité, un nouveau système local. Les deux systèmes stockent des données similaires. Pour les garder synchronisés, le PK sur cette table dans le nouveau système est incrémenté lorsque des éléments sont ajoutés à l'ancien système, même si les données ne sont pas transmises (un RESEED est effectué). Il pourrait donc y avoir des lacunes dans la numérotation dans cette colonne. Les enregistrements sont rarement, voire jamais, supprimés.

Toute réflexion serait grandement appréciée. Je suis plus qu'heureux de recueillir / inclure plus d'informations.

Mark Wilkinson
la source
Le seul paramètre de la procédure est-il un TVP ou existe-t-il également d'autres paramètres?
Martin Smith
1
Si vous regardez un plan XML lent et rapide, la différence serait-elle explicable par différents ParameterCompiledValuepour ces autres paramètres?
Martin Smith
1
La plage de dates avec laquelle il a été compilé est considérablement plus étroite (5 jours au lieu de 31). Pour la majorité des appels, ce processus durera un mois. Je pourrais essayer d'ajouter un indice de recompilation à cette déclaration spécifique.
Mark Wilkinson
1
Cela semble définitivement être une distribution étrange pour une colonne d'identité. Je viens de lire cet article et je me demandais si vous pouviez élaborer sur ce que vous voyez pour une estimation par rapport à une réalité sur ces deux plans. > blogs.technet.com/b/mspfe/archive/2013/04/18/…
Richard Schweiger
1
Juste pour être clair: quel est exactement le graphique? RANGE_HI_KEYsur l'axe des X probablement, mais qu'est-ce que sur l'axe des Y? EQ_ROWS? RANGE_ROWS? La somme de ceux-ci?
Paul White 9

Réponses:

3

Cela a fini par être lié au reniflage des paramètres. Il se trouve que certaines versions étrangement formées de cette requête ont été exécutées juste après la reconstruction des statistiques. Le plan mis en cache n'était donc pas représentatif de la majorité des appels. J'ai utilisé l'astuce de copier les paramètres de date dans des variables locales et cela fonctionne très bien, avec peu ou pas d'impact sur les performances. Cela ne répond pas à la raison pour laquelle l'histogramme semble si "désactivé", mais cela explique mes problèmes de performances.

Mark Wilkinson
la source