Friday, November 30, 2012

Handling Disk Space Issues During Heavy Index Rebuild Operations

There are times where you need to massively rebuild indexes on some really large databases, after indicated by the relevant analysis of course.

However, rebuilding indexes, requires also the adequate amount of free disk space that will be used during the rebuild operation (mainly for the sorting process).

Usually the required space is the size of the indexes to be rebuilt plus some more space (more information on Index Disk Space can be found here).

For example, when you have a clustered index and the table size is 50 GB you will need between 50-55 GB of free disk space in order for the rebuild process to run properly.

Imagine a scenario where you need to rebuild 10 clustered indexes and each table to be 50 GB. If you just schedule the job without having in mind disk space you might find your machine running out of disk space very soon! This can have undesirable consequences to the O.S. and any other running processes.

To this end, before deploying an index rebuild operation you first need to make sure that you have an adequate amount of free disk space.

But which disk drive should you monitor? The TempDB drive? The user database drive?

When you design an index rebuild operation, you typically have the option to sort the rebuild results in the "TempDB" system database. If you use this option then you will need to make sure that there is enough disk space on the disk onto which the TempDB database is located.

If you do not choose to sort the rebuild results in the "TempDB" database, then you will need to make sure that there is enough disk space on the disk onto which the user database is located. Of course, you should always have disk space available (always allow for some GB to be available) for TempDB as it is used in most of the SQL Server operations. However, in this case you need to focus on the drive where the database is located on.

Last but not least, a practice which I find useful because it helps avoiding disk space issues when running heavy index rebuild operations is the following:
Always, after each large index rebuild, include the following T-SQL statement:


From Books Online, when the TRUNCATEONLY option is used, it "releases all free space at the end of the file to the operating system but does not perform any page movement inside the file. The data file is shrunk only to the last allocated extent." 
By the time there's no page movement inside the files, the space that will be used for the index rebuild, it will be returned to the Operating System fast. The only prerequisite is that you run the shrink operation right after the index rebuild.
Let's conclude with pseudo code displaying how the rebuild process should look like:
You can also include in the above logic additional maintenance tasks like update statistics, etc.
I hope you find this useful! Cheers!

My Latest Projects:

Check out my latest eBook on SQL Server:
Tuning SQL Server - Ebook

Easily secure your SQL Server instances! Try out DBA Security Advisor!
DBA Security Advisor for SQL Server by SQLArtBits
DBA Security Advisor was developed by SQLArtBits. The tool was being carefully developed for an entire year and it contains comprehensive security checks and recommendations based on proven SQL Server security best practices. Feel free to download and use the Community Edition which is free and if you find it useful, you can consider upgrading to the Enterprise Edition!

Artemakis Artemiou [MVP]

Author & Editor

Artemakis Artemiou is a Senior SQL Server Architect, Software Developer and Microsoft Data Platform MVP. He is also an author, regular blogger, president of Cyprus.NET User Group and CY Country leader of INETA-EU. He is also the creator of DBA Security Advisor and In-Memory OLTP Simulator. Artemakis is a frequent guest author of worldwide well-respected online journals where he writes articles focusing on many SQL Server topics.

Reference: The SQL Server and .NET Hub (


Jeff said...

DBCC SHRINKDATABASE will also shrink the logfile. It would probably be better to just use DBCC SHRINKFILE with the TRUNCATEONLY option.

I will say that I've not had much luck with this option because there's frequently the data of other tables or indexes at the logical end of the file. It may, however, be just what the Doctor ordered for the individual files of partitioned tables.

Artemakis Artemiou [MVP] said...

Hi Jeff,

I agree that you can also use DBCC SHRINKFILE with TRUNCATEONLY.

However, as the index rebuild operations move pages inside the data file and they will require log space for storing the temp results (unless you use TempDB for that), DBCC SHRINKDATABASE will release space from both data and log files because, in this example, it runs right after the index rebuild for each database.