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?
LVL 1
ohmErnieAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

AustinComputerLabsCommented:
the best way is an offline defrag. This will take the store down so do it after hours.
0
maytrixCommented:
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.
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

-alvin-Commented:
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.
0
maytrixCommented:
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.
0
lucid8Commented:
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
0
ohmErnieAuthor Commented:
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?
0
lucid8Commented:
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?
0
ohmErnieAuthor Commented:
Mailbox Database.edb is 76GB
205 Mailboxes
325GB Free Space
0
lucid8Commented:
Well,  you have about 13% available in white space and usually IMO unless you reach the 20% mark I wouldn't waste the time, and even then if you are running the Enterprise version of Exchange I think you would be better off to create a NEW database and migrate the users into the new DB.  This is less disruptive, i.e. only the users being moved are inconvenienced while others can continue to work and you get a fresh new database.

Now one thing to consider is to take the opportunity to break up your users into smaller groups, i.e. Executive, Engineering, Administrative, or whatever grouping makes the most sens for you.  The reason I say this is that it makes things much more manageable if you have a DB problem then it will only effect a smaller group of users and you can also prioritize actions based upon the members of the DB, i.e. we have to get the XYZ group finished first etc.

 
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
lucid8Commented:
Thanks for the points!
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Exchange

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.