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: [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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Anjo Kolk 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).
