I think alot of people associate Method-R with extended trace files. I've
always thought this isn't necessarily the case. In 8 years of being a dba, I
think I've done a handful of extended trace to figure out a problem. 99% of
problems I've had are either bad sql whither written or poor stats or
hardware problems associated with storage. I've always found Oracle to be
remarkably fault tolerant and resilient (though RAC is different). I always
use the extended trace as a last resort, never the first thing I do. Same
with statspack/AWR.
I have a RAC database where all client interactions are through Weblogic
beans and whatever else they call it. This is used for all ordering within
our organization. You probably have 10 different vendors responsible for
various pieces of the process. Really, the business has no idea what is
hitting the database or what is important. What they usually do is say it's
the database if there's any slowdown and it's because the
business/programmers just don't understand it. My approach is it's an
ordering system, queries are lightning quick. If I use session browser on
TOAD and see active queries then this is what I concentrate on. They pile up
quick in a slowdown. It's really Method-R and it's how I've always done my
tuning, even before the book. If I don't see any active queries then I say
the problem is elsewhere (there is auditing, so I can tell queries are being
executed).
Anyways, for this most important database, I will log onto it throughout the
day and just watch what is going on and I am not shy about adding an index
on the fly. I find our RAC hates full tablescans across nodes and I do not
like being paged.
So the best tuning class is sql knowledge and knowing dbms_stats. Internals
are good to wax poetically about with other dba's when there isn't a fire to
put out.
--
http://www.freelists.org/webpage/oracle-l
Received on Fri Sep 28 2007 - 13:07:41 CDT
