| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> SQL*Net message waits
Hi all,
Performance concerns have been raised for a particular application. The users can't tell me exactly which actions they believe are slow, but it has been suggested that the problem may be the connection between the app server and the database. This was a fairly small app, with all components running on the same server. When we upgraded, the database went to a Unix server, and the other app process were split across several Win2003 servers. App servers are in the same rack, DB is connected with a gb line.
I ran separate 10046 traces against the most active sessions on a typical afternoon. Connections are pooled, so several different user sessions are represented in the trace files. The SQL*Net messages from the client include a range of wait times, but since the sessions included periods of inactivity, I'm considering this user think time, not wait time. 99.9% SQL*Net messages from the database back to the client are sub .00 seconds, a very few took .01 second. Total time for all SQL*Net messages in the traced sessions in a 30 minute window was .05 seconds. I'd like to be able to use this information to show that the connection between the database and the application server is not the performance block. Is this a valid way to use the data or am I reaching here? Can latency be hiding in the 'from client' messages that wouldn't appear in the 'to client' messages?
There appear to be too many database calls; still trying to investigate that, but it's a vendor app and we have limited ability to change their code. Performance issues seem to be related to the client workstation size, etc. but I need to prove that the issue is not between the app server and the db so we can move on and find the real problem.
TIA ... Robyn
 |
 |