RE: question about statspack

While skewness could allow for a very small number of these waits to be the 3 seconds, that is probably still too small to worry about.  

But, and again subject to skewness on the averages, I'm wondering whether the average of a little over 2,000 of these waits per second might be injecting some significant context switching overhead.  

That depends partly on the number of cpus, and of course a second is about an eternity now. Still, some part of the applications you are running may be driving line turnarounds for exceedingly small amounts of work and that in turn might be symptomatic of doing too much row by row processing. or it could be completely benign. If that is your worst wait event you probably have things really humming.  

I tend to agree with Jared's smiley face.  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Jared Still
Sent: Wednesday, March 12, 2008 12:50 PM To: john40855_at_gmail.com
Cc: oracle-l_at_freelists.org
Subject: Re: question about statspack  

You could work on eliminating these waits...

... and save 3 seconds an hour.

How long and hard do you want to work to improve response time by an imperceptible amount? ( 3/7,255,516)

:)

Jared

On Wed, Mar 12, 2008 at 6:18 AM, John Smith <john40855_at_gmail.com> wrote:

I have a statspack report with this line as one of the wait events:

SQL*Net message to client 7,255,516 0 3 0 900.0

As you can see, the number of waits is very high, but the actual time is only 3 seconds in the course of an hour. Is this something I need to be concerned about?

-- 
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist




--
http://www.freelists.org/webpage/oracle-l