Title: RE: Excessive SQL*Net message from client waits
I recently worked on tracing and tuning a process where developer retrieved one row, did a bunch of pl/sql stuff and update ... lather, rinse and repeat.
There were a lot of SQL*Net message from/to client. I finally opened up
Bear in mind that when you are talking about a
load process, your client is another computer
program, and should not (you hope) need any
think time. This is the one case where the
SQL*Net message from client is a threat
rather than (as statspack puts it, I think) an
idle event.
Regards
by: Subject: RE:
Excessive SQL*Net message from client waits
[EMAIL PROTECTED
Not like this nor should it be the top event always as seems to be the
case here I don't believe. And, I know for certain that the client did
everything as quickly as possible during the trace. Minimal data entry done
and OK buttons clicked without delay...no time out for getting a cup of
coffee
But if one user spawns 10 sessions, then whilst
one session is being 'clicked' the other 9 are idle -
no matter how fast the user is being bounced from
one to the next - so on average every session is
going to be waiting for SQL*Net message from client
90% of the time.
Regards
Jonathan
Good point, but what if each user only has a single session?
Not that I've noticed this exact same situation here on one of our
Engineering support databases whose clients are Java, and I'm not wondering
if it has something to do with the application or if I can possibly speed it
up with tweaks
Title: RE: Excessive SQL*Net message from client waits
This is an idle wait event that just means the server is waiting to be given some work from the client. Looks to me like you won't be needing to do any tuning on this database.
-Original Message-
From: Karen Morton [mailto:[EMAIL
I'd start by being doubtful about anybody
being able to work so fast that the can avoid
a high percentage of time in 'sql*net from client' -
in fact, it the percentage was low (when the
client was a person at a terminal) I would
write myself a memo to check whether the
client code was executing
Jonathon et al, is it really true that every session is waiting on the
others if as each session is spawned, it does its thing (i.e. issues some
set of queries) and then disconnects? There are never two sessions doing
something simultaneously really. The user logs in and only sees and works
with
I am not suggesting that sessions are waiting
for each other, or reporting each others' wait
times. I am simply assuming that if the application
design was daft enough to spawn multiple sessions,
it probably was clever enough to have the parallel,
independent threads of execution making all
]
lting.comcc:
Sent by: Subject: RE: Excessive SQL*Net
message from client waits
[EMAIL PROTECTED
]
14/03/2003 cc:
08:55Subject: RE: Excessive SQL*Net message
from client waits(Document
link: Mark Richard
Hi
Isn't sql*net message from client always sort of on top, because it just
means the rdbms is waiting for the client to send some query/command (user
is not typing/clicking/reading fast enough)
Jack
-Original Message-
Sent: donderdag 13 maart 2003 3:19
To: Multiple recipients of list
13 matches
Mail list logo
