I’ve added a link to the Script Catalogue to the end of the article. There are two scripts there that can help you identify indexes where a coalesce would be sufficient; both do a lot of work since they read the index one block at a time, but they don’t cause any locking. One of them generates a statistical report of leaf block usage, the other “draws a picture” of the index leaf level.

However, the doubt on coalesce still stands though.

It takes us approx 8 hours!! to complete the ‘validate structur’e for all indexes (on a daily clone).

Your script caught my attention and I’m trying to use it ti identify worthy candidates for rebuild. On this regard, could you please elaborate on the relevance of the “scaling factor” used?

I’m also trying to decide on what to rebuild and what all to coalesce. Any inputs you have will be great!

Jithin

The main flaws are in the notes in the script. The biggest, perhaps, is that it doesn’t cope with compression at all. There’s also a problem with rounding errors and approximations when you have a lot of nulls in the columns that make up the index. It’s very easy to get an approximation which is much larger than the final index would actually be.

I made a few comments about the dbms_xplan feature a few months ago: http://jonathanlewis.wordpress.com/2009/05/22/index-size/

Your use of dbms_metadata.get_ddl is very elegant.

This looks like it may be one of the bugs associated with ASSM and the difficulty of choosing a moment to update the bitmaps to show that a block is free.

Any updates which do a massive delete followed by inserts run a risk of making indexes bigger than they need to be. This is because Oracle cannot re-use the space in an index block until the transaction has committed – even for rows inserted by the same transaction (except for one special case). The same thing happens with tables, in fact, but the mechanics are different and the effect is much less noticeable. (See http://jonathanlewis.wordpress.com/2009/05/20/lunchtime-quiz/ for more details.)

Since you’re on 10g with materialized views, I’d guess that you are doing atomic refreshes, which means Oracle deletes everything from the MVs and their indexes, then re-inserts, then commits – which fits a critical pattern.

You could experiment by putting a couple of your indexes into a tablespace using freelist management to see the problem “magically” disappears. Alternatively just schedule a “coalesce” on all the problem indexes immediately after the refresh.

nice post ,just out of curiousity do you mind sharing what was the flaws in the original script and what are the defects we should take note in the calculation

Thanks

Did you compare your estimation of index size with the one Oracle provides when doing explain plan on the create index statement ?

Here is an example to get estimated size for all current user indexes:

begin
 for r in ( select index_name from user_indexes ) loop
  execute immediate 'explain plan set statement_id='''||r.index_name||''' for '||
  dbms_metadata.get_ddl('INDEX',r.index_name);
 end loop;
end;
/
select object_owner,object_name
 ,cast(extractvalue(xmltype(other_xml),'/other_xml/info[@type="index_size"]') as number) estimated_index_size 
from plan_table p where id=1;

Regards,
Franck.