Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Cost/Time Anomaly

Re: Cost/Time Anomaly

From: blr_dba <>
Date: Sat, 30 Dec 2006 01:34:22 +0530
Message-ID: <000b01c72b84$88d2c3e0$357b6dcb@lipu>

Thanks for your reply...

There is no filter in this query.

Want to know why in second case the cost is less but time taken to execute the query is more...?

Any suggestion on improving the performance of the query? I have two CPUs and the big tables are hash partitioned on ID column into two partitions.

  And your resultset will contain at least as many rows as B1 (~20M as you said), perhaps many more - correct? Given that, and the fact that B2 and B3 also contain ~20M rows, the CBO seems to be making a perfectly logical choice.

  Is it possible you don't want such a large resultset returned? Is there a filter you left off that would limit the # of rows?     -----Original Message-----
    From: []On Behalf Of blr_dba     Sent: Friday, December 29, 2006 1:03 PM     To: 'ORACLE-L'
    Subject: Cost/Time Anomaly

    Hi Gurus,

    Am stuck in a tuning problem and need your expertise to get rid of the issue.

    I have 3 huge tables(~20M rows each) and many small look up tables joined in a query as follows...

    Big tables : BT1, BT2, BT3
    Small tables: ST1, ST2, ST3, ST4, ST5, ST6

    select * from BT1, BT2, BT3, ST1, ST2, ST3, ST4, ST5, ST6     where and and and and and and and; 

    The CBO is using hash joins and the cost is too high (400K) and we are having a lots of "direct path write waits".

    I tried to remove the outer joins for the small lookup tables by using sclar sub-queries. The cost reduced drastically (10K) but the overall execution time got increased.

    Badly need your expertise to get rid of this issue.

    Also would like to know even if the CBO cost is less in the second case, why the overall execution time is more. Is n't the cost inversly proportional to the time taken to execute the query?

  This email has been scanned by the MessageLabs Email Security System.   For more information please visit
Received on Fri Dec 29 2006 - 14:04:22 CST

Original text of this message