Discussion :

[joujousagem2006]

bonjour a tous
Pour un de mes serveur du production j'ai un doute que les plans d'exécution ne sont pas optimales pour tous les appels vers ces SP
donc comment je peut détecter ou tracer ce phénomène?
Exit t'il une méthode avec trace du profiler ou avec les évenement étendu ?
aussi dans quel cas j'aurai ce phénomène ?
l'absence du mis a jour de statistique du façon régulier entraîne t'il l'apparition de ce phénomène
pour Réparer le Paramètre Sniffing est ce quel la seul solution c'est toujours d'ajouter

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

with recomplie

j'ai écouter que l’utilisation de cette option entraîne une cons somation énorme de ressources CPU
je cherche une solution optimale
merci pour vos aide

[SQLpro]

Il y a beaucoup de choses à faire en ce domaine.

L'essentiel ayant été résumé ici : http://blog.developpez.com/sqlpro/p9...ns_de_requetes

A +

[elsuket]

Bonjour,

l'absence du mis a jour de statistique du façon régulier entraîne t'il l'apparition de ce phénomène ?

Si les options de création et de mise à jour automatique des statistiques sont positionnées à ON, ce qui est le cas par défaut, cela peut encore arriver.
L'idéal est d'avoir un job qui met à jour les statistiques dont la valeur du compteur de modifications excède le nombre de lignes de la table multiplié par le seul de recalcul de la statistique (500 + 20% * nombres de lignes de la table).

donc comment je peut détecter ou tracer ce phénomène?
Exit t'il une méthode avec trace du profiler ou avec les évenement étendu ?

Effectivement à l'aide de SQLProfiler ou des événements étendus (voir notamment les chapitres 14, 17 et 19 du livre référencé dans ma signature), on peut tracer les requêtes les plus gourmandes en ressources (CPU, Reads, Writes, Duration, RowCounts si vous le faites avec SQLProfiler).

aussi dans quel cas j'aurai ce phénomène ?

Lorsqu'au moins une des valeurs avec lesquelles le plan de la requête s'est compilé n'était pas dans l'histogramme de la statistique sous-jacente ET que cela a entraîné un défaut d'estimation de cardinalité. C'est une situation est assez rare. En d'autres termes, il est important de bien comprendre pourquoi le plan est sous-performant, et c'est rarement à cause d'un problème de reniflage des valeurs des paramètres.

pour Réparer le Paramètre Sniffing est ce quel la seul solution c'est toujours d'ajouter WITH (RECOMPILE)

Heureusement, non. En effet la compilation (et donc la recompilation) est un processus coûteux en CPU.
Si la procédure stockée, ou une requête de cette procédure stockée est exécutée fréquemment, vous observerez donc une utilisation CPU élevée.
L'alternative est d'aider l'optimiseur en lui précisant de ne pas tenir compte de la valeur pour un ou tous les paramètres : respectivement OPTION (OPTIMIZE FOR (@param UNKNOWN | = constante)) et OPTION (OPTIMIZE FOR UNKNOWN). Le plan étant mis en cache, toutes les exécutions subséquentes à sa compilation utiliseront cet indicateur; il est donc important de bien tester, et de revalider de temps en temps.

je cherche une solution optimale

Seule l'étude méticuleuse de plan de requête, et, le cas échéant, de la statistique sous-jacente, pourra vous aider dans ce sens.
Encore une fois, les problèmes de reniflage de valeurs de paramètres à la compilation sont rares
Cet ouvrage gratuit peut vous aider dans ce sens

@++

[joujousagem2006]

cela me fait plaisir de vous me donner ces explications détailler

merci bien