Re: SQL*Net Message to client/SQL*Net more data to client

Pings can be misleading.

There's 7 layers to the OSI model.

Ping only reaches the third layer, the Network layer.

The Transport layer is not tested by a ping.

Ping will tell you that your network is up, but it tells you nothing about the state of the server. It's possible ( and happens all the time ) that you can successfully ping a hung or crashed server.

There are open source pings available that will test TCP as well as IP, but the standard ping doesn't do this.

Wonder if your network guy knows that? ;)

Jared

On Tuesday 29 October 2002 19:03, Stephen Andert wrote:
> 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: Jared Still
  INET: jkstill_at_cybcon.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).