Discussion :

[zoltar35]

Bonjour,

J'ai des procédures stockées pour effectuer des statistiques sur des tables assez importantes.

Lorsque j'execute une procédure avec des parametres elle mets 2 minutes pour s'executer.

Je declare localement les mêmes variables que les parametres (avec un autre nom) et affecte leur valeur avec les parametres de la sp.

L'execution dure 2 secondes!!!

Qu'elle est la différence de gestion au sein du moteur de SQL Server qui génère une t'elle différence de traitement?

Merci de votre aide.

[iberserk]

que donne cette même procédure stockée avec vidage du cache au préalable? (DBCC freeproccache)?

[zoltar35]

J'ai regardé sur l'aide SQL Server concernant cette commande mais je n'arrive pas à récupérer le plan_handle à l'aide de cette commande

Code :

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

1
2
3
4
SELECT plan_handle, st.text
FROM sys.dm_exec_cached_plans 
CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS st
WHERE text LIKE N'SELECT * FROM MaStoredProc%'

Merci de votre aide

[mikedavem]

Qu'elle est la différence de gestion au sein du moteur de SQL Server qui génère une t'elle différence de traitement?

De loin cela ressemble fortement à un problème de parameter sniffing.
En utilisant des variables locales internes à la procédure le comportement de l'optimiseur est différent vis-à-vis des statistiques qu'il utilise pour les objets sous-jacents.

En forçant l'utilisation des variables locales dans la procédure l'optimiseur ne voit plus la valeur de celles-ci dans la procédure au moment de la compilation mais seulement lors de l'exécution de la procédure. Par conséquent l'optimiseur n'utilise plus l'histogramme de statistiques de chaque objet concerné par la procédure mais les informations de densité globale. On a un plan d'exécution globale pour n'importe quelle valeur de paramètre.

++

[zoltar35]

Merci pour cette réponse qui me permet de comprendre ce comportement particulier.

La était bien le but de ma question

++