Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Excessive SQL*Net message from client waits

RE: Excessive SQL*Net message from client waits

From: Karen Morton <>
Date: Thu, 13 Mar 2003 12:29:09 -0800
Message-ID: <>

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 one screen at a time. A session is spawned to do some initialization stuff...this one sticks around and may see a bit more activity before the I can see how this one would have the waits. But the other spawned sessions connect, do something and disconnect. These spawned sessions come from various controls on the screen...not different app occurrences or windows within the app.

So, what I end up with are 10 separate trace for each session connect period. Doesn't each trace file then only show that specific session's info and big spikes in SQL*Net message waits shouldn't "carry over".

I'll certainly try your idea about using netstat while tracing and see what I find.

I feel as if I'm being thick-headed about this but I do not see this same behavior at every installation. These high SQL*Net message waits are showing up only at this one client site. Other pratically identical sites do not see this behavior. By practically identical I mean that other comparable sites have different network config. This particular site has it's database server 100 miles away from the users running the client application. WAN vs LAN. Just wish I could find a "good reason" why it's so different.....

Thanks so much,
Karen Morton

-----Original Message-----
Sent: Thursday, March 13, 2003 12:19 PM
To: Multiple recipients of list ORACLE-L

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 an extreme number of very small statements behind the scenes (e.g. get all keys for a drop-down, then get each drop down by key one at a time every time the user hit the field).

It's always possible that the many layers of code at the client end are taking a surprising

However, assuming you have a truly
unreasonable loss of time on waiting for client - I would try and isolate the problem by using netstat and top. This can be hard in typical environments, though.

Start up the client session -

Start netstat running on the server with minimum snapshot time (usually one

Start top (or similar) running in real time or minimum snapshot time.

Start up event 10046 at the session.

Then get the client to do something,
and watch for:

  1. the peak in netstat as the request reaches the server.
  2. the burst from the server as the request is serviced
  3. the peak in netstat as the reply gets sent
  4. the delay before it appears on the client screen.

It's crude, but simple-minded, and if the client is causing the problem it may prove it quite convincingly.

Back it up with the trace file - which will record timestamps of a query coming in and results going out.

The biggest problem, usually, is that it simply isn't realistic to get a system so quiet that you can get just one client
running all by itself with nothing else going on.

In your particular case, I have to sya that I have noticed that Java can use a surprising amount of CPU sometimes.


Jonathan Lewis

Now available One-day tutorials:
  Cost Based Optimisation
  Trouble-shooting and Tuning
  Indexing Strategies

(see )

____UK_______April 8th
____UK_______April 22nd

____Denmark May 21-23rd

____USA_(FL)_May 2nd

Next dates for the 3-day seminar:
(see )

____USA_(CA, TX)_August

The Co-operative Oracle Users' FAQ

> 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
> if it has something to do with the application or if I can possibly
speed it
> up with tweaks to SDU/TDU. I'm just wondering... ;)

Please see the official ORACLE-L FAQ:
Author: Jonathan Lewis

Please see the official ORACLE-L FAQ:
Author: Karen Morton

Fat City Network Services    -- 858-538-5051
San Diego, California        -- Mailing list and web hosting services
To REMOVE yourself from this mailing list, send an E-Mail message
to: (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Thu Mar 13 2003 - 14:29:09 CST

Original text of this message