Index Reorganize (2)

Question

Hi All,
I was on a long vacation so couldn't post my comments for my previous query. Today i checked and could see lot of replies and arguments over the issue. And before i could reach to a conclusion the thread has been locked i guess and i'm not able to comment. So, i'm posting this new thread.
After giving just a single read to most of the replies(not all, coz some of those were deleted i guess), i was not able to decide what is the exact answer to my question.
You guys are Experts and i can count on you to give me what i need or atleast show me the right direction. It's been less than an year since i'm working in this Real-World environment.
So, i would request you all to give a me a clear answer(approach) for my query:
"How can i check for indexes that are more than 15% fragmented in my 9.2.0.8 DB?"
Thanks and Regards,
Nick.

Answer 1

two comments
1) the benefits of re-organization generally require justification
2) you haven't defined what you mean by 15% fragmented.
Google tells me that I wrote the following in response to an advocate of rebuilding who regularly rebuilds indexes and will likely have his own script as an answer to your query.
>
Nick's already received adequate answers to his query in the form of the queries that detect indexes that are significantly larger than they should be. He's also been told that a simple rule of thumb like '15% of index entries are for deleted rows' is inappropriate. In addition I'm not the one advocating rebuilding according to formulae, or who claims to rebuild thousands of indexes without issue. I'd have thought that the self proclaimed expert who delights in advocating rebuilding would be a more likely candidate for being in a position to share with us their rules for index rebuilds.
Personally I think that a query of the form
select (del_lf_rows/lf_rows) from index_stats;post analyze .. validate structure which is probably the closest to Nick's original request, is likely to be only a little better statistically than
select index_name from dba_indexes where uniqueness = 'NON-UNIQUE'
for identifying candidate indexes for rebuilds.
In the end it's all about understanding the data, if we know that that 15% of data has been deleted, and similar values will never again be inserted into the table - and exisiting data will never be updated to similar values, then you've probably got a good candidate for rebuilding, but it isn't the 15% it's the fact that the leaf nodes will not be reused that is important. It's also this, that puts the lie to the idea that 'it follows that a query will detect them', how can a query exist that will tell us what the behaviour of yet to be inserted data will be? Now for what it's worth I don't think it has been shown that most indexes are on columns where data arrives in random order - though many are - I suspect that many are on sequence or date derived columns (or similar data) where indeed it maybe that deleted space (so long as all the old data doesn't get deleted) is not reusable, but it still remains a function of the data that has been deleted and the data that is yet to come.
>
You'll see that I'd identify your candidate indexes by doing analyze index... validate structure; and use averages across the index. I'd also not actually execute any of this unless I was persuaded by other means that I needed to rebuilt on a 'how much free space is there' basis. Incidentally this suggestion got shot down because calculating this stuff is resource intensive, one of my main objections to doing it in the first place.
How to find unexpectedly large indexes is shown at http://www.jlcomp.demon.co.uk/index_efficiency.html and the psoug library.
In summary I'd say
1) why bother, why aren't your deletions going to be reused?
2) if you are bothering it costs, is the cost worth it?
3) why 15% rather than 35%?
Niall
PS: others will advocate frequent rebuilding, I'd pay close attention to the criteria they give you - mostly missing from the debate so far.