The extra byte appears only once per index entry (it’s the byte that says the rowid is 6, or 10, bytes long), so we add it to the accumulated length just once.

Why ind.uniq_ind is not multiplied by tab.rowid_length?

It makes perfect sense now. I had overlooked that avg_col_len already considered nulls. Thanks for the clarification!

Carlos

The choice of tab.num_rows was deliberate, and based on the fact the avg_col_len already makes allowance for nulls.

Every index entry has a rowid, lock byte, directory entry etc. and that’s why I have a component that uses ind.num_rows at line 162; but the “data” content of the index is dictated by the data content of the table, irrepective of how the columns are distributed across index entries. It’s probably best to see this through an example (engineered to be an extreme case):

create table t1(v1 char(6), v2 char(6));
insert into t1
select 
        decode(mod(rownum,2),0,'xxxxxx'),
        'xxxxxx'
from
        all_objects
where   rownum <= 1000
;

execute dbms_stats.gather_table_stats(user,'t1')

select  column_name, avg_col_len
from    user_tab_cols
where   table_name = 'T1'
;

COLUMN_NAME          AVG_COL_LEN
-------------------- -----------
V1                             4
V2                             7

3 rows selected.

Although every populated column has a data content length of 6 bytes, the average (content) is 3 for v1 because half the rows are null. The reported length includes the one extra byte required for the length byte that precedes the column content which is why we see 4 and 7 rather than 3 and 6 in the column stats.

If I had an index on just v1, then ind.num_rows would be 50 because only half the table rows have a value for v1; so if I multiplied the average column length by the number of index entries I would have applied the “half the rows in the table” factor twice. By using tab.num_rows I scale the average column length back up to “total space taken by column” in both the table segment and index segment.

The choice does introduce an error, of course, in as the average column length is rounded up to an integer, leading to an over-estimate. There’s a further error due to the addition of the length byte which I could correct if I used (avg_col_len – 1) multipled tab.num_rows then re-introduced as ind.num_rows * “number of columns in index”.

1. I have an entire category on rebuilding indexes: http://jonathanlewis.wordpress.com/category/oracle/indexing/index-rebuilds/

2. The best answer to that question is in my book Cost Based Oracle – Fundamentals: I don’t have space to repeat it all in a comment, but as a starting point here’s a link to a short article I wrote several years ago:http://www.jlcomp.demon.co.uk/12_using_index_i.html

I want to ask two questions related with B*TREE indexes :

1. What are the things/statistics which tells /indicate that an index need to be rebuild. There are rare cases as I have learned where index rebuild can actually help, can you please give few cases where it really helps.
2. What are the statistics using which optimizer decide to use one index over another in a table.

Thanks
Ajeet

Thanks for the extra information; it’s always useful to hear about the special cases. I’ll leave it as an exercise for someone else to test, though.

One thought, if anyone does want to follow this – my general strategy for handling “rare” cases is to write a separate script; it’s much safer and simpler than trying to write a “one script does everything … but no-one dare change it” type of thing.