Discussion :

[FMJ]

Bonjour,

En fait je suis en train de développer une petite application Access s'appuyant sur une base d'un SQL Server Express 2008 (10.0.1600.22).
Un formulaire utilise un Recordset ADODB pour requêter le serveur. La requête utilisée est une simple requête de type sélection, qui utilise plusieurs sous-requêtes en tant que colonnes., soit tout ce qu'il y a de plus basique. Le Recordset est utilisé avec les paramètres adOpenStatic et adLockOptimistic (donc juste pour une simple consultation ponctuelle).
L'exécution de la requête via ce Recordset est instantanée. Sur le moniteur de ressource, il y a un dirac de moins d'une seconde. Et toutes les données requêtées sont bien chargées et affichées dans le formulaire.

Par contre, la même requête, avec une syntaxe strictement identique, exécutée sur la même base, mais ce coup-ci via le Management Studio (2014 pour le coup) a une exécution de 23s....
J'ai vérifié, revérifié, je retombe bien sur ces 23s.
Le Management Studio est paramétré avec les options de requête standards (soit SET ARITHABORT , SET CONCAT_NULL_YIELDS_NULL, SET ISOLATION LEVEL en READ_ONLY et DEADLOCK PRIORITY en Normal).
J'ai regardé le plan d'exécution : la totalité des coûts sont portés par les sous-requêtes utilisées en tant que colonnes de résultat (elles sont toutes identiques à un paramètre près). Et effectivement, si je supprime ces sous-requêtes, la requête est exécuté instantanément.

A noter que l'application Access, le management Studio et la base SQL Server sont hébergées sur le même poste.

Auriez-vous une idée sur la raison (paramétrage du Management Studio j'imagine) qui pourrait expliquer cet énorme différence de performance d'exécution.
Normalement, je m'attendais à une tendance inverse, mais avec un écart beaucoup plus modéré.
Je suis vraiment très circonspect ?????

Merci pour votre aide.

[soazig]

Bonjour,
Tu auras peut-être des axes de reflexion ici
http://www.sommarskog.se/query-plan-mysteries.html
Pour ton cas particulier, je n'ai pas d'idée
Cordialement
Soazig

[aieeeuuuuu]

Bonjour,

si vous n'avez pas les mêmes variables d'environnement (ainsi que pour d'autres raisons), alors vous pouvez avoir deux plans d’exécution différents. l'un optimal, l'autre non visiblement.

Il faudrait donc comparer les plan d’exécution pour comprendre le problème avec celui qui est lent. Peut-être simplement un problème de mise à jour des statistiques,...

Postez les plan d’exécution réels, ça sera un bon début pour orienter les recherches.

[rudib]

Bonjour,

Il faudrait analyser les attentes générées par la requête, par exemple avec une session d'événements étendus. Management Studio utilise en interne un SqlDataReader pour afficher ses résultats, cela génère des attentes de type NETWORK_IO ou ASYNC_NETWORK_IO si le jeu de résultat retourné est important et que SSMS met du temps à l'afficher. Le datareader est un objet connecté qui récupère ses données au fur et à mesure. Si ton application Access utilise un objet déconnecté qui récupère les données en une seule fois, cela peut faire une différence, même si ici ça semble beaucoup. Quel est le volume de données retourné ?
Mon outil SQL Trismegiste (voir lien dans la signature) extrait les statistiques d'attentes sur ton serveur SQL.

[FMJ]

Bonjour et merci pour vos réponses.

D'abord, le volume des données est faible : il y a 10 lignes avec quelques dizaines de colonnes à afficher ! Par contre dans ces colonnes, il y a 30 sous-requêtes un peu lourdes qui filtrent sur des champs indexés transformés. Donc à la base, je n'étais pas étonné que MMS mette 23s pour afficher le résultat !

Ensuite, concernant le plan d'exécution, je sais l'afficher pour une exécution sous MSS mais quid d'une requête passée via une connexion ADODB ???

De plus à quel niveau sont paramétrées les variables d'environnement d'une connexion ADODB ?


Rudi

Tu abordes des notions que je ne maîtrise pas. Mais quand tu parles de NETWORK_IO et ASYNC_NETWORK_IO, je m'attendrais à ce que leur impact soit nul puisque l'application VBA et le SQL Server sont sur la même machine ???!!!
Mais je vais tâcher d'investiguer sur le SqlDataReader et sur ton outil Trismegiste.

Merci

[rudib]

Tu abordes des notions que je ne maîtrise pas. Mais quand tu parles de NETWORK_IO et ASYNC_NETWORK_IO, je m'attendrais à ce que leur impact soit nul puisque l'application VBA et le SQL Server sont sur la même machine ???!!!
Mais je vais tâcher d'investiguer sur le SqlDataReader et sur ton outil Trismegiste.

Les attentes en question ne sont pas liées à des problématiques physiques du réseau, mais au comportement de l'application cliente. Si le client utilise un objet connecté, il récupère petit à petit les données du serveur dans une session TCP. S'il prend tu temps à traiter les lignes qu'il récupère, il va traîner pour demander à SQL Server les lignes suivantes (à envoyer des ACK au serveur pour l'avertir qu'il peut continuer à envoyer ses données).
Si par exemple je mets ici un jour à te répondre, ce n'est pas parce que developpez.net est lent, ce n'est donc pas la faute du réseau.