The Index Fragmentation form provides a quick snapshot of the indexes in the Database that are fragmented more than the chosen value. The MS SQL recommendation is to not allow fragmentation over 30%, so the default value is set to 30. This value can be altered.
Double clicking a row on the Index Fragmentation Table will display a popup box with more detailed information about how that index is used. This data is reset anytime the database is restarted for any reason. This can be used to help evaluate possible index clean up if the database has been running for a long period of time.
The decision to rebuild, reorganize or just leave an index alone will vary from case to case. It may be necessary to experiment to determine the best threshold for the environment.
Fragmentation on small indexes is usually not controllable, so small indexes may not realize any benefits from rebuilding or reorganizing. |
REBUILD | REORGANIZE |
---|---|
This process drops the existing index and recreates it | This process does not drop the index, but physically reorganizes it |
Will lock the database resources | Does not lock the database resources |
Can be executed while the database is online or offline (If contains LOB* data it must be excuted offline) | Only executes while the database online |
Settings can be changed that affect the index, such as fill factor | Settings stay the same |
Index-column statistics are updated | Statistics are not updated |
Reclaims disk space by compacting the pages in new index | Works in two phases, compaction and defragmentation |
Requires extra space (the size of the current index) | Does not require free space |
Fixes extent fragmentation | Fixes mainly logical fragmentation |
If the index spans multiple data files, it will be addressed | If the index spans multiple files, it will only reorder pages within the same file |
It is commonly recommended to rebuild indexes that are over 40% and to reorganize indexes that are between 5-40% fragmented. This also depends on the size of the table and how often that index is depended upon. Smaller tables will have high fragment sizes, but not benefit from reorganization or rebuilding. Tables with LOB* data that are rebuilt will need to be rebuilt offline, so performing some of these tasks should be scheduled as part of a regular maintenance plan with database backups.
*LOB data (text, ntext, varchar(max), nvarchar(max), varbinary(max), image, and xml data type columns) |