Determining database free space with Exchange 5.5 Service Pack 1 and later versions of Exchange

Versions of Microsoft Exchange starting with Microsoft Exchange Server 5.5 Service Pack 1 offer two informational features for determining free space in Exchange database (EDB) files. Knowing this can help you decide whether it is worthwhile to perform offline defragmentation.

To discover how much free space is available in your database files, look for an Event 1221 in the Windows application event log. There will be separate events logged for each database after online defragmentation completes for that database. The event descriptions will be similar to the following:

For Exchange Server 5.5, an Event 179 from source ESE97 is logged for each database at the beginning of online defragmentation. An Event 180 signals completion of online defragmentation. An Event 183 indicates that online defragmentation did not complete, but has been suspended and will finish later. Online defragmentation may be suspended if the online maintenance period that is defined for the database expires before online defragmentation completes. In this case, online defragmentation will resume where it left off during the next online maintenance window.

In Microsoft Exchange 2000 Server and in Microsoft Exchange Server 2003, event ID 700 signals the beginning of a full pass, and event ID 701 signals the completion of a full pass.

You may view or adjust the Information Store Maintenance schedule in the Exchange Server Administrator program for individual databases.

The free space that is reported by Event 1221 is a conservative estimate. If you perform offline defragmentation, you will recover at least the amount of space that is reported as free. All space in an Exchange database is owned either by the database root or by particular tables in the database. Event 1221 estimates free space by calculating the number of empty pages owned by the messages table, the attachments table, and the database root. Free pages that are owned by other tables in the database are not taken into account.

To obtain a closer estimate, you may stop the database and generate a detailed report on free space by typing the following at a command prompt: ESEUTIL.EXE /MS [database.edb] > FREESPACE.TXT

Even on a large database, this procedure will require only a few minutes of downtime.

Note The /MS switch is available only in Exchange Server 5.5 Service Pack 1 or later versions of Exchange.

The following is an abridged example of typical output that would be saved to Freespace.txt:



The first section of the space report is the SLV SPACE DUMP. This reports on free space in the streaming database file (.stm). There are 4710 free pages in the .stm file, and each page is 4096 bytes in length. Therefore, there are 19,292,160 bytes of empty space in the file (4710 x 4096). If you were to defragment this file, you would recover approximately 19 megabytes (MB) of disk space.

Note There is no streaming database for Exchange Server 5.5, and thus no SLV SPACE DUMP section in the space report.

The second section of the space report is the SPACE DUMP. This reports on free space in the database file (.edb). Each table in the database is listed together with the number of pages that it owns and the number of pages owned that are available (empty).

The number at the lower right of the output (20687) is the total of all free pages in the database. If you multiply this number by 4096, you will see that defragmenting this database will recover 84,733,952 bytes of space.

Background information

The Exchange database files Dir.edb, Priv.edb, and Pub.edb grow as needed to handle new data. As old data is deleted, the "holes" in the file are re-used for new data before growing the file size again, but the files never shrink in gross size until an offline defragmentation is performed.

In regular operation, the size of the .edb files will stabilize after a few weeks or months. Significant changes in usage or configuration may change the equilibrium size of the files. Examples of significant changes in usage or configuration include adding or deleting large numbers of mailboxes or adding an Internet gateway. In such cases, offline defragmentation may be helpful to not only reduce file size, but to improve performance and to increase data allocation efficiency, especially with versions of Exchange that are earlier than Exchange Server 5.5 Service Pack 1.

Exchange Server 5.5 Service Pack 1 added significant new capabilities to online defragmentation. While online defragmentation cannot shrink the gross size of the database files, it is now as efficient as offline defragmentation in rearranging file layout for maximum performance.

Offline defragmentation is not a periodically-required Exchange maintenance practice and should be performed only when the events in the application event log tell you that there would be benefit from it, or when you have performed operations that warrant it. The most commonly performed operation that warrants an offline defragmentation is moving a large group of mailboxes off your server.

As a very broad rule, you will probably not obtain long term file size shrinkage unless the amount of free space in your database is ten times the average daily traffic on your server. (Determine daily traffic by adding up the sizes of all the EDBnnnnn.log transaction log files generated on a typical day with circular logging turned off.)

Offline defragmentation is performed with the Eseutil.exe utility's /D switch, and requires stopping Exchange services. Plan for a minimum of 30 minutes of downtime per gigabyte (GB) of data to be defragmented.

Offline defragmentation works by creating a new database and copying pages in use from the old database to a temporary database. Offline defragmentation also discards and rebuilds all indexes.

After all pages in use have been copied to the temporary database, the old database is deleted and the new database file is renamed. We recommend that before defragmentation begins, you have free disk space equal to the size of the database being defragmented. However, you actually must only have free disk space equivalent to the expected defragmented size of the database.

If you run out of space or if offline defragmentation fails for some other reason, no harm is done to your original database. But you should find and manually delete the partial new database to free up disk space. The partial new database is typically named Tempdfrg.edb.

Offline defragmentation can be performed in place or out of place on another server if you are short on disk space. Copy the defragmented .edb file back in place after defragmentation completes. This will, of course, be a much longer process than defragmenting the database "in place."

Make sure that you perform a full online backup after defragmentation. Defragmentation makes dramatic changes to the database without recording those changes in the transaction logs. Therefore, transaction logs cannot be replayed across the point where an offline defragmentation has occurred. If it were to become necessary to restore a pre-defragmentation backup, you would not be able to recover data past the point of defragmentation. After defragmentation, you should consider all previous backups of the database to be invalid.