From time to time we need to see how our Exchange databases are doing so that they are being managed proactively. One aspect is tracking size and the utilization of each database. At the simplest level we want to ensure that the database and transaction log LUNs do not run out of disk space. That would be bad.
Sometimes we want to take a peek at the database, and check that the size of the database is within design expectations. We can look at the amount of user data stored in the database, system usage for recoverable items in addition to looking at the size of the database on disk. Some folks also want to see the blank space that is within a database. This blank space is sometimes called:
-
Available Mailbox Space
-
White space
-
Free database pages
-
Free space
Historical Approach To Checking White Space
In ye olden days when Exchange admins went to work on horses (alright, iron horses), we would look for the venerable application event log entry 1221. This event would tell us the amount of white space within the database. This event was introduced in Exchange 5.5 SP1 back in August 1998. That’s more than 15 years ago, eeek!!
In those simple Exchange days we would have one Public Folder (pub.edb) and one Mailbox database (priv.edb) per server. Standard Edition could have a database of up to 16GB, and Enterprise had the “unlimited” database. This was before the advent of the .stm file so all content lived in the .edb file. Event ID 1221 would then report on the white space contained within the database file. Life was indeed simple and good! Additionally Exchange 5.5 SP1 also added a second enhancement for determining white space which was the ESEUTIL /MS switch to dump out the space consumed by tables in the database. More on this later….
As mentioned in the KB, 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.
Things advanced, the dotcom bubble popped and with the advent of Exchange 2000 the streaming file was introduced. The intent was to store native RFC content in the streaming file as the Internet was the future and content would be converted between the .stm and .edb as needed. Event 1221 does not review this shiny streaming thingymabob, and did not report what free space may have been available within the .stm file. For a trip down memory lane there is an excellent read in this document Determining the True Amount of Space in an Exchange Database
If ESEUTIL /D was executed against a database the .stm would have been defragmented in addition to the .edb by default. Though this could be changed by specifying the /I switch. Details on defragmenting databases are can be found in this KB.
Exchange 2007 dropped the .stm file and just like Atomic Kitten, the .edb became whole again. Event 1221 was still with us and reporting on the database white space!
Then along came Exchange 2010, sans Event ID 1221….
Getting White Space In Exchange 2010
Exchange 2010 introduced numerous improvements to the Mailbox role. These improvements included things like
- Enhanced ESE physical store to improve performance
- Larger 32 Kb ESE page size
- Dumpster 2.0
- No database level attachment table
- Updated Online Maintenance routines
As part of the changes to the mailbox role, the venerable event ID 1221 was removed, and output was added to Get-MailboxDatabase called AvailableNewMailboxSpace. This data is returned when the –Status parameter is also specified to execute the more expensive work items. We can see the difference below, note the second command has –Status added:
So NewAvailableMailboxSpace looks good? Well not so much. This parameter only looks at the root portion of the database. This is clearly stated in the Exchange team blog post. For reference the relevant text is shown below.
Remember we would come back to ESEUTIL /MS?
We need to use ESEUTIL /MS to get an accurate picture of white space in an Exchange 2010 database.
Running ESEUTIL /MS against a lab database shows the following:
From this we can see the breakdown in the database structure and where space is being consumed. Note that this can only be executed against a dismounted database, and you will receive the following error if running against an active mailbox:
Operation terminated with error -1032 (JET_errFileAccessDenied, Cannot access file, the file is locked or in use)
And if you are thinking that I’ll be sneaky and run it on a passive database copy in a DAG, then you will receive this error instead, after stopping the replication service else you will get the same error as listed above:
Operation terminated with error -550 (JET_errDatabaseDirtyShutdown, Database was not shutdown cleanly. Recovery must first be run to properly complete database operations for the previous shutdown.)
Conclusion
To get an accurate representation of the amount of white space in an Exchange 2010 database we need to use ESEUTIL /MS. Note that the database must be dismounted, else you will receive JET errors and no data will be returned.
Dumping out the table information is a fairly quick operation, unless the verbose /V option is used and then the time taken will greatly increase.
How often do I expect this to be used? Rarely and typically as part of troubleshooting.
The days of online maintenance killing itself trying to defragment partially filled 4K pages of data to be on a single ESE page are gone. The same goes for offline defragmentation. We now live in a world where large mailboxes are the norm and any white space will be quickly re-used. Also consider that many organisations are now running 24 * 7, and it is hard to justify the impact caused by taking a database offline.
Defragmenting databases to reclaim whitespace should be a rare event nowadays. Exchange 2010/2013 are designed to use larger and cheaper storage which means you can get more storage capacity for the same price point. Rather than defragmenting databases we should look to leverage the online mailbox move experience in Exchange 2010/2013 and simply move mailboxes to a new database and then discard the original one. This is critical when we are discussing DAG replicated databases.
Cheers,
Rhoderick
