Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1399
  • Last Modified:

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?
1
InSearchOf
Asked:
InSearchOf
  • 5
  • 3
  • 2
  • +4
3 Solutions
 
Madan SharmaConsultantCommented:
You have to run an offline defragment on this database and it will be shrink. To know how to defragment a database visit this link:- http://support.microsoft.com/kb/328804
0
 
jennylembertCommented:
Exchange Mail-stores NEVER shrink in size unless you take them offline and defrag them with ESEUTIL /D. If you have moved the mailboxes to another store - delete the old store and then create a new one.

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.
0
 
mvsnaniouCommented:
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.
0
Configuration Guide and Best Practices

Read the guide to learn how to orchestrate Data ONTAP, create application-consistent backups and enable fast recovery from NetApp storage snapshots. Version 9.5 also contains performance and scalability enhancements to meet the needs of the largest enterprise environments.

 
Neil RussellTechnical Development LeadCommented:
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.
0
 
gleekCommented:
On the exchange server look at the Event logs and check for 1221.  This is the message that completes after Exchange online maintenance.  As the posters above stated you need to perform an Offline Defrag.  By looking at the whitespace that is available you can determine the amount of space you can potentially get back during the defrag process.

I'm not sure how many different databases you have but sometimes to juggle space when you have little to spare whitespace can be helpful.  You can move mailboxes to a database that has lots of whitespace availible and the mailbox will take up the whitespace first before increasing the overall size of a database.

For example.  Database A has 100 gb in size..  Database B is 100gb in size but 30gb of that is whitespace.  You can take 30gb of mail data off of Database A, move it to database B and the total size of database B will not increase since the mailboxes just took up the whitespace.   (this is a simplistic overview but relevant for the example)

How this helps is when you have databases on different drives and not enough space to perform an offline defrag because it requires free space on the drive of 150% of the database size you are defragging.
0
 
gleekCommented:
btw 1221 shows the whitespace amount and is trigged per DB.  forgot to mention that above.
0
 
lucid8Commented:
ok but the key here is that Dfig said that all the mailboxes were already MOVED to a new database, correct?  if so then its a waste of time to defragment the database, best thing to do is to dial-tone it, i.e.

1. Be darn sure all mailboxes are moved

2. Take that database offline

3. I would suggest copying the files to an alternate location OR renaming the EDB and STM just to ensure you have a way to get back to the data if need be, i.e. if names are MB1.edb and STM then rename to OLDMB1.edb and stm.  

4. Mount the mailbox database.  Exchange will squawk that the database files are missing and that if you continue you will create new database files.  Say yes and new files are created.  

5. Now even if there are still users assigned to this DB they will continue to send and receive email however all the old email will  be gone, therefore I would strongly suggest that you copy that OLD EDB and STM file to a safe location or do a flat file backup of it so that IF you find that someone wasn't really moved you can mount it in an RSG for recovery.  Once that's done you can delete the old files and your good to go and have recovered 200GB.
0
 
InSearchOfAuthor Commented:
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?
0
 
Madan SharmaConsultantCommented:
If you have moved your all mailboxes then you can delete it.
0
 
lucid8Commented:
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.
0
 
gleekCommented:
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.
0
 
lucid8Commented:
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.
0
 
lucid8Commented:
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
0
 
InSearchOfAuthor Commented:
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.
0
 
lucid8Commented:
Thanks for the points!
0

Featured Post

Prep for the ITIL® Foundation Certification Exam

December’s Course of the Month is now available! Enroll to learn ITIL® Foundation best practices for delivering IT services effectively and efficiently.

  • 5
  • 3
  • 2
  • +4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now