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
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
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
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
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
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#
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
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
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
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
> "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.
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
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
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
> 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
E-L <[EMAIL PROTECTED]>
> .com>cc:
>
> Sent by: Subject: Re: Diagnose
> Slow System
> [EMAIL PROTECTED]
ore.
>
> Cherie Machler
> Oracle DBA
> Gelco Information Network
>
>
>
> "Tim Gorman"
>
> .com>cc:
> Sent by: Subject: Re: Diagnose Slow
System
>
Sent by: Subject: Re: Diagnose Slow System
[EMAIL PROTECTED]
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
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
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
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
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
23 matches
Mail list logo