RE: Diagnose Slow System

2002-06-14 Thread Johnson, Michael
Title: RE: Diagnose Slow System You need to take a slice of the database when the performance degrades.   Capturing statistics at the end of the day before the database goes down is meaningless. Consider setting up a 10046 event trace and find out what session and what wait event is boggin

RE: Diagnose Slow System

2002-06-11 Thread Aponte, Tony
Title: RE: Diagnose Slow System I apologize if I missed the final post.  Did you discovered the cause of the problem? Tony Aponte -Original Message- From: Baker, Barbara [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 23, 2002 6:13 PM To: Multiple recipients of list ORACLE-L

RE: Diagnose Slow System

2002-05-28 Thread VIVEK_SHARMA
 proves insufficient . This is used on between Unix systems Though there may be better network tools too.   HTH     -Original Message-From: Barbara Baker [mailto:[EMAIL PROTECTED]]Sent: Friday, May 24, 2002 9:43 AMTo: Multiple recipients of list ORACLE-LSubject: Re: Diagnose

Re: Diagnose Slow System--OraPerf

2002-05-26 Thread Rachel Carmichael
20 groups of redo logs IS a bit astonishing.. are you switching logs so rapidly that you loop around to the first before it is archived if you use a smaller number of groups? if nothing else, it must be a nightmare to manage! --- [EMAIL PROTECTED] wrote: > > Aack! I don't know why, it makes mo

Re: Diagnose Slow System--OraPerf

2002-05-26 Thread Tim Gorman
Not astonishing, but unusual and -- as it turns out -- probably unnecessary... The query against V$LOG_HISTORY reveals that you are performing anywhere from 2 to 42 log switches per day, but no higher than 15 since you raised the size from 50M to 100M. The major question here is whether the log

Re: Diagnose Slow System--OraPerf

2002-05-26 Thread dlorraine
Aack! I don't know why, it makes more sense to me the way I said it, but I can see now my error. Here is the result of the first query...I have 20 groups with 2 members in each group! (That's not so astonishing I hope!) select thread#, group#, members, bytes/1048575 mb from v$log; THREAD#

Re: Diagnose Slow System--OraPerf

2002-05-26 Thread Anjo Kolk
Hi Debi, The check that is performed is basically looking at the settings of log_checkpoint_interval and that is multiplied by the physical blocksize. In your case that comes to 9+GB. Setting the checkpoint interval high but the size of log file is kept small, will still cause a lot of checkpoint

Re: Diagnose Slow System--OraPerf

2002-05-25 Thread Tim Gorman
Two groups of 20 members apiece? That must be a misprint! Is that even possible? Perhaps you mean 20 groups of 2 members apiece? That is still astonishing, but not as astonishing as the way it reads originally... Just to make sure we have the right story, please post the results of the follow

Re: Diagnose Slow System

2002-05-25 Thread Tim Gorman
Yup. It never makes sense to pay attention to more than 3-5 issues at a time. The operative word is "triage"; fix what you can, get the fixes moved into production, then re-evaluate and peel off the next top 3-5 issues and repeat. Getting a list of 20-30 tuning issues would cause a dispersal o

Re: Diagnose Slow System--OraPerf

2002-05-25 Thread dlorraine
After seeing the original post and replies, I checked out the analyzer at oraperf.com, as I am having performance problems for the first time since becoming a DBA for our student information system. Over time, we've gone from 7.3.4 to 8.1.7.3 64-bit, from sequent to Sun Solaris, from 800-1200 us

Re: Diagnose Slow System

2002-05-25 Thread Greg Moore
> "tuning advise" section is merely a listing of the > subtotals of each individually identified component > of "total response time" I usually get only three or four items of advice at the end of an oraperf report. Is that typical? -- Please see the official ORACLE-L FAQ: http://www.orafaq.

Re: Diagnose Slow System

2002-05-25 Thread Greg Moore
I don't get what it means when the oraperf report says the tuning suggestions are "ranked" in order of the potential impact they may have on performance. It seems like that means the item at the top of the list would have the most potential impact, but the report also has an estimate of the perce

Re: Diagnose Slow System

2002-05-25 Thread Rachel Carmichael
short answer: yes oraperf is written/run by Anjo Kolk, father of the tuning by wait event methodology. I would tend to trust his suggestions for tuning opportunities. Would I not also investigate on my own? No. I know my apps, he doesn't unless he's come onsite. But oraperf can give me some gener

Re: Diagnose Slow System

2002-05-25 Thread Tim Gorman
There is always a flaw somewhere, but that "tuning advise" section at the bottom of the report is useful because it is a simple arithmetic summary based on the percentage numbers laid out earlier in the report. The whole "YAPP" methodology is based on identifying the portions of "total response t

Re: Diagnose Slow System

2002-05-24 Thread Greg Moore
> the YAPP analyzer at www.oraperf.com anyways.. The last part of the oraperf report has suggestions for items to investigate and tune. Is oraperf really good at spotting the key tuning opportunities? -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Greg Moore INE

Re: Diagnose Slow System

2002-05-24 Thread Rachel Carmichael
E-L <[EMAIL PROTECTED]> > .com>cc: > > Sent by: Subject: Re: Diagnose > Slow System > [EMAIL PROTECTED]

Re: Diagnose Slow System

2002-05-24 Thread Tim Gorman
ore. > > Cherie Machler > Oracle DBA > Gelco Information Network > > > > "Tim Gorman" > > .com>cc: > Sent by: Subject: Re: Diagnose Slow System >

Re: Diagnose Slow System

2002-05-24 Thread Cherie_Machler
Sent by: Subject: Re: Diagnose Slow System [EMAIL PROTECTED]

Re: Diagnose Slow System

2002-05-23 Thread Barbara Baker
Thanks, Tim. I do have a YAPP report from last week when the problems began --  I'll get that to you.  I'll also grab some more data tomorrow.  (If it's consistent, it'll start slowing down about 9:00 tomorrow morning.) Barb   Tim Gorman <[EMAIL PROTECTED]> wrote: Barb,Can you take a BSTAT/ESTAT

Re: Diagnose Slow System

2002-05-23 Thread Tim Gorman
Barb, Can you take a BSTAT/ESTAT while the problem is occurring? Run the "utlbstat.sql" script from SVRMGRL and then 15-25 mins later run "utlestat.sql" from SVRMGRL. It's actually pretty important the "utlestat.sql" be run from SVRMGRL and not SQL*Plus. Please do this at least once during the

Re: Diagnose Slow System

2002-05-23 Thread Greg Moore
One idea is at the end of the day run the script response_time_breakdown.sql from Steve Adam's site. If people are not complaining about a specific SQL statement, but just say the system is slow, this will show the components of response time. For example, it will show you how significant enqueu

Re: Diagnose Slow System

2002-05-23 Thread Bill Pass
Although the wait per enqueue is high, it is not where the majority of wait time is being spent. I would be more concerned about the full table scans as indicated by the 'db scattered read events'. If you can capture the sid in v$session_wait for this event, you can track down the object being fu

RE: Diagnose Slow System

2002-05-23 Thread Cary Millsap
Barb, Trace a slow session, choosing carefully when you start and stop data collection to include *only* user response time. As I showed in the example on the "I/O EVENTS" thread earlier on this list, this trace data will give you what you need to prove whether or not you have the network issue y