Discussion :

[Alain B.]

Bonjour,

Je m'initie aux joies du "tuning" via sqltrace/event 10046/tkprof.

Je suis surpris de voir apparaitre des

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SQL*Net message from/to client

Alors que l'application que je teste tourne SUR la même machine que la base et que la chaine de connexion utilisée ne contient que user/pass sans aucune mention de connexion distante @...

Est ce que c'est un fait de sqltrace qu'il y ai toujours des attentes sqlnet même en connexion locale ?

Ou est ce que j'ai loupé un paramètre quelque part qui me force une utilisation de sqlnet transparente et à l'insu de mon plein gré ?

Config:
Oracle 10g2 sous Windows 2003SP2

[LeoAnderson]

Il faut bien que l'application cliente fetch les données retournées par le serveur, que ce soit en local ou pas, ça ne change pas grand chose.

Après, si vous êtes sous Unix/Linux, quel est le résultat du ps -aef | grep <SID> ?

(on verra clairement si les connexions locales sont vis TNS ou BEQ)

EDIT : Vous êtes sous Windows...
Comment est configurée l'application ? ODBC ? JDBC ? Client Oracle ? si vous supprimez les alias du tnsnames.ora, que se passe-t-il ?

[orafrance]

Et s'il s'agit de faire du tuning inutile de perdre du temps là-dessus, c'est pas là qu'on gagne en perf

[LeoAnderson]

je ne suis pas d'accord.
Un SQL*Net message to client très long peut indiquer des problèmes réseau et révéler un défaut de fetch. (fetcher les lignes une à une par exemple).

[Alain B.]

Comment est configurée l'application ? ODBC ? JDBC ? Client Oracle ? si vous supprimez les alias du tnsnames.ora, que se passe-t-il ?

ProC + Visual C

si vous supprimez les alias du tnsnames.ora, que se passe-t-il ?

Pas sur une machine de prod
Et même sur les machines de test, c'est les collègues qui vont être contents.
(j'essaierai un soir au calme)

edit: j'ai trouvé un peu de place sur une machine de test unix avec le même style d'applications, le ps indique

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

oracle<SID>(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

et j'ai toujours les attentes SQLNet.

Et s'il s'agit de faire du tuning inutile de perdre du temps là-dessus, c'est pas là qu'on gagne en perf

Pour l'instant je ne tune pas grand chose, je me familiarise avec les outils et j'étais surpris de voir des attentes 'réseau' alors que je tourne en local.

[LeoAnderson]

considérez qu'il s'agit d'attente de l'application. réseau ou pas.

[Alain B.]

Merci

[pifor]

je ne suis pas d'accord.
Un SQL*Net message to client très long peut indiquer des problèmes réseau et révéler un défaut de fetch. (fetcher les lignes une à une par exemple).

Je dirais même plus:
- si l'événement SQL*Net message from client apparaît dans la liste des waiting events après une requête donnée, c'est que les échanges sont liés aux étapes parse/execute/fetch de la requête en question.
- si l'événement SQL*Net message from client apparaît uniquement dans le récapitulatif TKPROF (à la fin du fichier produit), cela représente de l'activité ou de l'inactivité du client connecté à la session Oracle entre 2 requêtes.

[13thFloor]

J'ajoute ma modeste contribution aux attentes SQL Net.
Contexte : script sql lancé sous SQL+ (local ou distant)
Le paramètre arraysize peut grandement améliorer les performances.
Je l'ai constaté chez un client qui effectuait des mesures de performances mais avait oublié l'aspect réseau pour Oracle.
Le test consistait à lancer avec sqlplus 5 fois de suite une requête qui ramène (en full table scan) plusieurs milliers de lignes, chaque ligne sizant 72 octets.
Avec la valeur par défaut d'arraysize (15) on obtenait des temps de réponse globaux (elapsed time sous unix) de 13". Avec arraysize=200 on obtenait 11" et avec arraysize=400 : 6"

Conclusions :
1) orafrance a raison dans le sens ou l'essentiel des gains en sera pas obtenus sur cet aspect réseau
2) toutefois, si une majorité des attentes se produit sur l'évènement "bytes sent via SQL*Net to client", il en sera pas inutile de chercher à optimiser le flux réseau en adaptant notamment le paramètre arraysize (dans $ORACLE_HOME/sqlplus/admin)

Voir les notes Metalink :
Note:67983.1 Oracle Net Performance Tuning
Note:266809.1 Difference between GLOGIN.SQL and LOGIN.SQL
Note:69591.1 FAQ: SQL*Net Performance Tuning in Applications