RE: SQL*Net message waits
- From: "Bobak, Mark" <Mark.Bobak@xxxxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 16 Mar 2004 16:31:55 -0500
Robyn,
Ok, of a 30 minute window, 0.05 seconds total was attributed to SQL*Net message
waits. How many total SQL*Net waits were in the trace?
I'm a little concerned because with the scoping error you admit is present in
your tracing, it's going to obfuscate the solution a bit.
I'm also a little concerned that "the users can't tell me exactly which actions
they believe are slow....". That statement tells me
your system has no real measurable SLA. Without that, how will you know when
you've succeeded? Ok, ok, I know, it wasn't your idea
but you're stuck with it. Which business process is the most business critical
and performing the worst. Start there. Try to get
an accurately scoped trace of that process. This will reveal much in
determining where the problem is.
Now, going back to the trace you already got:
What does the profile of the other 29 minutes 59.95 seconds look like? How
many database calls are in the trace file?
Database calls are PARSE, EXEC and FETCH. Also, how much CPU time is
represented in that 30 minutes? How much wait time?
What events were you waiting on?
Also, consider what's going on the in the O/S. Are the CPUs hammered? Are
there lots of processes waiting on I/O?
Hope that helps,
-Mark
-----Original Message-----
From: Robyn Anderson Sands [mailto:robyn@xxxxxxxxxxxxx]
Sent: Tuesday, March 16, 2004 3:40 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: 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
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
