Mladen Gogala
Oracle DBA
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jamadagni, Rajendra
Sent: Tuesday, August 26, 2003 4:54 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: Performance ProblemFunny ...
I have tkprof give up analyzing a 4.2G tracefile on a 64bit platform. anyone else experienced this??
Raj
--------------------------------------------------------------------------------
Rajendra dot Jamadagni at nospamespn dot com
All Views expressed in this email are strictly personal.
QOTD: Any clod can have facts, having an opinion is an art !
-----Original Message-----
From: Cary Millsap [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 26, 2003 4:24 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: Performance Problem
Laura,
You might find the problem by checking the things you plan to check, and
by following the advice of the book you're using. But the odds are very
good that you will not. At least not for a long time...Any application program on your system can tell you where it is spending
its time. Let it tell you. Take a 10046 level-12 trace of *any*
important, slow application program. Read
http://www.hotsos.com/dnloads/1/timing-data/Oracle%20Operational%20Timin
g%20Data.pdf, or ask the list for details if you need some help.
Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.comUpcoming events:
- Hotsos Clinic 101 in Sydney
- Hotsos Symposium 2004, March 7-10 Dallas
- Visit www.hotsos.com for schedule details...
-----Original Message-----
Burton, Laura
Sent: Tuesday, August 26, 2003 2:30 PM
To: Multiple recipients of list ORACLE-LNo, I had read not to analyze the sys tables in the 'TIP' section of the
book I am using as a reference (Oracle Performance Tuning/Tips &
Techniques). As I stated earlier, I also made sure that I analyzed all
the tables and indexes that were involved, because I had read that
leaving a table 'un'analyzed would cause a performance hit.Someone earlier had suggested doing the analyze during an 'off' time.
This I did not do. It was done while everything was going on, so maybe
that is why everything came to a standstill. Anyway I want to try it
again after I upgrade and do so when others are not on.If you know of any other gotcha's, please let me know. I may not have
picked up on it in my research.Someone else had responded about looking at systemic things before
attacking the code. I had already done this and found that I needed to
enlarge my sort area because the disk read ratio was a little high. I
also enlarged my shared pool size. The stats I have been running since
then to keep track of this are staying between 98 and 99% so I do not
think this is my problem now. Those changes did not make any difference
to the users. Even though the disk/memory read was not above 95%, it
was at 92% so that is probably why no performance gain was noticed. We
are using PL/SQL procedures heavily. The stats on the Library Cache
looked good though.I read something this weekend about how using 'logical' drives to
separate the different files can cause a performance hit. I am using
logical disks, and I plan to change when I can, but I'm not sure yet
how much that will help. I have redistributed some of the rollback
segments so that they are not all located on the same disk. However
since some of the drives are logical, that may not have done any good.
I've rebuilt indexes, changed extent sizes to reduce the amount of
extents, added rollback segments, etc. In lieu of this, code is next...Thanks,
Laura-----Original Message-----
Sent: Tuesday, August 26, 2003 1:29 PM
To: Multiple recipients of list ORACLE-LDid you analyze the sys schema by mistake. This can stop the fastest
database. We had a contractor do that to an 8.0.5 database once, and
only
once.Ruth
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Burton, Laura
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.net
--
Author: Cary Millsap
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).
