Offline defragmentation in an Exchange 2007 CCR environment

by Jaap Wesselius [Published on 22 Dec. 2010 / Last Updated on 22 March 2010]

this tip deals with an offline defragmentation when using a CCR cluster

When you move mailboxes from one Exchange database to another, or you delete a large amount of mailboxes you will end up with Exchange databases that have a lot of white space in them. But the size will never decrease, until you perform an offline defragmentation of this particular database.

When an offline defragmentation is performed a new Exchange database is created and all database is copied from the ‘old’ database to the ‘new’ database. When finished the ‘old’ database is deleted. The gotcha here is that a new database is created, with a new database signature etc.

When an Exchange 2007 CCR environment is used this can be a problem since both the active and the passive copy are the same from a logical perspective. So when you have to perform an offline defragmentation of an Exchange 2007 database that’s part of a CCR cluster, the passive copy has to be updated as well, i.e. a seeding has to be performed after an offline defragmentation.

Follow these steps to perform an offline defragmentation in a CCR environment:

  1. Disable the replication: Suspend-StorageGroupCopy –Identity SERVER\StorageGroup;
  2. Dismount the Database;
  3. Perform the actual offline defragmentation with ESEUTIL /D “mailbox database.edb”
  4. Mount the new database;
  5. Delete the old passive copy and its accompanying log files;
  6. Seed the copy: Update-StorageGroupCopy –Identity SERVER\StorageGroup;
  7. Start replication: Resume-StorageGroupCopy –Identity SERVER\StorageGroup

This will always result in a certain downtime. How much downtime you might ask? Suppose you have a 200 GB mailbox database, and only 100 GB is used, then 100 GB will be copied during the Offline Defragmentation. Depending on the hardware you use you'll see an average throughput of 10 GB/hour, which means a downtime of 10 hours in this particular scenario.

To prevent this downtime a better (and recommended) solution is to create a new Mailbox Database and move all mailboxes from the ‘old’ database to this new database. When finished the old database can be deleted. This will result in less downtime for your end users.

Featured Links