Why Is My Exchange 2010 Mailbox Database Growing So Big?

A reader asks:

We recently migrated to Exchange Server 2010 and now not only is the mailbox database much larger than it was in Exchange Server 2003 but it seems to be growing a lot faster as well. Why is this happening?

In a perfectly healthy Exchange Server 2010 environment this difference in size and growth rate compared to Exchange Server 2003 is completely normal.

The first reason is the removal of single instance storage from the Exchange Server 2010 database schema. I’ve written about this before so I’ll just briefly recap it here. Microsoft determined that single instance storage was producing a rapidly diminishing benefit to Exchange customers while at the same time inhibiting improvements to the database disk I/O performance. So the decision was made to remove single instance storage in favor of an improved database schema that delivers as much as 70% reduction in disk I/O requirements.

What this means is that when migrating from Exchange 2003 to Exchange 2010 a mailbox database that hosts the exact same mailboxes can easily be 20-50% larger immediately after the migration has occurred. I’ve even heard from some Exchange specialists that they’ve seen up to 5x size increase with some customers. The ongoing growth rate of the database will also be higher for the same reason.

In addition to this the Exchange Server mailbox database has some retention settings that customers can configure to suit their environment.

[PS] C:\>Get-MailboxDatabase MB-HO-02 | fl *retention*

MailboxRetention            : 30.00:00:00
DeletedItemRetention        : 14.00:00:00
EventHistoryRetentionPeriod : 7.00:00:00

Most people are already familiar with the deleted items retention and deleted mailbox retention settings that default to 14 days and 30 days respectively. There is also the event history retention period that adds to the size of the store, although I would not expect this to be a root cause of massive database growth.

Although deleted item retention is set by default to 14 days, this can be as much as 30Gb of data per mailbox if the recoverable items quota is left at its default setting.

[PS] C:\>Get-MailboxDatabase MB-HO-02 | fl recoverable*

RecoverableItemsQuota        : 30 GB (32,212,254,720 bytes)
RecoverableItemsWarningQuota : 20 GB (21,474,836,480 bytes)

Another reason for increased database growth can be the large default mailbox quotas in Exchange Server 2010.

[PS] C:\>Get-MailboxDatabase MB-HO-02 | fl *quota*

ProhibitSendReceiveQuota     : 2.3 GB (2,469,396,480 bytes)
ProhibitSendQuota            : 2 GB (2,147,483,648 bytes)

If these are left at their default value deliberately or because they were overlooked during deployment, and as a result end users are not receiving warnings to delete mailbox items to stay under quota, then their mailboxes will naturally grow larger at a faster rate than before.

Should you be concerned about your Exchange 2010 databases growing too big?

Well considering that previous versions of Exchange Server had recommended maximum database sizes of 100Gb (or 200Gb for Exchange 2007 CCR clusters). However in Exchange Server 2010 this recommendation has increased to 2Tb.

With the significant core improvements made to Exchange 2010, the maximum recommended mailbox database size when using continuous replication has increased from 200 gigabytes (GB) in Exchange 2007 to 2 terabytes in Exchange 2010.

However this is only when database replication (ie a Database Availability Group) has been deployed. For non-replicated mailbox servers you should consider your recovery SLAs and size databases according to how quickly you can recover them from backups in a disaster.

So in summary, some increase in mailbox database size is normal for Exchange Server 2010, and as long as you’re managing database sizes in line with your recovery SLAs then there should be no problem.  However if you are concerned there are a number of database configuration settings that you can look into for reducing the size and growth rate of your mailbox databases.