Stephen,

Sounds like you've already done plenty of hunting.  Do you know what these
waits were like previously?

Perhaps someone can correct me if I'm mistaken but does a "listener not
responding" error indicate the problem is getting to the server in general,
not the instance itself.  Perhaps something happened to your network
routing over the weekend?  Maybe a cross-network backup was executed over
the weekend or something like that.

Good luck finding the gremlin - some of those issues can be very good at
hiding themselves.



                                                                                       
                                   
                    "Stephen Andert"                                                   
                                   
                    <StephenAndert@firsth       To:     Multiple recipients of list 
ORACLE-L <[EMAIL PROTECTED]>       
                    ealth.com>                  cc:                                    
                                   
                    Sent by:                    Subject:     SQL*Net Message to 
client/SQL*Net more data to client        
                    [EMAIL PROTECTED]                                                   
                                   
                                                                                       
                                   
                                                                                       
                                   
                    30/10/2002 11:28                                                   
                                   
                    Please respond to                                                  
                                   
                    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: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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).



<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
   Privileged/Confidential information may be contained in this message.
          If you are not the addressee indicated in this message
       (or responsible for delivery of the message to such person),
            you may not copy or deliver this message to anyone.
In such case, you should destroy this message and kindly notify the sender
           by reply e-mail or by telephone on (61 3) 9612-6999.
   Please advise immediately if you or your employer does not consent to
                Internet e-mail for messages of this kind.
        Opinions, conclusions and other information in this message
              that do not relate to the official business of
                         Transurban City Link Ltd
         shall be understood as neither given nor endorsed by it.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Mark Richard
  INET: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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).

Reply via email to