Discussion :

[lmalta]

Bonjour,

J'ai une requête dans un applicatif qui est devenue depuis aujourd'hui trés lente (38s).
Les indexes sont reorganisés chaque WE.
Lorsque que je la lance via l'analyseur de requête sont plan d'execution est abérant (alors que ce n'était pas le cas avant)

lorsque je la lance plusieurs fois de suite pas de changement (le cache n'y change rien)

lorsque je la lance avec l'option FORCE ORDER elle reprends le bon plan d'éxécution et est instantanée.

Lorsque j'intégre cette requête (sans FORCE ORDER ) dans une procs stock elle reprends le bon plan d'éxécution et est instantanée.

Les indexes ne sont pas fragmentés et les tables sont de faible fragmentation (table de travail)
Mais alors pourquoi le plan n'est pas le même en fonction de la méthode (sous procédure stockée ou pas sous procédure stockée).

PS : je suis sous SQL 7.0

Merci

[SQLpro]

sans le code difficile de voir.
Quelle méthode de defrag utilisez vous pour vos index ? Car cela peut être un problème de stat non à jour.
Une procédure est plus persistante en cache pour l'ensemble des objets qui y figure, y compris plan de requête.

A +

[lmalta]

Bonjour,

Ok pour le cache sur les procédures, je ne savai pas.

Chaque WE à lieu un DBCC DBREINDEX.
Les stats sont à jour.

Je comprends bien que sans le code ...,mais il fait parti d'un module trés sensible dont je ne peux diffuser sur la toile.
Globalement c'est une vielle requête (sans inner join et avec un *=) en jointure sur 10 tables avec deux paramétres de date de passés.

Donc la procédure en fait de même.
Ce qui explique que je ne comprenne pas qu'elle ne prenne pas le même plan d'execution.

J'ai donc fait évoluer l'appli pour qu'elle utilise la procs et j'en ai profité pour reconditionner la requête.
Je continu à chercher car aujourd'hui la requête reprends le bon plan d'execution, alors que là il n'y a pas de nouveau defrag !!!

Merci quand même.

A +