Exchange database not shrinking after mailbox move
I have an information store that is 200GB in size that dismounts itself on Exchange 2003. Suspecting some corruption I created another information store and moved the mailboxes. The size of the original information store is still the same size. How can I get this down 0? Do I delete the database and associated stm file?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Just wanted to add to what Mark mentioned. In exchange the physical size of a database does not reduce when you delete or move mailboxes out of it. The size of the file on disk will remain the same until whatever "white space" created by the move\delete has been re-used. To see how much (white space) free space is actually in the database run the following command (also shows the total database size):
Get-MailboxDatabase DatabaseName -Status | FL AvailableNewMailboxSpace, DatabaseSize
Over half of me is thinking that you probably need to get a consultant in for a day to to help you out with a bit of mentoring to make sure you delete the right things. The flipside is that you could just defrag the store and that might be safer. Unfortunately I think that would rear up just as many questions on what the proper syntax is.
I'll try and be as final and clear as I can here.
Make sure there is only one store under that storage group. You can see that from the management console.
Make sure you write down the paths to the logs and the store. They are in different places (properties of the storage group and properties of the store) so yes, you have to do two actions. Yes, when you look at the logs you will see two paths. They should be the same. If they are not the same you will ultimately write down three paths.
Dismount the store.
Delete the files.
Remount the store.
Accept the warnings.
Get-MailboxDatabase DatabaseName -Status | FL AvailableNewMailboxSpace, DatabaseSize
Over half of me is thinking that you probably need to get a consultant in for a day to to help you out with a bit of mentoring to make sure you delete the right things. The flipside is that you could just defrag the store and that might be safer. Unfortunately I think that would rear up just as many questions on what the proper syntax is.
I'll try and be as final and clear as I can here.
Make sure there is only one store under that storage group. You can see that from the management console.
Make sure you write down the paths to the logs and the store. They are in different places (properties of the storage group and properties of the store) so yes, you have to do two actions. Yes, when you look at the logs you will see two paths. They should be the same. If they are not the same you will ultimately write down three paths.
Dismount the store.
Delete the files.
Remount the store.
Accept the warnings.
And dont forget...... Disk space! You need, on average, one and a half times the free disk space available as the size of your database you are defragging to be safe.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
btw 1221 shows the whitespace amount and is trigged per DB. forgot to mention that above.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Ok. Thanks for all the useful advice. Since I have moved the mailboxes off the problematic Information Store, I do not need the old one. Can I just delete it and be done with it?
If you have moved your all mailboxes then you can delete it.
yes you can delete the DB files and be done with them, however, you may want to keep the instance of the DB in the Exchange management console and mount it up again as a black EDB so that you have a fresh EDB to move users to in the future.
instead of deleting it you could also run an eseutil /p and isinteg along with a eseutil /d for defrag. that would repair the database at both levels and defrag it to reduce the size down.
Sorry but I have to STRONGLY disagree because
1. /P is a very dangerous last ditch or crud I have no backup command that will certainly help you moving towards the ability to mount a database that has corruption, but ABSOLUTELY should NOT be run EVER on a healthy database.
2. isinteg and eseutil /D are not relevant here either because there are no mailboxes within the database the customer cares about and therefore doing eseutil and isinteg commands against a DB that is large but no mailboxes is a colossal waits of time and resources.
1. /P is a very dangerous last ditch or crud I have no backup command that will certainly help you moving towards the ability to mount a database that has corruption, but ABSOLUTELY should NOT be run EVER on a healthy database.
2. isinteg and eseutil /D are not relevant here either because there are no mailboxes within the database the customer cares about and therefore doing eseutil and isinteg commands against a DB that is large but no mailboxes is a colossal waits of time and resources.
Furthermore IF you are ever in the position of having to do a /P against a database then yes you would want to run isinteg and eseutil /D against that database and once done mount the database and immediately MOVE the mailboxes to a new database and then get rid of the old db. The reason its important to get off the /P database is that in my experience once a DB has to be /P its compromised and should be replaced ASAP else you are sure to have some future issues. FYI, we are an ISV that specializes in the optimization, protection, recovery and discovery/searching Exchange databases and have seen this fatal mistake made way too many times
ASKER
Good information. Thank you all for all your help. I will delete the DB files and then the only thing I will have in that information store will be the public folders.
Thanks for the points!
Even if you have moved the mailboxes out, the stores are configured to retain data for a set period of time, so the information can still be recovered, but don't expect the size to reduce as Exchange stores only grow without manual intervention.