Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

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


View products that this article applies to.

Summary

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.

↑ Back to the top


More information

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:
The database has 151 megabytes of free space after online defragmentation has terminated.


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:

Microsoft(R) Exchange Server Database Utilities

Version 6.5

Copyright (C) Microsoft Corporation. All Rights Reserved.



Initiating FILE DUMP mode...
         Database: priv1.edb

****************************** SLV SPACE DUMP ******************************
Chunk          Free Res Del Com  |------------ Used ------------|           
============================================================================
512             110   0   0 402  *************************
1024            505   0   0   7  
1536              0 509   1   2  ********************************
2048            512   0   0   0  
2560            511   0   0   1  
3072            512   0   0   0  
3584            512   0   0   0  
4096            512   0   0   0  
4608            512   0   0   0  
5120            512   0   0   0  
5632            512   0   0   0  
============================================================================
TOTALS:
         Free:         4710
     Reserved:          509
      Deleted:            1
    Committed:          412
      Unknown:            0
              -------------
                       5632
****************************************************************************


******************************** SPACE DUMP ***********************************
Name                   Type   ObjidFDP    PgnoFDP  PriExt      Owned  Available
===============================================================================
priv1.edb               Db           1          1   256-m      24064      19726
<SLV Avail Map>         SLV          6         33    32-m         32         29
<SLV Owner Map>         SLV          7         65    32-m         64         10

1-103C1                 Tbl        793       2073     8-s          8          3
  MsgFolderIndex7       Idx        795       2074     1-s          1          0
  MsgFolderIndexPtagDel Idx        798       2077     1-s          1          0
  MsgFolderIndexURLComp Idx        797       2076     1-s          1          0
  RuleMsgFolderIndex    Idx        796       2075     1-s          1          0
. . . .
1-23                    Tbl         61        236     2-m        226         15
  <Long Values>         LV        1439        619     1-m        137          9
. . . .
Msg                     Tbl         19        112     2-m        866         53
  <Long Values>         LV         106        359     1-m         16          0
-------------------------------------------------------------------------------
                                                                          20687

Operation completed successfully in 6.89 seconds.


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.

↑ Back to the top


Keywords: KB195914, kbinfo, kbhowto

↑ Back to the top

Article Info
Article ID : 195914
Revision : 9
Created on : 10/25/2007
Published on : 10/25/2007
Exists online : False
Views : 679