When should I rebuild my indexes?
Need is necessary for any change. I hope all agree to this. So why
many DBA’s (not all) rebuilds indexes on periodical basis without
knowing the impact of it?
Let’s revisit the facts stated by many Oracle experts:
- B Tree indexes can never be unbalanced
- The distance of any leaf block (which contains the index value) from the root block is always same.
- B Tree performance is good for both small and large tables and does not degrade with the growth of table
When will rebuild help?
• When the data in index is sparse (lots of holes in index, due to deletes or updates) and your query is usually range based.
If your SQL’s use “=” predicate, rebuilding of index may not help you at all unless the DML’s (updates/deletes) on the table are cause of increasing the height of index. Due to heavy updates/deletes on a table, the space in the index can be left unused (unless it is reused) due to which block splits and if the splitting goes beyond the level of accomodation, the height of index increases by 1.
In simpler terms, unless you reduce the height (BLEVEL) of index, the time taken to reach the leaf block from root block will not change.
As explained above, the height of index can be decreased by rebuild of an index(only if height was increased to updates/deletes).
Only in case of range scan, rebuild (consider coalesce option also) may help.
Select * from emp where empno between 1000 and 2000;
In above case there could be lot of deleted/updated data which will also be read while reading between 1000 to 2000. Rebuilding will reclaim any unused space and hence the select could be faster.
• Index fast full scan/ Index full scan. (rare case)
If your SQL’s are designed in a way that mostly data is selected from index (it doesn’t goes to table). In this case the whole index is read for data not for redirecting to table.
Ex:
Select count(empno) from emp; — you have an index in empno
Select empno from emp — you have an index in empno
Both the above SELECTs will fetch the data from Index only. Since the whole index is getting read, the space used by deleted rows is also read at the time of SELECT operation
Let’s revisit the facts stated by many Oracle experts:
- B Tree indexes can never be unbalanced
- The distance of any leaf block (which contains the index value) from the root block is always same.
- B Tree performance is good for both small and large tables and does not degrade with the growth of table
When will rebuild help?
• When the data in index is sparse (lots of holes in index, due to deletes or updates) and your query is usually range based.
If your SQL’s use “=” predicate, rebuilding of index may not help you at all unless the DML’s (updates/deletes) on the table are cause of increasing the height of index. Due to heavy updates/deletes on a table, the space in the index can be left unused (unless it is reused) due to which block splits and if the splitting goes beyond the level of accomodation, the height of index increases by 1.
In simpler terms, unless you reduce the height (BLEVEL) of index, the time taken to reach the leaf block from root block will not change.
As explained above, the height of index can be decreased by rebuild of an index(only if height was increased to updates/deletes).
Only in case of range scan, rebuild (consider coalesce option also) may help.
Select * from emp where empno between 1000 and 2000;
In above case there could be lot of deleted/updated data which will also be read while reading between 1000 to 2000. Rebuilding will reclaim any unused space and hence the select could be faster.
• Index fast full scan/ Index full scan. (rare case)
If your SQL’s are designed in a way that mostly data is selected from index (it doesn’t goes to table). In this case the whole index is read for data not for redirecting to table.
Ex:
Select count(empno) from emp; — you have an index in empno
Select empno from emp — you have an index in empno
Both the above SELECTs will fetch the data from Index only. Since the whole index is getting read, the space used by deleted rows is also read at the time of SELECT operation
No comments:
Post a Comment