alphaspirit - Fotolia


Don't forget Exchange 2010 database maintenance

Exchange Server 2010 automatically performs background maintenance on your mailbox databases, but Exchange administrators can't shirk these important database maintenance and monitoring tasks.

Exchange Server 2010 is well into the extended support phase of the product lifecycle, but still remains widely...

deployed; so it must be maintained.

Whether you plan to migrate off Exchange 2010 in the next year or two, or not until the end of extended support in the year 2020, the Exchange 2010 servers that continue to exist in your organization require database maintenance above and beyond what Exchange Server does automatically.

Administrators working on Exchange 2010 or later should keep an eye on database maintenance for a few reasons. Within an Exchange database, online maintenance tasks:

  • Clean up deleted mailboxes and items, and purge those mailboxes and items that have passed the retention period.
  • Scan online databases to look for corrupt database pages.
  • Defragment for data contiguity, which places related database pages close together where they can be read by sequential I/O rather than by random I/O.

Online maintenance for the database runs as a continual background process and as database transactions occur. The Exchange 2010 server continuously performs maintenance on its own databases. But this doesn't mean Exchange administrators have nothing else to do. There are still several Exchange 2010 database maintenance tasks that the admin should perform.

Monitor database backups

Perhaps the most obvious task for an admin is to ensure that Exchange 2010 database backups run successfully. Backups are critical for disaster recovery, but they're also important for database maintenance. An administrator may configure the Exchange 2010 database with retention settings for deleted items and for deleted mailboxes; admins also must specify whether deleted items should be retained until at least one backup has been performed (Listing 1).

Listing 1. This output shows retention times in an Exchange 2010 database for deleted mailboxes and items.

[PS] C:\>Get-MailboxDatabase -Identity DB2010 | Select MailboxRetention,DeletedItemRetention,Retain*

MailboxRetention              : 30.00:00:00

DeletedItemRetention          : 14.00:00:00

RetainDeletedItemsUntilBackup : True

In the output shown in listing 1, the database retains deleted mailboxes for 30 days, and deleted items for 14 days. Both mailboxes and items are retained until a backup has run. If backups are failing, the background Exchange 2010 database maintenance process cannot purge items or mailboxes. This situation causes the database to grow to a larger size than necessary for the organization.

You can verify that backups are successfully completed for a database by running the Get-MailboxDatabase cmdlet (Listing 2).

Listing 2. The Get-MailboxDatabase cmdlet shows if Exchange database maintenance backups are in working order.

[PS] C:\>Get-MailboxDatabase -Identity DB2010 -Status | Select Name,Last*Backup

Name                   : DB2010

LastFullBackup         : 2/12/2016 9:00:51 PM

LastIncrementalBackup  :

LastDifferentialBackup :

LastCopyBackup         :

Monitor database copies

In a database availability group (DAG), each member can host copies of the same database for high-availability purposes. The administrator should monitor replication of database copies between DAG members to ensure each database copy remains healthy. Monitor the health of the copy queue, the replay queue and the content index -- also known as the catalog.

Run the Get-MailboxDatabaseCopyStatus cmdlet to see the health of the database copies in the DAG (Listing 3).

Listing 3. The Get-MailboxDatabaseCopyStatus cmdlet reveals that multiple database copies were suspended.

[PS] C:\>Get-MailboxDatabaseCopyStatus * | Select Name,Status,*QueueLength,ContentIndexState

Name              : DB05\EX2010SRV1

Status            : FailedAndSuspended

CopyQueueLength   : 5721

ReplayQueueLength : 0

ContentIndexState : Suspended


Name              : DB05\EX2010SRV2

Status            : Mounted

CopyQueueLength   : 0

ReplayQueueLength : 0

ContentIndexState : Healthy


Name              : DB06\EX2010SRV1

Status            : FailedAndSuspended

CopyQueueLength   : 5547

ReplayQueueLength : 0

ContentIndexState : Suspended


Name              : DB06\EX2010SRV2

Status            : Mounted

CopyQueueLength   : 0

ReplayQueueLength : 0

ContentIndexState : Healthy

In this example, two of the database copies are unhealthy. This would go unnoticed without active monitoring from the Exchange administrator team, because each database still has at least one other healthy copy that is mounted and able to serve clients. If the server hosting the healthy database copies failed, or if it was restarted for maintenance, the server hosting unhealthy copies would not be able to mount the databases. Forgetting this Exchange database maintenance task would cause an outage for your end users.

This scenario is a good example of why implementing a DAG is not a bulletproof high-availability tactic. Exchange admins still need to monitor and maintain the database copies in the DAG to ensure availability.

Where are you going?

These Exchange database maintenance tasks still apply to Exchange 2013 and 2016. But none of this applies for Office 365, as Microsoft handles all that for you. Consider this as one factor in the decision about whether to migrate to Office 365, Exchange Server 2016 or a hybrid deployment after 2010.

Reclaim disk space

When data is added to a mailbox database, the database file grows larger. As data is deleted from the database, the online Exchange maintenance process reclaims unused database pages, without disrupting operations. Empty pages can be reused for other data; however, the online maintenance process never shrinks the size of the database file itself.

For legacy Exchange deployments, such as Exchange 2010, that have existed in the enterprise over a long period of time, it is common for a mailbox database to grow well beyond the size of the data it contains. This is often referred to as database white space, but is more accurately known as available new mailbox space.

Available new mailbox space is created in two ways: when mailbox items are deleted or when mailboxes are deleted. This, of course, also applies to mailbox migrations. After the deleted or migrated data has passed the retention period, it is purged from the database and the empty pages made ready for new data.

You can see the available new mailbox space by running the Get-MailboxDatabase cmdlet (Listing 4).

Listing 4. In this example, the Get-MailboxDatabase cmdlet retrieves information on the available new mailbox space.

[PS] C:\>Get-MailboxDatabase -Status | Select Name,Available*

Name                     : DB01

AvailableNewMailboxSpace : 850.7 MB (892,043,264 bytes)

In some cases, a significant amount of available new mailbox space exists in a database. The organization could end up maintaining larger storage volumes for the database than necessary, simply because the database file cannot shrink to the actual required size. This bloated storage scenario has a similar effect on the amount of data you need to back up.

The only way to shrink a database file is to perform an offline defrag. As the name suggests, offline defragmentation involves dismounting the database and making it unavailable to end users. Your Exchange deployment will have an outage while the defrag operation runs. The larger the database, the longer the outage.

A better approach, and one that Microsoft recommends, is to create a new database and move mailboxes to it. The new database file will only grow to the size needed to host the mailboxes you move to it; unused space in the old database does not migrate over. Assuming there was available new mailbox space in the old database, you end up with a new database that is smaller than the old one. When the migration is complete, simply remove the old database to reduce your disk space and backup capacity requirements.

Because an offline defrag is riskier, requires more free disk space than the new database will, and involves an outage, use the mailbox migration method to shrink your databases.

Next Steps

Can't delete a database? Here's why

Help: I cannot remount this Exchange 2010 database

Size your next Exchange deployment correctly

Dig Deeper on Exchange Server setup and troubleshooting