Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Wednesday, September 16, 2015 12:15 PM
How can I reclaim database space after mailboxes are removed from store to store?
All replies (8)
Wednesday, September 16, 2015 12:43 PM ✅Answered
You can shrink the existing database (Rhoderick Milne, a senior PFE with Microsoft, wrote a blog on this a while ago) only by taking it offline and compacting it, during which time, your users will not be able to access their mailboxes. However, unless your database has filled its drive, you don't need to do that - Exchange will reuse the whitespace in the database before it adds to the database size. It will also work to ensure that the whitespace is used efficiently.
I'll add that when we removed half the data from our mailbox databases (because we implemented retention and deleted half our mailbox data), we moved the remaining mailboxes from the database and deleted them. We then moved the mailboxes back into the (now empty) databases. This simplified the process of "database compaction" and enabled our users to have full access to their mailboxes during the time we "compacted" the database (except for a small time period when their mailbox move was completing, which we scheduled to run during off hours).
HTH ...
Will Martin ...
-join ('77696c6c406d617274696e2d66616d696c6965732e6f7267' -split '(?<=\G.{2})' | ? { $_ } | % { [char][int]"0x$_" })
Wednesday, September 16, 2015 12:48 PM ✅Answered
So there are a few ways to handle this
OPTION A: Do nothing and let the white space be reused by new data mailboxes
OPTION B: You can run an offline defrag using ESEUTIL /D however to do so consider
- This is an offline process, i.e. users will not be able to access email during this time
- Processing time wise your looking at about 4-6GB an hour so usually best to do after hours/over a weekend
- You should make a backup of the offline EDB before starting the process just in case something goes awry
- You will need 115% of free disk space to defrag the DB
- If you want something to automate this for you check out http://www.lucid8.com/product/preventative.asp
OPTION C: Do a mailbox move of remaining mailboxes and then a dial tone to reclaim space
- If there are still mailboxes within that data you need to move ALL of them to another database. This is an online process so should provide very little pain in terms of user downtime
- However the process will generate allot of logs so plan accordingly, i.e. do incremental backups or temporarily switch the circular logging for those DB's
- Once all the mailboxes are moved from that data base you can then; 1. Dismount the DB, 2. Delete the EDB and associated log files from disk (or rename the folders their located in a create a new folder of same name that's empty. 3. Attempt to Mount the DB and Exchange will complain that the DB file is not there and if you continue it will create a new DB. 4 Say yes and a new blank EDB will be created and will use very little disk space. 5. This DB is now small and ready to be used for new mailboxes, mailbox migrations etc.
Search, Recover, & Extract Mailboxes, Folders, & Email Items from Offline Exchange Mailbox and Public Folder EDB's and Live Exchange Servers or Import/Migrate direct from Offline EDB to Any Production Exchange Server, even cross version i.e. 2003 --> 2007 --> 2010 --> 2013 with Lucid8's DigiScope
Wednesday, September 16, 2015 3:55 PM
On the list from Troy above, only C is the option I ever consider. I have never done an offline defrag on Exchange 2007 or higher, and have no intention of doing so. Why do something where there is risk of data loss and downtime, when you can resolve the issue with no downtime and no risk?
Simon.
Simon Butler, Exchange MVP
Blog | Exchange Resources | In the UK? Hire Me.
Wednesday, September 16, 2015 3:58 PM
Agreed option C is the least disruptive
Search, Recover, & Extract Mailboxes, Folders, & Email Items from Offline Exchange Mailbox and Public Folder EDB's and Live Exchange Servers or Import/Migrate direct from Offline EDB to Any Production Exchange Server, even cross version i.e. 2003 --> 2007 --> 2010 --> 2013 with Lucid8's DigiScope
Wednesday, September 16, 2015 8:18 PM
Actually, option A is the least risky. There's no reason to remove whitespace unless the system is at a hard stop, since the system will reuse it.
If you need to remove whitespace, as the second paragraph of my first response and Troy's C option state, you can do it with minimal affect on the remaining mailboxes.
Will Martin ...
-join ('77696c6c406d617274696e2d66616d696c6965732e6f7267' -split '(?<=\G.{2})' | ? { $_ } | % { [char][int]"0x$_" })
Wednesday, September 16, 2015 8:49 PM
Hi,
I'm in agreement with Will here. If there's no strong reason to move mailboxes and recreate a mailbox database then it's best to leave as is. Option B is generally not a good idea because of the amount of downtime that's required.
If you want, you can set up a script to report on the usage of the available whitespace:
Get-MailboxDatabase -Status | fl name,*available*
I hope this helps.
Thanks.
Mark Gossa
MCSE 2003, MCITP Enterprise Administrator 2008 R2, MCSA 2012 R2, MCTS Exchange 2010
Blog: http://markgossa.blogspot.com
Posts are provided “AS IS” without warranty of any kind, either expressed or implied.
Thursday, September 17, 2015 12:46 AM
Thanks Will!
In addition to the impact of the offline defrag post, I'd also add this one as well:
I certainly agree that move mailbox is the way to go, since we have the online move mailbox process.
Cheers,
Rhoderick
Microsoft Senior Exchange PFE
Blog: http://blogs.technet.com/rmilne Twitter:
LinkedIn:
Facebook:
XING:
Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.
Thursday, September 17, 2015 2:45 AM
Hi,
Please have a look at above links and blog.
I suggest you can create a new DB an move the mailboxes over to it.
Additionally, I have found a similar thread for your reference ；
Regards,
David