Optimizer is not using the right index

Question

Hi gurus,
there's something I understand. If someone can explains, it'll be greatly appreciated.
Env:
10gR2 on Redhat AS
The
SQL> desc stock_detail
Name Null? Type
NO NOT NULL NUMBER(15)
BP_CODE NOT NULL VARCHAR2(10)
STOC_CAT_CODE NOT NULL VARCHAR2(6)
BUIL_CODE NOT NULL VARCHAR2(8)
LOCA_CODE NOT NULL VARCHAR2(8)
LOCA_SUB_CODE NOT NULL VARCHAR2(6)
ITEM_NO NOT NULL NUMBER(8)
QTY NOT NULL NUMBER(6)
DEFAULT_SHELF NOT NULL VARCHAR2(1)
CREATION_DATE NOT NULL DATE
CREATION_USER NOT NULL VARCHAR2(8)
CM_NO NUMBER(15)
LANDING_COST NUMBER(11,2)
SUPPLI_COST NUMBER(11,2)
RMA_DEADLINE DATE
MOD_USER VARCHAR2(8)
MOD_DATE DATE
RECEP_DATE DATE
NOTE VARCHAR2(2000)
FLAG VARCHAR2(1)
REFUS VARCHAR2(1)
STOC_MOVE_REAS_CODE VARCHAR2(6)
I have many indexes on this table. (like 5 or 6).
There's one with item + business_unit (lets say INDEX_A)
And there's one with item + category + business_unit (lets say INDEX_B)
The following sql is always using the wrong index
select nvl(sum(sd.qty),0)
from stock_detail sd, location lo
where sd.item_no = 419261 <- In INDEX_A & INDEX_B
and sd.STOC_CAT_CODE='REG' <- In INDEX_B
and sd.bp_code = 'TECMTL' <- In INDEX_A & INDEX_B
and sd.buil_code <> 'TRANSIT'
and sd.buil_code = lo.buil_code
and sd.loca_code = lo.code
and sd.loca_sub_code = lo.sub_code
and nvl(lo.restricted, 'N') = 'Y';
This SQL always use the INDEX_A. INDEX_B is far better.
Stats of the index uactually used (INDEX_A):
Last Analyzed 2007-10-18 22:04:38
Blevel 1
Distinct Keys 72124
Clustering Factor 105368
Leaf Blocks 339
Average Leaf Blocks Per Key 1
Average Data Blocks Per Key 1
Number of Rows 110285
Sample Size 110285
Stats of the index I want to be used (INDEX_B)
Last Analyzed 2007-10-18 22:04:46
Blevel 2
Distinct Keys 77407
Clustering Factor 103472
Leaf Blocks 551
Average Leaf Blocks Per Key 1
Average Data Blocks Per Key 1
Number of Rows 110285
Sample Size 110285
Is there a way to use the right index without adding a hint?
Thanks in advance.
Message was edited by:
(made a mistkae on the stats of index B)

Answer 1

I assume the execution path is a nested loop driving of the table with the constant inputs.
The key difference in the stats is that the second index has a blevel of 2. I'd guess that the cost of using the first index is 1, and the cost of using the second index is three.
The basic cost of accessing a table through an index is:
blevel +
index selectivity (ix_sel) * leaf blocks +
table selectivity (ix_sel_with_filtering) * clustering_factor.
However, if the blevel is 1, then Oracle ignores it.
Your index and table selectivities in both cases are 1/distinct_keys (since this is 10.2)
The numbers involved with the leaf block and clustering factor calculations are so small (and similar) that the difference of 2 in the add-on for the blevel is the deciding factor.
According to the statistics, though, the choice of index shouldn't make much difference to the performance, since the number of rows (and blocks) visited is likely to be the same. However, if you have an uneven distribution of values for individual columns, you may need a histogram on that column so that the optimizer can see the effect it has on the expected work.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
P.S. I suppose it's probably fair to mention that I wrote a pretty good book about how the optimizer works: http://www.jlcomp.demon.co.uk/cbo_book/ind_book.html