SQL Server Index Fragmentation In-depth

There is no way to avoid index fragmentation in any SQL Server environment. It does not depend on your SQL Server version or I/O subsystem you have, or your hardware. In this article, we will drill down into SQL Server index fragmentation issue. We will figure out why index fragmentation is a problem and how it affects overall performance, as well as how discuss how to detect and avoid it.

Index Fragmentation

Fragmentation is a common term that describes numerous effects that can occur because of data modifications. Chances are, you already know that SQL Server stores data on 8KB data pages. Eight contiguous pages form extent. A data page both in clustered or non-clustered indexes contains pointers to the next and previous pages. The following picture demonstrates that there are no fragmentation.

Let’s insert a new row into the index and see what happens. SQL Server inserts a new row on the data page in case there is enough free space on that page, otherwise the following happens:

1. SQL Server allocates a new data page or even a new extent.
2. A part of data from the existing (old) data page transfers to a newly allocated data page.
3. In order to keep the logical sorting order in the index, pointers on both pages are updated.

As a consequence, we have 2 types of index fragmentation:

• Logical fragmentation (also called external fragmentation or extent fragmentation) — the logical order of the pages does not correspond their physical order. As a result, SQL Server increases the number of physical (random) reads from the hard drive, making the read-ahead mechanism less efficient. This directly impacts to the qury execution time, because random reading from the hard drive is far less efficient comparing to sequential reading.

• Internal fragmentation — the data pages in the index contain free space. This lead to an increase in the number of logical reads during the query execution, because the index utilizes more data pages to store data.

Detecting Fragmentation

Before you decide which defragmentation approach to use, it is required to analyze the index to find out the degree of fragmentation. You can use the sys.dm_db_index_physical_stats data management function to analyze fragmentation. The following columns in the resultset are most important:

• avg_page_space_used_in_percent shows the average percentage of the data storage space used on the page. This value allows you to see the internal index fragmentation.

• avg_fragmentation_in_percent provides you with information about external index fragmentation. For tables with clustered indexes, it indicates the percent of out-of-order pages when the next physical page allocated in the index is different from the page referenced by the next-page pointer of the current page. For heap tables, it indicates the percent of out-of-order extents, when extents are not residing continuously in data files.

• fragment_count indicates how many continuous data fragments the index has. Every fragment constitutes the group of extents adjacent to each other. Adjacent data increases the chances that SQL Server will use sequential I/O and Read-Ahead while accessing the data.

Avoiding Index Fragmentation

To avoid index fragmentation, try to adhere the following rules:

1. Choose a cluster key that complements the table’s insert pattern
2. Do not insert records with random key values
3. Do not update records to make them longer
4. Do not update index key columns
5. Be aware of features that can cause page splits
6. Implement index fill factors

Utilizing Index Fill Factor

Set SQL Server to leave free space on index leaf pages. The main idea is to allow records to expand, records to be inserted without filling out the page and having to cause page split.

Therefore, you need to figure out how much space you want to leave. Amount of space to use is 100% minus fill factor value (e.g. fill factor of 70 means 30% free space).

SQL Server only uses the fill factor when an index is created, rebuild, or reorganized. The index fill factor is not used during regular inserts, updates and deletes. In fact, that does not make any sense, because the whole point is to allow inserts and updated to happen and to add more records without filling up the page.

It is possible to set the instance fill factor using sp_configure, but not recommended. The reason is when you set the fill factor for the entire instance, there are probably some indexes that do not need fill factor. If you find that you’ve got fragmentation problems on non-leaf level of the index (rare), you can use the PAD_INDEX option. It takes fill factor that has been specified and puts it up into the non-leaf level.

Setting a Fill Factor

Probably the easiest way to set the fill factor is to use the FILLFACTOR option,  when you create or rebuild an index. You can also use the Object Explorer to set the fill factor. Note that you can not set fill factor when you reorganizing an index. Both REBUILD and REORGANIZE use the fill factor stored in index metadata, otherwise they use the instance-wide (default) fill factor. Ulless the FILLFACTOR option is specified for a REBUILD.

An obvious question arises: “What fill factor do I use?”. Well, actually, there is no any magic number. You just need to pick an initial fill factor and implement it. Put it into production and then monitor how quickly fragmentation occurs. Then choose to do one or both of the following: increase/decrease the fill factor or change the frequency of index maintenance.

Removing Index Fragmentation

Let’s figure out what is the difference between ALTER INDEX … REBUILD and ALTER INDEX … REORGANIZE. The following table demonstrates the difference:

There is no correct answer in regards to “What to use REBUILD or REORGANIZE?” One of Microsoft Books Online provides the following guidance:

• 0 to 5-10% — do nothing

• 5-10% to 30% — do REORGANIZE

• 30% to 100% — do REBUILD

Eventually, you have several basic options to remove index fragmentation:

1. Choose to rebuild index
2. Choose to reorganize index
3. Forced to reorganize by HA/DR features
4. Do nothing
5. Use CREATE INDEX…WITH (DROP_EXISTING=ON) — does the same as ALTER INDEX…REBUILD but you need to specify the entire CREATE INDEX statement.

Resources

Below is a list of resources you may find useful:

• Microsoft SQL Server 2000 Index Defragmentation Best Practices

• Online Indexing Operations in SQL Server 2005

• Books Online for ALTER INDEX (Transact-SQL)

• Free index maintenance tool (and much more)

Written by Andrey Langovoy