ohmErnie
asked on
Clean/Shrink Exchange 2007 Database Size
We are running Exchange 2007, SP3 and using Backup Exec 2010 to perform full backups to disk. It is my understanding that over time, white space is created from all the changes in the database and the actual size of the database can be shrunk, thus reducing the b2d file created from a backup.
I have read an option of creating a new database and moving all the mailboxes over, then deleting the old database, then create another new database with the old name and move the mailboxes back. Is this a good or bad idea?
I have had this server in place for about 2 years without any database cleanup. I am hoping that after whatever maintenance I perform, I will have reduced the backup file size.
What are my options?
I have read an option of creating a new database and moving all the mailboxes over, then deleting the old database, then create another new database with the old name and move the mailboxes back. Is this a good or bad idea?
I have had this server in place for about 2 years without any database cleanup. I am hoping that after whatever maintenance I perform, I will have reduced the backup file size.
What are my options?
AustinComputerLabs
the best way is an offline defrag. This will take the store down so do it after hours.
Here is a step by step for the move alternative that you mentioned:
https://www.experts-exchange.com/Software/Server_Software/Email_Servers/Exchange/A_2730-Exchange-Offline-Defrag.html?sfQueryTermInfo=1+10+2007+30+defrag+exchang+offlin
https://www.experts-exchange.com/Software/Server_Software/Email_Servers/Exchange/A_2730-Exchange-Offline-Defrag.html?sfQueryTermInfo=1+10+2007+30+defrag+exchang+offlin
As suggested, an offline defrag would be your best bet. However this may not be necessary unless you have purged lots of old exchange data. Any white space in the database file would be filled up by new information. So the actualy Exchange DB file size will not grow when there is white space.
There is an event that should be logged nightly that would indicate how much free space is in the database. I believe it is event id 1221. If you are not seeing a large amount of white space, then an offline defrag will not do much for you.
There is an event that should be logged nightly that would indicate how much free space is in the database. I believe it is event id 1221. If you are not seeing a large amount of white space, then an offline defrag will not do much for you.
another option is to allocate a new set of disks and create a new db and log. basically migrate the mailboxes to a new db. once done, decommission the old db. we had to do this since we couldn't take the extended outage.
In addition to migrating to a new DB (If there's really any free white space to be reclaimed), you may want to have a couple of DB's so users are broken up a bit and the total database size is smaller. This way you can reclaim space in the future without as much downtime.
I'd still be surprised if you have a large amount of white space though, unless you've removed a lot of users or done a lot of mail cleanup.
I'd still be surprised if you have a large amount of white space though, unless you've removed a lot of users or done a lot of mail cleanup.
1. Good suggestions on checking for 1221 to see the amount of space you have available before doing anything
2. You can certainly do an offline defrag however, that is going to require downtime for the entire system vs moving mailboxes is only going to effect one user at a time.
3. Once you move the users to a new DB there is no reason to move them back to another database. Only issue is to change your backup job to point to the new DB, dismount the old DB for a day or so to ensure that nothing was missed, i.e. all users were moved cleanly etc and then delete the old database
If you go the defrag route you want to A. Backup the database before you do the defrag then B. post defrag do an ISINTEG see http://technet.microsoft.com/en-us/library/bb125144(EXCHG.80).aspx until you have 0 errors. Usually you need to do at least two passes. C. bring the DB online and do an immediate online backup
2. You can certainly do an offline defrag however, that is going to require downtime for the entire system vs moving mailboxes is only going to effect one user at a time.
3. Once you move the users to a new DB there is no reason to move them back to another database. Only issue is to change your backup job to point to the new DB, dismount the old DB for a day or so to ensure that nothing was missed, i.e. all users were moved cleanly etc and then delete the old database
If you go the defrag route you want to A. Backup the database before you do the defrag then B. post defrag do an ISINTEG see http://technet.microsoft.com/en-us/library/bb125144(EXCHG.80).aspx until you have 0 errors. Usually you need to do at least two passes. C. bring the DB online and do an immediate online backup
ASKER
I checked event 1221 and this is what it said:
The database "First Storage Group\Mailbox Database" has 10622 megabytes of free space after online defragmentation has terminated.
Should I take any action?
The database "First Storage Group\Mailbox Database" has 10622 megabytes of free space after online defragmentation has terminated.
Should I take any action?
Well if I am reading this correctly you have 10GB available.
1. How big is that database?
2. How many users are within the DB?
3. How much space do you have available on the system for new DB's?
1. How big is that database?
2. How many users are within the DB?
3. How much space do you have available on the system for new DB's?
ASKER
Mailbox Database.edb is 76GB
205 Mailboxes
325GB Free Space
205 Mailboxes
325GB Free Space
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Thanks for the points!