Oracle-L: RE: SQL*Net Message to client/SQL*Net more data to client

From: Stephen Andert <stephenandert_at_firsthealth.com>
Date: Tue, 29 Oct 2002 19:03:38 -0800
Message-ID: <F001.004F6FAA.20021029190338@fatcity.com>

Anjo,

They have reported the results of ping times and said that response times are "within spec". They have told me that the network card is handling "x bytes per second without errors" and that the card is capable of many times that throughput. They have swtiched network cards 8 times last week and "tested" each one without any errors. The reason for this testing/card switching was the errors that they were seeing that was causing the box to stop responding.

I am asking our swat team to look into the network stats from the response time perspective instead of utilization.

Thanks
Stephen

>>> anjo_at_oraperf.com 10/29/02 06:23PM >>>

This is called "Blame Storming". Every component works "fine" but response time sucks and the problem is some other area. So how do we turn "Blame Storming" into "Brain Storming"?

Check out the network components. One of the problems is that the network people look at utilization, instead of response time. They will
find that utilization of certain components may be low (due to some problem), and assume that the problem is some where else. Can they tell
how long a packet is on your network connection?

Anjo.

-----Original Message-----
Andert
Sent: Wednesday, October 30, 2002 1:28 AM To: Multiple recipients of list ORACLE-L

We have experienced a sudden and dramatic decrease in performance sometime over the weekend (after Sat but before Monday 4 am). In following Gaja's tuning philosophy, I've found that the top 2 waits are
usually (always 2 of the top 3) SQL*Net Message to client/SQL*Net more data to client. Everybody swears there have been no changes. SA's say
no harware or kernel changes. AppDev say no code changes. DBA (me) says
no database changes.

WAN folks say no WAN issues and ping is responding at expected speed. SA's say LAN card has had no errors during this time frame and is processing a good number of bytes but nowhere near it's capacity. The application has some very good timing points where there is no human element in response time, but there is a big "unknown" category that is a larger chunk of time than previously. We suspect that is machine wait time of some kind.

We just bounced the instance because someone wanted to try it and after
being back up for 20 minutes, early indicators are that performance is back to normal. We'll see how long that lasts.

We have seen a few client sessions getting errors that indicate connectivity problems (listener not responding, etc) so we wrote a .com
file that is repeatedly connecting to the database and will run overnight and stop if there are any errors.

Metalink search for SQL*Net waits gives both "tuning advice" and "you can't tune much" notes. I strongly suspect some kind of hardware failure, but don't know where since everyone involved says everything is
working fine.

Environment Notes:
Server
8.1.7.3
Tru64 5.1A (upgrade to A was done a few weeks ago) Compaq GS160 with 16 CPU's and 32 GB RAM (RAM is from memory, so that may be off)

Client
Open VMS version 7.2
Client is 8.0.5

Any ideas on a next step for finding out the cause (solution) to this drop in performance???

Help
Stephen

--

Please see the official ORACLE-L FAQ: http://www.orafaq.com
--

Author: Stephen Andert
INET: StephenAndert_at_firsthealth.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com 
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (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).

--

Please see the official ORACLE-L FAQ: http://www.orafaq.com
--

Author: Anjo Kolk
INET: anjo_at_oraperf.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com 
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------

--

Please see the official ORACLE-L FAQ: http://www.orafaq.com
--

Author: Stephen Andert
INET: stephenandert_at_firsthealth.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------