This content has been marked as final. Show 5 replies
How could you possibly know this without knowing how the index is used? The basis for these scripts is:
-- Index is considered as candidate for rebuild when :
-- - when deleted entries represent 20% or more of the current entries
-- - when the index depth is more then 4 levels.(height starts counting from 1 so > 5)
-- Index is (possible) candidate for a bitmap index when :
-- - distinctiveness is more than 99%
What if you're going to reinsert those 20% of deleted entries? What if 5 levels is the natural size of the index, and it's just going to grow (painfully) back to that level? What if you modify some of the values you've just bitmap indexed?
I would focues efforts on tuning problems that you actually have, not on this.
If you read the script, you will see that it uses dbms_output() to print out the details of an index only if it meets certain criteria. Presumably there are no indexes in your schema that meet the criteria.
Frankly I find it hard to believe how stupid someone at Oracle has been to "update" and re-publish this script with a 10g reference.
There is no mention of the locking problems that the validate command produces, no hint that the script might list details from one index with the name from another index because of that locking problem, and no warning that turning a B-tree index into a bitmap index may cripple an OLTP system.