ASE 12.5.3 : Pb de cache ?

Bonjour

J'ai un "probleme de perf" sur une vue
En effet, je fais un 'select * from ma_vue' directement, cela prend 30 s
Par un ps avec le meme code, elle prend environ 10 secondes
Cela vient certainement du plan d'excution deja calculé dans le cache pour la ps mais je croyais que le plan etait en cache pour une vue aussi

Si qq'un a une explication plus rationnelle


Pour info, voici le resultat du 'statistics io,time on' :
Parse and Compile Time 325.
SQL Server cpu time: 32500 ms.

Execution Time 50.
SQL Server cpu time: 5000 ms. SQL Server elapsed time: 10750 ms.

(3107 rows affected)



NB : la vue fais une jointure sur une 20aine de tables


Merci d'avance de vos remarques / aide

jeeps64

Idéalement il faudrait voir le SHOWPLAN des deux exécutions pour voir quelle est la différence.

Est-ce que les jointures dans la vue sont strictement identique à celles dans la proc stockée ?

Michael

Bonjour

Les 2 plans sont identiques, la requete dans la ps etant le 'select * from ma_vue'
J'avoue que je seche la
La seule difference vient du temps passer à parser et à compiler

le select :
Parse and Compile Time 328.
SQL Server cpu time: 32800 ms.
The sort for Worktable1 is done in Serial

la ps :
Parse and Compile Time 1.
SQL Server cpu time: 100 ms.
The sort for Worktable1 is done in Serial


Si vous avez un piste, n'hesitez pas

Merci

jeeps64

Le plan de la vue n'est pas pré-compilé, d'où les 3 secondes à faire la compilation et l'optimisation du plan d'accès à chaque exécution.

Tu pourrais invéstiguer l'utilisation d'un plan abstrait pour stocker le plan d'accès et ainsi éviter la longue optimisation à chaque exécution.

Michael

Je croyais que le plan d'une vue était pré-compilé comme une ps
Je vais travailler sur un abstract plan alors

Merci des reponses Michael

@+

Juste un petit conseil pour finir sur ce sujet

J'ai créé une proxy_table 'ma_vue_proxy' pointant vers la procedure stockée et la evidemment ca fonctionne et c'est aussi rapise que le lancement de la ps seule.

Y a t il une contre indication a faire ce genre de chose ? ou des effets pervers ?


Merci d'avance


jeeps64

Je n'avais pas pensé à utiliser une table proxy pour ceci, mais cela devrait effectivement marcher assez bien. Il y aura plus d'IO réseau, mais comme c'est sur le "loopback" cela ne devrait pas poser de problème. Et comme je suppose que cette vue n'est pas utilisée en jointure avec d'autres tables/vues il ne doit pas y avoir de problème de perfs particulières.

Ceci étant, si tu as le temps il vaut peut-être la peine d'investiguer les "abstract query plans". Si mes souvenirs sont bons on peut sauver le plan d'une requête en l'exécutant, puis forcer ce plan à être exécuté.

Michael

Salut

Pour l'instant, je vais rester sur cette idée je pense (faute de temps)
Pour les abstract plan, j'arrive à enregistrer le plan du 'select * from ma_vue' dans un groupe de plan.
Par contre, pour obliger la requete 'select * from ma_vue' a prendre l'abstract plan ainsi enregistré, je n'ai trouver que cette syntaxe :

set plan load mon_grp_plans on
go
select * from ma_vue
go
set plan load off
go


J'aurai voulu pour forcer le plan directement a l'appel du select. Mais je ne pense pas que ce soit possible.
Sauf en l'ecrivant a la main. Mais sur une jointure entre une vingtaine de tables...bonjour le plan !!!


Merci en tout cas de toutes ces reponses


jeeps64