Comments on: Index Access best approach?? Not Always…

By: Amit

Amit — Fri, 26 Jun 2009 04:50:23 +0000

Daniel, I do not remember these values as I worked on this site long back..But I believe I had checked and statistics were not stale. Note that in my case index SCOTT_BILL_FK7 was being used which did not have any date column. I actually suspected this issue to be caused by null values and use of nvl function. And also there was "No out of range" messages in the 10053 as observed in my Post DBMS_STATS.COPY_TABLE_STATS does not copy low/high values

By: Daniel, Wu

Daniel, Wu — Fri, 26 Jun 2009 03:24:08 +0000

What’s the high value and the low value in the stats for these columns? Is any value in the where clause out of range?

By: Amit

Amit — Fri, 19 Dec 2008 06:34:19 +0000

Even I will have to re-read it. I was hoping Jonathan will stumble upon this article and give his opinion

cheers
Amit

By: Gary

Gary — Thu, 18 Dec 2008 21:58:27 +0000

Yeah, I can see the table cardinality coming down to 1, because there’s a bunch of of criteria.
The cardinality of the index range scan gets me though. Index selectivity and table cardinality turn out to 216.76. But, since only two of the leading columns on the index are being used, maybe it isn’t using index selectivity. I’ll have to re-read my jonathan Lewis over Xmas.

By: Amit

Amit — Thu, 18 Dec 2008 06:46:23 +0000

Gary, thanks for your update. After writing this article , I also came across article from Richard Foote. I have striked out the statement regarding B-Tree indexes and gave a new link. I cannot share the query with you (have changed table name too). But I believe I can share some information from 10053 trace which I ran for problematic query.

Table stats    Table: SCOTT_BILL   Alias: SYS_ALIAS_6
  TOTAL ::  CDN: 27451688  NBLKS:  661386  AVG_ROW_LEN:  158  
  
    INDEX NAME: SCOTT_BILL_FK7  COL#: 8 17 9 
    TOTAL ::  LVLS: 2   #LB: 101624  #DK: 21675  LB/K: 4  DB/K: 710  CLUF: 15399740
	
  TABLE: SCOTT_BILL
      RSC_CPU: 0   RSC_IO: 3
  IX_SEL:  7.8961e-06  TB_SEL:  2.4117e-11
    Join:  resc: 66419  resp: 66419
  Access path: index (scan)
  
  Join order[9]:  SCOTT_PO[SCOTT_PO]#1  SCOTT_POIC[SYS_ALIAS_5]#0  SCOTT_BILL[SYS_ALIAS_6]#2  SCOTT_CUST[SCOTT_CUST]#4  SCOTT_DSST[C]#3
Best so far: TABLE#: 1  CST:         98  CDN:      21716  BYTES:     260592
Best so far: TABLE#: 0  CST:      65246  CDN:        391  BYTES:      27761
Best so far: TABLE#: 2  CST:      66419  CDN:          1  BYTES:        126
Best so far: TABLE#: 4  CST:      66421  CDN:          1  BYTES:        141
Best so far: TABLE#: 3  CST:      66433  CDN:          1  BYTES:        161

CBO has estimated cardinality to be 1 row, though I am not sure the way it has been calculated. I believe this is calculated as round(Table_selectivity *num_rows) for SCOTT_BILL table.This comes out to 1.

By: Gary

Gary — Wed, 17 Dec 2008 22:06:46 +0000

“As B-Tree index does not index Null columns”
Steady on. The index is on “BILL_PO_NO, BILL_PO_SEQ_NO and BILL_RQMT_NO”, so there will be an index entry even when BILL_RQMT_NO is null (except maybe for the 636 with null BILL_PO_NO). Which you can see because the filter condition on the index access 11 on the problem query plan shows the NVL being applied.
Now the table has at least 27 million rows, with 32,000 distinct values for BILL_PO_NO so each BILL_PO_NO has about 850 entries, spread across 4 BILL_PO_SEQ_NO, so may give 200 entries each (though I bet there’s a lot of skew towards sequence no 1).
The NVL clause will go for, I think, a 1% default selectivity so will assume 2 rows returned. [Not sure how it gets that down to 1, unless there's a lot more than 27 million rows in the table. ] In practice, we can see that with such a high proportion of nulls, we’d get pretty much a 100% selectivity, not 1%.

It would be nice to see the original query for this, and the query plan with the hint.