Exchange Databases are LARGE 2

[bigjrocksit]

I was looking at the size of my Exchange backups and I'm close to 80GB with only ~60 users.

I found that my public folders are close to 27GB, which is part of the problem I'm sure, but that's another issue on how to manage that.

I've seen some links on how to "defrag" the exchange databases, but is this a good way to shrink the size of the databases? And will I actually shrink them enough to matter with these methods?

-Thanks

Jermaie

 

[58sniper]

That depends. Look in your application event log for event 1221. There will be one for the Public Folder database, and one for each mailbox database. They will tell you how much unused, or "whitespace" is in the database.

If the amount is greater than, say, 30%, a defrag would help free that space.

Keep in mind that a defrag is done OFFLINE, which means your users can't connect. You also need ~110% free space for a working area.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[bigjrocksit]

Ok- I found those events and I'm a little confused on how this works.

I understand that the database will shrink in size, but the file size will remain the same, but how does that relate to what event viewer is showing me?

The 1221 event shows "The Database "First Storage Group/Mailbox store has 15572mb of free space after online defragmentation was terminated" - what is this really telling me? That I have 15GB of free space for that database? Or that there is a 15GB difference in the database size and the actual file size?

My public store shows 46mb of free space- I'm a little confused on if these "free space" numbers are telling me something is good or bad-

-J

 

[engjohn]

For example, assume that your priv.db is 30GB with 15GB free inside.
After an offline defrag, your priv.db would be ~15GB with 0GB free space inside...

 

[58sniper]

free space is "whitespace". Space that's not being used, and that could be recovered with an offline defrag. Keep in mind that an offline defrag is a lengthy process and depends more on how much data is actually in the database vs. how much whitespace there is. Figure 5-7GB per hour of data.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[Zelandakh]

80GB for backup less 27GB for public means 53GB for mailboxes of which 15GB is white space.

If that is the case it is debateable on whether you'd be benefitting really but do it if you are concerned.

 

[58sniper]

Yep. I wouldn't do it. Exchange will reuse the whitespace as needed.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[xmsre]

OK,

When I see situations where the amount of whitespace is equal to about 1/7th the size of the database, the first thing that comes to mind is delivery to PST. (Think about it: default DIR is 7 days). In this case, don't bother removing the whitespace; it's an exercise in futility.

You shouldn't be delivering to PST. PSTs have no place in a business environment. PSTs were intended as local storage for individual home users that POP their mail from an ISP. As the Executive Office of the President of the United States discovered, you can't count on them to archive important documents (the infamous missing 225 days). PSTs are fragile and easily corrupted. If retaining mail fulfills a legitimate business objective, then spring for the disk and store it on Exchange. If you store it on Exchange, you are reasonably assured it is backed up regularly and will be available to meet the business objective which drives its retention. If retaining the mail does not fulfill a business objective, then don't retain it; it's a liability.

You can shrink the physical size of a database by the amount of whitespace in the database if you do an offline defrag. This does come at a price. You have to take the store offline to do an offline defrag; for a really long time. That means a long outage that will surely blow all your SLAs (if you have them; if not your users will still complain very loudly). All secondary indexes are wiped and will have to be rebuilt. You will experience performance degredation until the indexes are repopulated. The signature of the database will change. This means all previous backups will become invalid (signature mismatch). That's a huge price to pay.

If you are delivering to PST, then tomorrow another day's worth of deleted email will exceed the DIR and become whitespace equal to about 1/7th the size of the database. All of the pain you experienced will be for nothing and you'll simply repeat it day after day after day. Whatespace gets reused before the physical size of the database is increased. There's no point unless you're into inflicting pain upon yourself. If that's the case, then try migrating to lotus notes.

 

[bigjrocksit]

Thanks all-

I appreciate the tips!

-Jeramie

 

[Zelandakh]

As we appreciate the stars

 

[Dfig]

I want to upgrade my current Exchange 2003 Standard to Exhane Enterprise. I am trying to determine how to best configure my drives. Our current Exchange was pre existing when T got here. It has one large volume running raid 5. From what I have read that is not very efficient. I have an IBM 3650 xServer 3650 with 6 X 300GB 15k drives with 1 X Quad CPU and 4GM of memory. I have found alot of info on it but some of it gets technical and lengthy. I have about 700 mailboxes. I would like to have 2 to 3 Private information stores and 1 Public. I want to upgrade because we are approaching the 75GB limit (SP2)for Exchange 2003 Standard. Any advice would be greatly appreciated.

 

[Zelandakh]

1. Start a new thread.
2. Good length of question and good summary - too wordy will put people off.
3. We've covered this in here lots of times so you should be able to propose something for discussion (OS on a mirror, Logs on a mirror and Stores on a mirror would work in your scenario).

Standard to Enterprise can be done on the existing server by installing Enterprise over the top, choosing upgrade, and takes about 15 minutes from start to finish and nothing gets harmed (though a backup would be recommended!).

That will get you over the initial bottleneck and give you time to plan.

 

[JamesClarkDizon]

Hi. We are using MS Exchange Server 2003 running on POP3 Clients. Our current DB size is 33GB (31GB .STM file and 2GB .EDB file).

Question: How do we reduce our database size especially the .STM file?

We did delete unnecessary emails on every users mailboxes, delete unnecessary users mailbox on the store, and do also offline defragmentation.

But after offline defragmentation, database size seems untouched and result to the same size as before.

Is there anything I missed to perform to fully reduce our exchange database size?

any help would be highly appreciated.

Many thanks,
- James

 

[zbnet]

Repeat after me: new question, new thread; new question, new thread...

 

[Zelandakh]

Answer: Check ESM for the sizes of each mailbox and add them up. Then come back in a new thread and ask us a new question.

 

[Javamahn]

I just did an offline defrag of a database with over 50GB of whitespace. It took me just over 2 hours for the whole process to reduce the size from over 90GB to less then 50GB. I did create a 2nd storage group and move a few critical users to it prior to the defrag so they would not be interrupted. I generally do this once a year just to keep things tidy. Be sure you do a full backup immediately prior and after.

 

[Zelandakh]

You don't need to offline defrag once a year, only when your 1221 shows you have a need to do so.