Exchange Server 2000 .edb .stm files Size are HUGE
I know someone has posted something similar to this but I did not find it helpful as I have already try all those things. I have a single exchange server 2000 server running in a native 2000 environment. The issue I am having is that lately I have been running out of space on my exchange box. Only 43 GB of free space left and it is shrinking very quickly. I have run offline defragmentation on the information store twice this weekend and I only manager to buy myself 9 to 10GB. As it stands the current size of the edb is 95GB and stm is 78GB after I ran defrag. Iran eseutil with /d and /p. I also ran Isinteg to check for errors on the information store but none were found. When i go to exchange system manager and add up the total mailbox sizes from there it is no more than 60GB so why is both my edb and stm files larger than than what shows up on system manager that is a total of 173Gb combine stm and edb as oppose to the 60GB that system manager shows. Another note worthy mention: I ran offline defrag about 5 months ago and got much better results. The stm file at the time went from 50GB to 10GB so it has worked in the past. I understand that Microsoft states that it is normal for the edb file to be larger than what shows in system manager but should it be this much larger? and should the stm also be larger? I'm confuse as to what is taking up all this space and what does the mailbox size on exchange system manger really represent. On the bottom I am going to post some link that I have reference from. Please if someone can offer a suggestion on how I can fix this issue it would be greatly appreciated. Priv.edb Database File Is Larger Than Mailbox Size (mircosofts explanation on why the edb can be greater than what is show on system manager)http://support.microsoft.com/kb/812232 How to resolve unexpected growth of EDB or/and STM Fileshttp://support.microsoft.com/kb/555360/en-us recreate the stm database (possible solution???)http://support.microsoft.com/kb/555146 Here is a pervious posting from another user with a similar problemhttp://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=2372806&SiteID=17
December 3rd, 2007 1:40am

When you look at mailbox sizes in Exchange System Manager, it won't take into account things like Deleted Item retention, which doesn't count towards mailbox quotas. You could check your deleted item retention setting and reduce if possible, thereby creating more whitespace in the database which can be reclaimed via an offline defrag. Check the event log for event 1221 which will give you a rough estimate as to how much data will be reclaimed if you perform an offline defrag. Clearly with a database that large you're running the Enterprise Edition of Exchange, so you can also consider creating a new database, moving the mailboxes to it, and then removing the old database files. This method means less downtime for the users and less risk for you, since you won't need to run ESEUTIL, etc.
Free Windows Admin Tool Kit Click here and download it now
December 4th, 2007 1:33pm

I'm also facing the same problem. I reduce the retention to 0 I perform the offline defragmentation too many times, but the size still larger than actual mails in the users mailboxes !!!! any idea plz????
April 22nd, 2009 4:31pm

Hello,First of all you SHOULD NOT use eseutil /p ever on database until unless there is no other way out.The size of the database and the size of exchange system manager will alway show different. As Neil said, ESM doesn't shows you exchange rules, dumpster items, server side rules, delete item count in ESM. The size of the database will doesn't sink unless there will be effective eseutil /d. Now when i say effective eseutil /d mean, successfully online maintainance has been performed on the server, event id 1221 reported with the so and so data can be freed up from database after we run offline defragment "eseutil /d" on the database. To me more accurate... run eseutil /s on the database to check how much data can be freed up after successful offline defrag.Other way - very effective cause it doesn't need much downtime., create another storage group with mailbox store and move mailboxes (Only for Enterprise servers).There is another cause for database size growing, if you ever broken the SIS (single instance storage) of database... Like you ever used exmerge for the exchange server.... Well, there is no such way to identify whether the SIS broken for the store or not (According to me there is no way you can identify).Arun Kumar | MCSE - 2K3 + Messaging | ITIL-F V3
Free Windows Admin Tool Kit Click here and download it now
May 7th, 2009 7:24am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics