Re: Oracle performance tuning

From: Michael E. Austin <austin_at_inmind.com>
Date: 1996/11/26
Message-ID: <329B4B37.7468@inmind.com>#1/1

I did/do not see teh orginal post, but it sounds like you are having problems
finding and correcting bad queries. There are some other tools that will give
you a lot more information that are available from companies (such as the one
I work for) that make DBA tools that can help with these types of problems.

TKPROF is available, but it can be a little kludgey at times. As a consultant
I find that performance problems fall into 3 maybe 4 categories:

poor database design
poor application code (including inefficiently written SQL) not enough horsepower (trying to go 200mph with a Chevette 4 cyl engine - can't be done)

Knowing your data, your engine and your system will go a long way in beginning to solve
those types of problems. Haveing the proper tools doesn't hurt either.

Ernst, good answer. I you see Michael Fleck w/Oracle tell him I said hello.

+=====================================================+


|               Michael E. Austin                     |

|           The Database Solutions Company            |

|        A DATABASE TOOLS AND CONSULTING FIRM         |

|  The Platform only matters if you want performance. |

|   Buy the BEST!  Buy Digital Alpha and Oracle RDB   |

|  Business:                        Personal:         |

| maustin_at_dbsol.com               austin_at_inmind.com   |
|http://www.dbsol.com     www.inmind.com/people/austin|
+=====================================================+

 views expressed by me do not necessarily  reflect the views of my employer!

erenner932_at_aol.com wrote:

> 
> Hello!!
> I agree with Cliff.  There is a debugging tool in UNIX called oradbx that
> allows you to run dynamic tracing against a given OS-level process (which
> translates to a SID on the database).  Using this tool will allow you to
> see where a given event is waiting (i.e. latch wait, db file scattered
> read (full table scans), etc.).
> If you don;t have that particular type of tool on your given platform,
> alter your entry point form so that it does a pre-form trigger that fires
> the statement:
> alter session set sql_trace true;
> This will alter your current session, when you exec your app, and turn
> tracing on for your session.  Run through the entire gambit, using as much
> "real data" where possible.  When you are finished, find the trace file
> associated with the time you fiinished running the test and translate (for
> lack of a better word) the file using tkprof.  Find all the bad queries
> and resolve them.
> Good Luck and let us know how it goes!
> Ernst W. Renner
> Sr. DBA/Systems Architect
> ITT Hartford Life Co.  VISTA
> erenner_at_itthartford.com

Received on Tue Nov 26 1996 - 00:00:00 CST