Exchange 2010 Whitespace reclamation

Some of you may be aware of a scenario in which the reclamation of Exchange 2010 database whitespace during item deletion or truncation is not as great as expected. So why is this a problem for Enterprise Vault customers?

Archiving data from a mailbox will frequently invoke either a deletion or truncation request to the Exchange server. If Exchange is not fully honouring this request then the database from which a customer is archiving will continue to grow as pending whitespace reclamation requests are not processed fully and available whitespace is not recognised.

The good news is that Microsoft have recognised and now resolved the issue: http://support.microsoft.com/kb/2621266

 

So what was the problem?

In summary the primary complaint was that in some cases Exchange 2010 customers were noticing that their mailbox databases were continuing to grow even though archiving was taking place and items were being archived as normal. The root cause of this was actually down to how Exchange reclaims whitespace and specifically the changes to this process in Exchange 2010. Modifications to the Online Defragmentation process caused, in some cases, whitespace to not be reclaimed for re-use essentially making that space unusable.

MS have now issued a fix which corrects the action of Online Defragmentation allowing customers to reclaim the excessive whitespace that has been building up in their databases.

 

For more information I highly recommend a read of the following technote: http://www.symantec.com/business/support/index?page=content&id=TECH164949&cache=refresh and my colleague’s blog here: http://www.symantec.com/connect/blogs/exchange-2010-whitespace-reclamation

 

Alex Brown

1 Comment

Issue now has publically available resolution with Exchange 2010 SP2 with HFRU1.  We've been testing with the interim patch for SP1 HFRU6 and it was successful, but doesn't cleanup the already existing mess.  So we waited for the public release, installed, created new databases and migrated all the mailboxes over to their new location.  Reclaimed about 40% of "invisible" white space in the process.

SP2 went in cleanly and easily enough.  HFRU1 did take a while to generate though, so a little more pateniece there is required.