edb and stm files growing quickly (Full Version)

All Forums >> [Microsoft Exchange 2000] >> Information Stores



Message

trevorc -> edb and stm files growing quickly (29.Dec.2006 5:27:16 AM)

I have two Exchange 2000 Standard running on two Win2K Server SP3 servers (MAIL1 and MAIL2). MAIL1 is a DC and MAIL2 is a member server. MAIL1 is an internet facing machine and has no mailboxes on it. All the mailboxes are on MAIL2.
 
Since both machines are on the same AD, if someone sends an outside email, it will first be received by MAIL1 and since the mailboxes are on MAIL2, it will be forwarded to it's respective mailbox on MAIL2.
 
I am noticing that my .edb and .stm files on MAIL1 are growing very quickly...nearly 12Gb. I cannot understand why because there are no mailboxes on this server. I am afraid that with time, i reach the 16Gb limit!
 
On MAIL2, the .edb and .stm files are about 10.5Gb. I cannot understand why the internet facing server has bigger db files that the server having the mailboxes! When MAIL1 forwards emails to MAIL2, does it keep a copy of the mail too?
 
Thanks in advance for any given help.



jassyca -> RE: edb and stm files growing quickly (1.Jan.2007 4:16:25 AM)

Couple questions for you..

On Mail1, did you tell it it was a "front end" server? There's a check box for that. (I'm not in front of my server just now but I think it's something like Exchange System Manager --> Administrative Groups --> Servers --> Mail1 then the properties of Mail1 and it seems to me I remember seeing that check box on that very first tab-page).

What do you see when you expand the "Mailboxes" for Mail1? (Again, I'm not sure where that's at but something like Exchange System Manager --> Admin Groups --> Servers --> Mail1 --> First Storage Group --> Private Storage Group --> Mailboxes.)



trevorc -> RE: edb and stm files growing quickly (2.Jan.2007 6:27:01 AM)

Thanks for replying.

I do not remember specifing to MAIL1 that it is a 'Front End' Server. I looked in Exchange System Manager -> Administrative Groups -> Servers - MAIL1 properties but there isn't this option. Can it be that it is not for Exchange 2000 Standard?
 
When i expand the mailboxes on MAIL1, there are only 5 mailboxes. ie:
  • System Attendant
  • EUQ_MAIL1
  • SMTP (MAIL1-{34CEC4EC-****-****-****-************})
  • SystemMailbox{34CEC4EC-****-****-****-************}
  • Administrator

The first 3 mailboxes are 0KB whilst SystemMailbox and Administrator are 2,610KB and 28,182KB respectively.



jassyca -> RE: edb and stm files growing quickly (2.Jan.2007 10:24:34 AM)

http://support.microsoft.com/kb/296614/en-us (Differences between Exchange Standard and Exchange Enterprise, blah blah blah) "Exchange front-end server configuration is not supported" Argh, you might be right. Although it just says it's "not supported", not that it can't be done. [image]http://forums.msexchange.org/image/s4.gif[/image]

The largest mailbox is using 28 meg but the edb file is 12 gig? Yii yii yiii! Something sure sounds wrong. Do you have "tracking" turned on? I'm not sure where Exchange stores the data for that although I have a vague feeling it's not in the edb or stm files.

Did you see any of these?
http://support.microsoft.com/kb/555360/en-us
"How to resolve unexpected growth of EDB and/or STM Files"

http://support.microsoft.com/kb/815297/en-us
"The Exchange public folder store database file grows unexpectedly large" (Article is about the public folder but perhaps the same problem can happen to the private folder?)

http://support.microsoft.com/kb/328804/en-us
"How to defragment Exchange databases" (I don't think it's a simple problem of fragmentation but I do feel it would be a good idea to first check the database's integrity (http://support.microsoft.com/kb/301460/en-us) and then see if a defrag shrinks it to a more normal size. A defrag will have to happen after hours because it will take MAIL1's database offline which means incoming and out-going mail won't be routed. At 12 gig, it will probably take quite a while to work through what's there.. maybe 20 minutes to over an hour? Not sure how long, really, but long enough that users could notice they aren't getting outside mail and start ringing your phone off the hook. [;)])

Let us know what you find.



trevorc -> RE: edb and stm files growing quickly (3.Jan.2007 8:42:51 AM)

hehe thanks for the articles. i confirm that i have the Stand Edition and therefore Front-End Server Configuration is "not supported".
 
All i can say is that a few months ago i had a corruption on this database and therefore decided to move all the mailboxes onto another server with the plan of deleting the corrupted store, recreating a new one and moving the mailboxes back.
 
In fact, when i moved all the mailboxes from MAIL1, i expected the store to diminish drastically in size but on the contrary, it gew bigger! Can it be that it's because of the corruption?
 
I still have not deleted the store and recreated it because if i delete the store, i will stop the SMTP and users will not be able to send/receive mails (and therefore panic). I have to come in during a weekend to do this! [:(]
 
ps: the last time i defragmented a 10Gb store took 12Hrs on a Dual P3 1GHz, 512 RAM and RAID-5 hard disks.



jassyca -> RE: edb and stm files growing quickly (3.Jan.2007 10:18:53 AM)

Oh oh oh!! Stupid me! I didn't look at your message history. That would've explained things. Duh!

If you have a storage group with mailboxes and someone deletes a ton of messages or, on the other hand, if you get rid of a bunch of mailboxes, the storage group's database won't shrink. Once it grabs drive space for itself, it's going to stay that size until you defragment it. The idea is that Exchange can always re-use the space because, internally, those database records are "blank". So if MAIL1 had all the mailboxes and they've been moved to MAIL2, no wonder MAIL1 is so large. You're not going to get that space back until you defrag. And, if I'm right and understand properly how it defrags, it should not take 12 hours because there really isn't 12 gig worth of data in the database. It only has to work through the valid messages which used, what, 23 something meg? It's still an "after hours" project, though. Always better to do this type of thing when there's less chance of the dreaded "is email down?" phone calls from users. [;)] Less pressure, more time to think.. incase something goes wrong.

Let us know how it goes.



Page: [1]