Our company is running Exchange 2003 on Server 2003. Our primary exchange store file (priv1.edb) keeps growing and is now at over 45GB. If I add up the size of the mailboxes in that store I get less than 16GB. I ran an offline defrag but didn't regain even a single KB from the .edb file (the .stm file shrank from 8GB to 2GB). I've also looked up the size of the Recoverable Items using Performance and it seems insignificant (not sure if the display is in bytes or KB, either way it would not account for the discrepancy). How do I find out what is taking up all this space, and more importantly, how do I remove it?
|
feedback
|
|
Are you getting good online backups? My guess is that you're not, and as a result you're seeing delete items piling up instead of being cleaned up. That would be consistent with the lack of any decrease in size that you saw with the offline defragmentation. You can force deleted item retention to delete items even if the Information Store hasn't had a good online backup, but I'd recommend fixing your backups first if that turns out to be the culprit. If you want to try it, untick the "Do not permanently delete mailboxes and items until the store has been backed up" on the "Limits" tab of the Mailbox Store's properties. Let us know how it turns out. | |||
feedback
|
|
An offline defrag should reduce your database size. Do you have public folders in the same database that are increasing the size? What is your deleted item retention period set to? Are you including the log size with your EDB file (if so, is it being backed up?) These are just some things to check into. The most likely culprit is the retention period though. | |||
feedback
|
|
Look for Event ID 1221 in your Application Event Log. This will tell you how much free 'white space' is in your Exchange DB. Also see: Event ID 1221 reports less free space than should be the case | |||
feedback
|
|
The best solution to strange database issues like this is to create a new, empty store and move mailboxes to it; this achieves the same effect as a full database defragmentation, allows you to check for database corruptions and doesn't create a prolonged downtime for your users. | |||||||
feedback
|
|
Some more steps you can take:
| |||||||
feedback
|
|
How are you backing up? I'm wondering if your backup software isn't setting the correct flags for Exchange to run post backup maintenance. What happens if you actually run an exchange-aware backup with NTBackup? | |||
|
feedback
|
|
If the online maintenance isn't running (not seeing the event log is a sign it isn't) then there will be no space marked for deletion by the offline defrag. Check that no backup is trying to run during the maintenance periods set. You may have to leave an extended period and disable backups on say a weekend to get a full runthrough if it hasn't happened before. Once it gets the online maintenance completed, the event log will tell you how much space the offline one will recover. | |||
|
feedback
|
|
Thanks to everyone for all your help. What I ended up doing was using exmerge to export each users data (after using auto-archive to bring them down below the 2GB limit, why doesn't exmerge use the newer unicode .psts?), creating a new private store and then using exmerge again to re-import the mailboxes. Unfortunately, this causes outlook to go into recovery mode for each user but at least it worked with a minimum of downtime. | |||
|
feedback
|
|
Though becoming depreciated with Exchange 2010, you'll lose the disk-saving capacity of Single Instance Storage by extracting and importing mailboxes with ExMerge. I tend to add date and folder filters when extracting with ExMerge. Don't forget to ignore Contacts, users get upset when half of them suddenly "go away" due to the export.. ;) Importing "just" the contacts back wasn't too bad, though.. Between the mailbox store teetering around 72G and whitespace inching less and less, I took charge and began exporting mail. Couldn't wait for the users to hit my 73G hedge limit. Now.. offline defrag. Good times! | |||
|
feedback
|