Exchange database size 2

[sergeys]

Hello.
I am running Exchange 2003 Server std, SP2. Last week, I noticed that combined size of Priv1.edb and Priv1.stm databases reached 69GB in size. I went ahead and set deleted mailbox and deleted item retention periods to 0 days. Then I deleted several old mailboxes total size appr. 5 GB, then I went to some of the users and personally moved stuff from their mailbox into pst files. Five days passed, since then, but my databases are showing the same exact size, they where showing before things were done.
They did not decrease or increase in size.
What should I do to decrease the size of these databases?
Thanks.

 

[RichardHuang]

You need to do offline defrag to shrink the database size. Here is more details:

http://technet.microsoft.com/en-us/library/bb123761.aspx

 

[sergeys]

The word "offline" scares me. Is this the only option?
Let me ask you another question. While the database is offline, will smtp service queue incoming emails, so they are delivered when the database is brought back online? Or will the sender's mail server keep trying to send it for a while, before it recieves an NDR? What will hapen to incoming email, while the store is dismounted?

 

[sergeys]

Thanks, it really looks like there's no other way. Thanks again.

 

[58sniper]

Well - you're going to get conflicting opinions here.

First, the size of the files that make up the database won't shrink automatically. But there's probably a fair amount of white space in them. This can be confirmed by looking at the 1221 events in the app event log.

If you're not hurting for drive space on the array that houses the database, leave it alone. Exchange will use that whitespace as needed. In fact, Exchange is more efficient when it has some white space to use than when it doesn't. That's because Exchange doesn't have to ask for more drive space, or for the file to be expanded.

If you ARE hurting for drive space, then there are several things to ponder. Why are you hurting for space, and can you live with (potentially) hours of downtime to do the offline defrag? If you can, do a full backup before.

Pat Richard, MCSE MCSA:Messaging CNA
Microsoft Exchange MVP
Want to know how email works? Read for yourself -

http://www.ietf.org/rfc/rfc2821.txt

 

[sergeys]

The whole reason I started thinking about this is that I notices that combined size of the database files is:
69.0 GB (74,192,470,016 bytes), when as far as I know the limit is 75GB. Otherwise, database is stored on it's own separate array, whith plenty of disk space available. Should I still be paranoid regarding the size of the database reaching it's max limit, or just leave it be?
Is there a way to calculate size of the white space in the database?
Thanks.

 

[RichardHuang]

Back to Exchange 5.5 times, the 16GB limit used to shutdown our Exchange server for 24 hours before we could bring it back up. I would say you defrg your database, and set the limitation on each mailbox than taking the chance to reach the max limit.

 

[scottew]

This thread has me wondering if anyone uses 3rd party applications like this one for the maintenance of their Exchange Servers.

http://www.lucid8.com/product/preventative.asp

 

[58sniper]

sergeys - The physical size of the database files doesn't matter. It's the amount of data in them that matters. As mentioned in my previous post, look for event ID 1221 in your event log to see how much whitespace is in the database. I'd be more concerned with how you limit mailbox sizes to just prevent abuse of the email system and unnecessary growth.

scottew - No. In fact, that product, and others like it, are often laughed at by Exchange pros.

Pat Richard, MCSE MCSA:Messaging CNA
Microsoft Exchange MVP
Want to know how email works? Read for yourself -

http://www.ietf.org/rfc/rfc2821.txt

 

[sergeys]

58sniper - 'The database "First Storage Group\Mailbox Store (BENTEXMAIL)" has 7197 megabytes of free space after online defragmentation has terminated.'
Now I can assume that database is about 62gb.
Thank you.

 

[xmsre]

As 58Sniper said, it's the logical size that matters. If my files are approaching 75 GB, and I have 200GB total space on the drive, and I have an adequate amount of ree space within the database, I wouldn't even consider an offline defrag. If you have another exchange server in your site or are running enterprise (I know you stated you're running std), then I would never consider an offline defrag, opting for move mailbox to a new store instead. It's only on the standard edition in a single server environment where offline defrag could be a (very very) remote possibility.

and to scottw, you don't run repair tools as part of regularly scheduled maintenance. If you find yourself with a single server running standard and constantly pushing the space limits, you need to add another server or go to enterprise. Running an offline defrag does recover space if you PERMANENTLY deleted all instances of a large quantity of mail; it provides no benefit otherswise. In fact, running an offline defrag unnecessarially will decrease your server performance (in addition to all that down time killing your SLAs). A certain amount of whitespace is normal. If you remove it then exchange has to do the work of putting it back. In addition, offline defrage clears indexes that exchange now has to repopulate.