CBO calculates un acceptable cost while using index.

Question

Hi,
I was wondering to see the execution plan for both the case using index/without index.
We are using oracle 10G(10.2.0.3.0) with RAC in production at O/S:- sun solaris 10.
Java based application is running in this database. One of the sql query is taking long time to fetch the records. I analyzed the sql plan and noticed the FTS. I created indexes to the column(s) which is refering in where clauses. I noticed a strage behavior. Execution plan shows that the CBO is using right path but its not acceptable as application is time outs while return the rows.
first execution plan with/without index (not using the index).
PLAN_TABLE_OUTPUT
Plan hash value: 419342726
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 196 | 3332 | 67845 (3)| 00:13:35 |
|* 1 | TABLE ACCESS FULL | CWDBENUMDESCRIPTIONS | 1 | 35 | 3 (0)| 00:00:01 |
| 2 | SORT GROUP BY | | 196 | 3332 | 67845 (3)| 00:13:35 |
|* 3 | TABLE ACCESS FULL| CWORDERINSTANCE | 51466 | 854K| 67837 (3)| 00:13:35 |
Predicate Information (identified by operation id):
1 - filter("ERR"."CODE"=:B1)
3 - filter("OI"."ERROR_CODE" IS NOT NULL AND "OI"."DIVISION"='OR9' AND
"OI"."ACTIVE"=TO_NUMBER(:1) AND "OI"."ORDER_STATE"<>'O_NR_NS' AND
"OI"."ORDER_STATE"<>'C_C_QR' AND "OI"."ORDER_STATE"<>'O_NR_NS_D')
SQl query was modified to force the index to use /*+ index(oi oi_div) */ the execution is as below:-
PLAN_TABLE_OUTPUT
Plan hash value: 1157277132
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 196 | 3332 | 394K (1)| 01:18:52 |
|* 1 | TABLE ACCESS FULL | CWDBENUMDESCRIPTIONS | 1 | 35 | 3 (0)| 00:00:01 |
| 2 | SORT GROUP BY | | 196 | 3332 | 394K (1)| 01:18:52 |
|* 3 | TABLE ACCESS BY INDEX ROWID| CWORDERINSTANCE | 51466 | 854K| 394K (1)| 01:18:52 |
|* 4 | INDEX RANGE SCAN | OI_DIV | 3025K| | 14226 (1)| 00:02:51 |
Predicate Information (identified by operation id):
1 - filter("ERR"."CODE"=:B1)
3 - filter("OI"."ERROR_CODE" IS NOT NULL AND "OI"."ACTIVE"=TO_NUMBER(:1) AND
"OI"."ORDER_STATE"<>'O_NR_NS' AND "OI"."ORDER_STATE"<>'C_C_QR' AND
"OI"."ORDER_STATE"<>'O_NR_NS_D')
My questions are here:-
1). why FTS is less costly comparing index scan where there are 15000000 rows in the table.
2). while forcing index to use cost increase drastically (the statistics is latest one analyzed on 6th of feb 2009)
3). what should i suppose to change to get the performance benefit.
Thanks,
Pradeep

Answer 1

user587112 wrote:
select null, oi.division, oi.METADATATYPE, oi.ERROR_CODE,
       (  select err.DESCRIPTION
FROM   CWDBENUMDESCRIPTIONS err
WHERE  oi.ERROR_CODE = err.CODE
count(*)
from CWORDERINSTANCE oi
where
     oi.ERROR_CODE is not null
      and oi.division in ('BK9')
     and oi.order_state not in ('O_NR_NS_D', 'C_C_QR', 'O_NR_NS')
      and oi.metadatatype = :1
     and oi.duedate>=:2
     and oi.active = :3
group by oi.division, oi.metadatatype, oi.error_code
order by oi.division, oi.metadatatype, oi.error_code
In this query, if we use as it is how its being displayed, it runs like a rocket, but if we change division in ('OR9') instead of 'BK9' it does not use index and leads to time out the application.
Number of records   division
1964690                             ---------------- why this field is null ?
3090666              OR9
3468                 BA9
1242                 EL9
2702                 IN9
258                  EU9
196198               DT9
1268                 PA9
8                    BK9
2332                 BH9
1405009              TP9
According to the stats in your original execution plan, it looks like you have a histogram on this column, and the index you want to use is on just the division column.
Oracle estimate for 'OR9' is 3M rowids from the index, resulting in 50,000+ rows from the table - that's a lot of work - it's not surprising that the optimizer chose a tablescan for 'OR9' - but chose to use the index for 'BK9' which has only 8 rows.
How often do you want to run this query ? And how accurate does the answer have to be ?
If you want this query to run faster even when it's processing a huge number of rows, one option would be to create a materialized view over the data that could supply the result set much more efficiently (possibly getting your front-end code to call a materialized view refresh before running the query).
The only other altenative is probably to create an index that covers all the columns in the query so that you don't have to visit the table - and if you order them correctly you won't have to do a sort group by. I think this index should do the trick: (division, metadatatype, error_code,active, duedate,orderstate). You could also compress this index on at least the first column, but possibly on far more columns, to minimise the size,
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge."
Stephen Hawking
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.