Exchange databases need maintenance. This maintenance defragments the databases, reindexes the databases and performs other tasks necessary for long-term sustainability of the databases.
To configure maintenance, open the Exchange Management Console and then under Organization Configuration select Mailbox.
At the Database Management tab, double-click on the database to schedule maintenance for and click on the Maintenance tab. Here, check the box for Enable background maintenance and then select one of the schedules for which Exchange maintenance occurs. This schedules a nightly database maintenance window where Exchange Server can perform the necessary operations on a given database.
Alternatively, if you have a lot of databases or need to batch change these things, or just want to do so through PowerShell ’cause you’re that frickin’ awesome, use the Set-MailboxDatabase cmdlet in PowerShell. To do so, open PowerShell from within Exchange and then run the Set-MailboxDatabase cmdlet along with -identity followed by the quoted name of the server\name of the database and then use the -MaintenanceSchedule option to identify the schedule (which should also be quoted), as follows:
Set-MailboxDatabase -Identity "Exchange\MailboxDatabase" -MaintenanceSchedule "Sun.2:00-Sun.6:00"
Alternatively there are two other ways to get an Exchange database defragmented. The first is to manually defrag the database using a tool called eseutil. In this case, you’ll encounter from 5 to 20 minutes of downtime per gig of the Information Store. To do so, run esetuil. You can run the tool, specifying that you are defragmenting a /d for database and /ds for the directory. You will need enough space on the drive with the edb files on it to make a copy of the database (double-click on an Information Store to see the path). In this example we’ll specify a temporary directory to use for defraging on another volume, as follows:
eseutil /d /ds /tc:D:\backup\eseutildefrag.edb /p
Note: To use a temporary volume increases the amount of time per gig to defrag the database.
In todays email archival and retention cycles databases are growing to ridiculous numbers though. Therefore, offline defragmentation is often no longer an option. So the second option for manual defragmentation is to actually spin up another database, perform a Local Move Request of all users to the new database and then delete your original production database. Doing so allows you to move users without impacting their ability to work, get the size of the total Information Store(s) down and also get a squeaky clean database in the process.