How to: Compact the size of an Exchange Mailbox Database

How to: Compact the size of an Exchange Mailbox Database

As of late I have been working on moving mailboxes form an onPremise deployment to the cloud in a hybrid environment. As I made progress I noticed the servers that hosted the Mailbox databases were using a lot of hard drive space and that backups were huge. Even after moving the mailboxes over to the cloud the space was not returned to the OS. This made me wonder, what really is going on with an Exchange Database. After doing some reading around the first thing I found was that Exchange logs every transaction and is able to reconstruct the entire database out of those logs. This roughly means you are storing about twice the amount of information that what you actually have. You can either use a backup application that clears those logs or enable circular logging. If you want to learn more about that there is an article titled: What is: Circular Logging in Microsoft Exchange Server.

So, at this point the first thing to do is address the issue around not cleaning up the database log files. But then you realize that the database even though its mailboxes are using a few megabytes of data has a size in the gigabytes. What happens is the Exchange mailbox database is sort of like a SQL database, it grows in size, reserves more space from the hard drive…. but unlike SQL there is no way to schedule a maintenance job to shrink the database. I guess this makes sense… an email database ought to grow 99% of the time. Even if a user starts purging their emails there are others and that space will be used again shortly in general. The solution to this lies in running a utility to defragment the database and therefore release the space that is not in use back to the OS. Now, as I pointed out there is no reason to do this generally. In my particular case as I moved gigabytes worth of data to another database that space is not going to get used any time soon in the foreseable future. The issue here is that in order to defragment the database you need to bring it offline and that will have an impact on the users whose mailboxes are stored in that db.

Another alternative worth exploring is creating another Mailbox store and transfering the mailboxes from your old db to the new one. The new db would use only the amount of space needed to store the emails and after the transfer is completed you can delete the other database off the system. Using this method would ensure you don’t leave all your users without email for a long time. If you want to learn how to move all the mailboxes from one database to another you can read this article: How to: Move Mailboxes to another Exchange Server 2013

So in summary:

1. Be sure to use a Microsoft Exchange compatible backup utility so that your database logs are cleared frequently. If you have another solution in place you might want to look into circular logging.
2. Use eseutil -d “Mailbox Database 1.edb” to defragment your database after a large purging of emails. Remember that it has to be offline for this to work
3. Transfer your mailboxes to another database and delete the source one once done. Remember there might be Archive, System and other kind of mailboxes besides user ones.

In order to use eseutil here is the information regarding syntax for the defragmentation of the db:

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 15.00
Copyright (C) Microsoft Corporation. All Rights Reserved.

DESCRIPTION: Database utilities for the Extensible Storage Engine for Microsoft(R) Exchange Server.

MODES OF OPERATION:
Defragmentation: /d <database name> [options]
Recovery: /r <logfile base name> [options]
Integrity: /g <database name> [options]
Checksum: /k <file name> [options]
Repair: /p <database name> [options]
File Dump: /m[mode-modifier] <filename>
Copy File: /y <source file> [options]
Restore: /c[mode-modifier] <path name> [options]

<<<<< Press a key for more help >>>>>
D=Defragmentation, R=Recovery, G=inteGrity, K=checKsum,
P=rePair, M=file duMp, Y=copY file, C=restore
=>
DEFRAGMENTATION/COMPACTION:
DESCRIPTION: Performs off-line compaction of a database.
SYNTAX: /d <database name> [options]
PARAMETERS: <database name> – filename of database to compact
OPTIONS: zero or more of the following switches, separated by a space:
/t<db> – set temp. database name (default: TEMPDFRG*.EDB)
/p – preserve temporary database (ie. don’t instate)
/b<db> – make backup copy under the specified name
/2 – set 2k database page size (default: auto-detect)
/4 – set 4k database page size (default: auto-detect)
/8 – set 8k database page size (default: auto-detect)
/16 – set 16k database page size (default: auto-detect)
/32 – set 32k database page size (default: auto-detect)
/v – verbose output
/o – suppress logo
NOTES: 1) If instating is disabled (ie. /p), the original database
is preserved uncompacted, and the temporary database will
contain the defragmented version of the database.

Below is a sample execution of the eseutil command to defragment and offline database:

[PS] E:Exchange DBs>eseutil -d “Mailbox Database 1.edb”

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 15.00
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating DEFRAGMENTATION mode…
Database: Mailbox Database 1.edb

Defragmentation Status (% complete)

0 10 20 30 40 50 60 70 80 90 100
|—-|—-|—-|—-|—-|—-|—-|—-|—-|—-|
……………………………………………
Moving ‘.TEMPDFRG6624.EDB’ to ‘Mailbox Database 1.edb’… DONE!

Note:
It is recommended that you immediately perform a full backup
of this database. If you restore a backup made before the
defragmentation, the database will be rolled back to the state
it was in at the time of that backup.

Operation completed successfully in 97.625 seconds.