Discussion :

[jvenambre]

Bonjour,

Je travaille actuellement sur un projet vb.net 2005 avec une base SQL Server 2005 Express.

J'ai constaté que toutes mes requêtes étaient systématiquement longues à éxécuter au premier lancement et beaucoup plus rapide les fois suivantes (durant la même exécution de l'application). 3 à 4 fois plus rapide, aussi bien sur des requêtes complexes style Select avec de très nombreuses jointures que sur des requêtes simples d'insert ou d'update...

Après recherche, j'ai appris qu'à chaque exécution d'une requête, SqlServer effectuait un travail de statistique pour réaliser le meilleur plan d'exécution possible.

D'où le titre de ce sujet, Y-t-il un moyen de prémacher ce travail de préparation des plans d'exécution ? Pourquoi d'une exécution de l'application à une autre, ce travail est-il systématiquement refait ? Les requêtes sont souvent les même, pourquoi refait-il ce travail ?

Y-t-il d'autres optimisations ou paramétrage de base auxquels je n'aurais pas pensé ? outre la création d'index sur les clés primaires et les clé étrangères...

Merci d'avance

Johann

[ylarvor]

Il existe différentes techniques d'optimisation... Il existe la possibilité d'indiquer le plan d'execution d'une requete mais c'est assez complexe à mettre en oeuvre... J'ai vu ca sur une video microsoft...

Le plus simple, c'est d'écrire tes requêtes dans des procédures stockées pour profiter du cache de procédure stockée. Il est conservé tant que tu ne redémarre pas ton serveur et qu'il reste de la mémoire disponible.

[jvenambre]

Merci pour ta réponse...

J'utilise déjà quasi-exclusivement les procédures stockées pour la majorité de mes accès à la base... Et c'est là que je ne comprend pas pourquoi les plans d'exécution sont systématiquement remis en question à chaque exécution (Et pas uniquement à chaque reset du Sql Server)... Une proc stock est justement prédéfinie et cloisonnée pour que son exécution soit toujours effectué de la même façon...

Dans mon appli, j'ai en l'occurrence une prise de commande avec saisie de quantités... A chaque saisie, j'effectue un Insert (encapsulé dans une proc stock) automatique dans la base... La première saisie prend 2 à 3 secondes alors que les suivantes sont réalisées en moins de 200 millisecondes...

Par ailleurs, j'ai aussi quelques requêtes de recherche qui ne sont pas encapsulées dans des proc stock parce que les jointures ne sont pas toujours les mêmes en fonction des critères et que la longueur des critères pourrait dépasser la capacité d'un paramètre varchar de proc stock... Et là, le phénomène est encore plus flagrant... plus de 10 secondes au premier lancement, moins de 2 secondes aux suivants...

peux-tu me spécifier les sources dont tu me parles quant à la possibilité d'indiquer le plan d'exécution d'une requête ?!

D'autres idée ?

Merci encore

[SQLpro]

Les temps de réponse que vous observez ne sont absolument pas lié à des problématique de plan de requête mais simplement au cache des données. En effet un SGBDR travaille exclusivement en mémoire (RAM). Lors de la première requête il faut donc charger les données en mémoire. Une fois chargées ces données persistent en mémoire tant qu'il y a de la RAM (SQL Server la mange toute).
Pour vous en convaincre faites vos requêtes avant et après avoir lancé un
DBCC DROPCLEANBUFFERS
ce qui vide le cache des données.

Lisez les articles que j'ai posté sur l'optimisation :
http://sqlpro.developpez.com/optimisation/

A +

PS pour ce qui est de forcer un plan de requête c'est extrêmement dangereux car cela rend la plan statique. Mais c'est possible de manière très simple les plans étant des documents XML.

[ylarvor]

Je voulais verifier, j'ai regarder à nouveau la video.

il s'agit de la troisième video sur l'optimisation par un ingenieur microsoft.

http://www.microsoft.com/france/visi...7-A9B3FFE93E1E

il explique que tu peux utiliser USE PLAN <Plan XML> dans ta requete... et l'usine à gaz dont je te parlais , c'est les plan guide qui permettent de parametrer le plan d'une requete sans intervenir sur la requete.

regarde cette video... c'est interessant car cela repond à ta question meme si on etait dans le faux tout les deux...puisqu'il s'agit des données...