Comments on: Testing Knowledge of Database Performance – Is this a good Execution Plan? Friends of Oracle and Java Wed, 08 Jul 2015 07:37:03 +0000 hourly 1 By: Vinod Ladda Fri, 16 Feb 2007 05:41:43 +0000 Good expample. Things can really get complicated when a query is having joins between 4 or 5 tables, one or two nested queries, order by/group by clauses.

By: Scott Baker Tue, 26 Sep 2006 16:41:16 +0000 After learning sql_trace with the 10046 and 10053 trace with tkprof, I would also recommend using the following Note in Metalink:

Note:215187.1 SQLTXPLAIN.SQL – Enhanced Explain Plan and related diagnostic info for one SQL statement

This gives you a lot more detailed information on the underlying tables being used (especially useful when selecting against a view), the last time they were analyzed, constraint information and a whole lot more.

By: Marco Gralike Wed, 20 Sep 2006 23:34:58 +0000 @Jacco:

I agree, reality differs.

A workaround could be (of course the solution would be invest in your self…READ and learn…) running DB Console during development and make extensive use of ADDM and the AWR (but this is also not a failsafe method). This would minimize hind site approaches (in production environments!) like, using Anjo Kolks YAPP (see: – my prevered approach) or the current Oracle performance methology, tuning on the use of resources.

By: Jacco Landlust Wed, 20 Sep 2006 22:28:03 +0000 I love the examples, but the major things I miss is skewed data / histograms. These can be a serious headache / great solution while looking for performance issues.

In my experience, which is limited, in a large production environment with many databases (and too little DBA’s), an examination of the environment up to the level where you can set statistics manually is hardly possible. There is simply not enough time to analyze the database to this extend. Using the gather_table_stats with auto option on all columns is taking way too much time on a large environment, so you are stuck with hoping that gathering schema statistics on a daily (or weekly, depending on the amount of data entered) basis is enough.

Sadly enough too many applications are developed without looking at any queries. Especially java developers using the lazy sql option of hibernate are killers, although Oracle’s toplink can create some serious trouble too. These objects mappers are the future of queries though….

By: Marco Gralike Wed, 20 Sep 2006 22:06:57 +0000 Tip.

If you don’t have the space to create real indexes (because your are testing on a proper sized test environment…) use virtual indexes:

Within (for example) sqlplus use:

— Forcing the optimizer to use nosegment indexes / virtual indexes
alter session set “_use_nosegment_indexes”=TRUE;

create index orders_product_id_idx on orders(product_id)

By: Marco Gralike Wed, 20 Sep 2006 21:47:12 +0000 Discussions and/or facts about COST can be found here:
or in the latest readings of Jonathan Lewis

By: Marco Gralike Wed, 20 Sep 2006 21:44:38 +0000 One of the questions should also be: What database version are we dealing with?

Now, you will have to come up with new interview questions… :-) You gave away to much; anyway, I think understanding TKPROF should be elementary knowledge, dear Watson 😉