Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Training for Oracle Performance tuning - Method-R is easy

Re: Training for Oracle Performance tuning - Method-R is easy

From: Michael McMullen <>
Date: Fri, 28 Sep 2007 14:07:41 -0400
Message-ID: <BAY141-DAV148859FE42F0968CE544C9A6B20@phx.gbl>

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.

Received on Fri Sep 28 2007 - 13:07:41 CDT

Original text of this message