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 eventis 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
ystemsThough 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 Slow System
Thanks, Tim.
I do have a YAPP repor
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
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#
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
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
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
time
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.com
--
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
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
of
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
:
Sent by: Subject: Re: Diagnose Slow System
[EMAIL PROTECTED]
om
recipients of
list ORACLE-L [EMAIL PROTECTED]
.comcc:
Sent by: Subject: Re: Diagnose Slow
System
[EMAIL PROTECTED]
om
05/23/02 09:38
PM
:
Sent by: Subject: Re: Diagnose
Slow System
[EMAIL PROTECTED
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
List:
We've been fighting problems for several days. I've sort of overwhelmed
myself with data, but I don't know what any of it means.
Solaris 2.6, Oracle 8.0.5, MTS
Users complain of extreme slowness. No errors in alert, no trace files
generated.
Database is bounced every day. I capture
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
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
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
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
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 while
22 matches
Mail list logo
