Discussion :

[Macfurp]

Bonjour,

j'ai un problème de performance sur une application qui exécute séquentiellement plusieurs dizaines de requètes, à chaque utilisation sur une seule table, et ces requètes provoquent du Scan systématique.
Les tables utilisées sont de volumétrie moyenne (entre 500.000 et 1M lignes, mais selon l'utilisation choisie seule une table est utilisée.
Je n'ai aucun moyen d'intervenir sur cette application développée en PHP qui soumet des procédures stockées à la volée et d'autre part le nombre de requètes exécutés est trop varié pour permettre une indexation correcte et surtout la structure des tables parfaitement inadaptée au besoin.

Le nombre d'utilisateurs étant relativement restreint je me demandais si je pouvais m'orienter vers une technique visant à placer la table utilisée quelque part en mémoire et espérer un gain les temps d'attente...

Quelqu'un aurait-il une idée sur la question ??

[SQLpro]

et surtout la structure des tables parfaitement inadaptée au besoin.

Dans ce cas il n'y a aucun remède. Il aurait plus simplement fallut faire développer votre application par des professionnels ayant un bonne maîtrise des problématique d'optimisation pour des bases à forte volumétrie.

Lisez les articles que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/optimisation/

Seule solution (qui est un pis aller) ajouter des ressources au serveur : augmentation de RAM tendant vers la taille de la base, augmentation du nombre de processeurs.... Mais cela vous coutera à terme plus cher que de remanier la structure de la base, car il s'agit d'une véritable fuite en avant !
Vous pouvez aussi tenter de faire ces requêtes par des lectures inconsistantes (niveau d'isolation READ UNCOMMITTED). Au moins il n'y aura aucun verrou posé. Mais le contrepartie est que vous risquer de lire des données "sales".

A +

[Macfurp]

Merci pour les infos et la documentation très instructive...
J'en déduis que la marge de maneuvre dont je dispose est très réduite.
Les traitements n'effectuent que des lectures et les données ne sont pas mises à jour en journée aussi j'ai effectué des mesures avec l'option WITH (NOCLOCK) sur tous les accès malheureusement je n'ai constaté aucun gain significatif sur les temps de réponses.

[Macfurp]

Oups, il s'agit bien de l'option WITH (NOLOCK) !

En complément, les requètes sont constituées dynamiquement par les procédures stockées en fonctions des valeurs fournies aux différents paramètres de la procédure.
Aussi le traitement finit par effectuer un EXEC @Requete une fois la requète constituée dans la variable; ce mode de fonctionnement ne peut-il entrainer un allongement des temps de réponse ?

[elsuket]

Bonjour,

ce mode de fonctionnement ne peut-il entrainer un allongement des temps de réponse ?

Malheureusement, si, parce que les plans des requêtes exécutées par un EXEC(@maChaîne) ne sont pas conservés par SQL Server.
Les requêtes sont compilées à chaque appel, et la compilation coûte cher

Un demi-remède est d'exécuter ces procédures en utilisant la procédure stockée système sp_executesql si c'est à peu près tout le temps les mêmes requêtes qui sont exécutées, aux valeurs des parmètres près (lisez bien la rubrique notes).
Le mieux restant d'écrire des procédures stockées, et dans votre cas de tout reprendre, ce qui n'est pas facile à faire comprendre et encore moins à faire accepter

[Macfurp]

Merci une fois encore, même si je constate que je cumule les handicaps, la qualité des réponses données sur le forum reste une grande satisfaction.