[TKPROF] SQL*Net message to client

Version imprimable

07/08/2008, 14h19
Alain B.

[TKPROF] SQL*Net message to client

Bonjour,

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

Je suis surpris de voir apparaitre des

Code:

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
07/08/2008, 14h29
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... :oops:
Comment est configurée l'application ? ODBC ? JDBC ? Client Oracle ? si vous supprimez les alias du tnsnames.ora, que se passe-t-il ?
07/08/2008, 14h41
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 ;)
07/08/2008, 15h05
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).
07/08/2008, 15h35
Alain B.

Citation:

Envoyé par LeoAnderson

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

Citation:

Envoyé par LeoAnderson

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

Pas sur une machine de prod :aie:
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:

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

et j'ai toujours les attentes SQLNet.

Citation:

Envoyé par 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

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.
07/08/2008, 16h00
LeoAnderson

considérez qu'il s'agit d'attente de l'application. réseau ou pas.
07/08/2008, 16h10
Alain B.

Merci
07/08/2008, 17h05
pifor

Citation:

Envoyé par 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).

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.
07/08/2008, 17h36
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