There are several things that should be done on a regular basis and one of these things is to manage database fragmentation. Depending on the tables, queries and indexes that are being used fragmentation can cause performance issues as well as using unnecessary space in the database. Database fragmentation is similar to disk fragmentation in that the data is stored in various places in the database file instead of sequentially or next to like data within the database. This often occurs where you have non-sequential keys and the constant inserting, updating and deleting of data causes the data to become fragmented as well as the use of additional data pages to store the data. So what steps should be taken?
The first step in managing fragmentation is to better understand what tables and indexes are fragmented and then to determine what steps to take for rebuilding indexes.
For small databases the normal practice is to use a Maintenance Plan to rebuild indexes across the board for all indexes. With SQL Server 2005 Maintenance Plans you have the option to specify which indexes to rebuild at a table level, but not at an individual index level. This is a great option if the database is not that large or if you have primarily small tables, but as the database and tables get larger this could become an issue because of the time that it will take to complete the operation. In addition, when using Maintenance Plans for SQL Server 2000 the only option is to rebuild the index, but with SQL Server 2005 you have the option to either do an index rebuild or an index defrag.
The differences between an index defrag and an index rebuild are as follows:
|Option||DBCC DBREINDEX (SQL 2000)
ALTER INDEX REBUILD (SQL 2005)
|DBCC INDEXDEFRAG (SQL 2000)|
ALTER INDEX REORGANIZE (SQL 2005)
|Rebuild All Indexes||Yes||Need to run for each index. In SQL 2005 using the ALTER INDEX you can specify ALL indexes.|
|Online Operation||No, users will be locked out until complete. In SQL Server 2005 Enterprise Edition you can build indexes online.||Yes, users can still use the table|
|Transaction Log Impact||Depends on the recovery model of the database||Fully logged operation regardless of the database recovery model|
|Transaction Log Impact||If set to the full recovery model can consume a lot of space for operation to complete.||If index is very fragmented this could potentially take up more transaction log space.|
|Can run in parallel (uses multiple threads)||Yes||No|
When tables get larger and larger and some indexes get fragmented and others do not it is better to understand what is occurring prior to selecting which indexes to rebuild. The primary reason for this is the time it takes to rebuild indexes and also if you do an index rebuild versus an index defrag the index will not be available as well as the potential for blocking until the index rebuild is complete.
So where is the information stored?
With both SQL 2000 and SQL 2005 you can get the fragmentation information by using the DBCC SHOWCONTIG command. In addition, you can use the dynamic management view sys.dm_db_index_physical_stats in SQL Server 2005. These commands are great, but you really need to collect the information and then analyze the data to determine which indexes should be rebuilt versus which indexes should be defragmented.
With the management view the data is displayed like a regular query result, so this data can be easily written to a database table. With the DBCC SHOWCONTIG command the data is not written in a table format, but by using the WITH TABLERESULTS option you can get the data in a table format instead of a report format which is the default.
So once you have decided which method to use to collect the data DBCC SHOWCONTIG WITH TABLERESULTS or sys.dm_db_index_physical_stats you should create a table to load this data. Depending on your database usage this data should be collected on a weekly basis. From there you can start to analyze the data to see which tables and indexes are becoming fragmented and by how much. From this you can then experiment with the index defrag versus index rebuild to determine which process makes the most sense for your environment. Here is a quick sample to collect the data using DBCC SHOWCONTIG.
Here is another sample of T-SQL statements from SQL Server 2000 Books Online which allows you to determine which indexes to defrag. This could be modified to either do an index rebuild or an index defrag. This also uses the DBCC SHOWCONTIG versus sys.dm_db_index_physical_stats.
- Build a table to start collecting the data
- Build a scheduled job to collect the data on a weekly basis
- Experiment with rebuilds versus defrags
- Establish a process to either rebuild or defrag your selected indexes based on the information you have collected
- Take a look at these other tips about this process:
- SQL Server 2000 to 2005 Crosswalk - Database Fragmentation
- SQL Server 2000 to 2005 Crosswalk - Database Maintenance Plan Wizard to SQL Server Integration Services (SSIS)
- Selectively rebuilding indexes with SQL 2005 maintenance plans
- SQL Server 2000 to 2005 Crosswalk - Index Rebuilds
- Microsoft SQL Server 2000 Index Defragmentation Best Practices
Last Update: 1/25/2007
About the author
View all my tips