Probably one of the most asked about topics, yet I've been searching the internet and can't find the answers to my questions below... From what I understand, Exchange 2007 online defrag consolidates the whitespace in an Exchange database. This is then reported in Event ID 1221 (DB has x 'free space'). I know we can run offline defrags (or store evacuations) to clear this, but what I'm not so sure about is: - Will Exchange ever use this white space? From what I've read, when the database needs to grow, it will use the whitespace area for expansion, so that the actual edb file doesn't increase in size. - If I had, say a 100GB database with 40GB white space. Should I leave Exchange to use up this space itself or should I offline defrag/ store evacuate and delete? - I have heard that a lot of places carry out store evacs (they move users out of Store1 to Store2, delete Store1 and recreate, then move users back to Store1 which now has no white space) to keep a lid on their database sizes. If Exchange *does* use the whitespace, then what's the point of doing this? Let's say the drive size was 110GB. The Database size was 100GB, of which 40GB was Whitespace. Now, that would ring alarm bells since there is only 10GB left on the drive, but since there is so much whitespace, surely the db won't grow in size since Exchange will use the whitespace for any growth? And, as long as there was whitespace, we could be confident that the db size wouldn't increase? This question relates to Exchange 2007/2003.

You are correct with your first bullet point. Exchange will first use/reuse the whitespace before it grows the .edb file. As for the rest, you should never have to defrag an exchange database. There I said it! This is something you do when you run into physical disk limitations, but it is not part of any Exchange maintenance schedule. Mike Crowley Check out My Blog!

To add to what Mike said: http://restartis.wordpress.com/2009/05/26/does-exchange-2007always-use-whitespace-available-in-a-database/ - Thanks, Jinesh.

so there is no other way to shrink down the DB size even by doing full backup everyday ?/* Server Support Specialist */

You can reduce the db size by 1) running an offline defrag 2) moving users off the database, deleting the database file(s) and letting Exchange create a new empty .edb (and .stm in old versions) file. As mentioned earlier in this thread there's usually no need to be doing either of these things routinely. A lot of admins seem to like to go hands-on and run these operations frequently, but really most people can just leave Exchange alone to manage the whitespace. They are both disruptive to users and open up risks and the chance for an administrator error. It does make sense though if you have a situation where you have multiple databases on the same disk volume and one of them has gotten bigger than it's "fair share" - so you do some re-balancing, mailbox cleanup, whatever and then you want to reduce the physical size (file size) of the database. One could argue that that situation could have been avoided with better design, quotas and monitoring but ... that's how you would fix it. A full backup won't affect the database size but it will cause the transaction logs to be cleared off the drive.

Ah ok, so creating new database and then migrating it manually from the EMC is the way to go in case it reach 95% full/* Server Support Specialist */