ESEUTIL not reducing Exchange database size
I am running SBS 2003 (upgraded from SBS 2000). I want to reduse the size of the Exchange database. The original size for the private mail store was 38.287 GB (edb) and 10.244 GB (stm). I dismounted the stores and ran the ESEUTIL utility with the /d switch. After the utility ran, my database size was 38.066GB and 10.045GB. I know that the database can be reduced more because I run a policy every week that deltes 300-900 GB of messages from users' delted items, inbox and sent items.
In the past when I rant the ESEUTIL on the SBS 2000 system, the datrabase would typically be reduced in size by 30%-50%.
Am I missing something here? How can I effectivly reduse the database size? If I keep increasing the database size limit, at some point I an going to hit the 75GB limit and have real trouble.
Thanks!
In the past when I rant the ESEUTIL on the SBS 2000 system, the datrabase would typically be reduced in size by 30%-50%.
Am I missing something here? How can I effectivly reduse the database size? If I keep increasing the database size limit, at some point I an going to hit the 75GB limit and have real trouble.
Thanks!
ASKER
No error messages were displayed when the policy ran. I looked at the details of the policy and it appears that many messages were deleted and spce was freed up. Here is a sample of one of the mailboxes. These are the last two lines of the detail showing the summary of the task:
Mailbox user@domain.com Contents (before processing): 162 Items (10.34 MB)
Mailbox user@domain.com.com Done: 7 Folders Processed, 0 Items Moved (0 (null)), 25 Items Deleted (286 (null))
It seems to me that 25 items were deleted. I am not sure what the "(286 (null))" means.
Does this shed any light on it?
Mailbox user@domain.com Contents (before processing): 162 Items (10.34 MB)
Mailbox user@domain.com.com Done: 7 Folders Processed, 0 Items Moved (0 (null)), 25 Items Deleted (286 (null))
It seems to me that 25 items were deleted. I am not sure what the "(286 (null))" means.
Does this shed any light on it?
Did you look to see how much white space was in the database before you started?
It is very unusual to get a large amount of space back on the database size unless you have deleted a large amount of date - ie by having a lot of mailboxes removed.
Don't forget that Exchange uses the whitespace in the database. It should use it before the size of the database is increased. The value of offline defrags is limited in that regard.
Also note that the behaviour of the limit was changed in Exchange 2003 SP2, and the limit now takes in to account the amount of white space. It is possible to have physical file sizes that are larger than 75gb by the fact that there is a lot of white space in the database.
I presume that you mean you have a policy that deleted 300-900mb of email a week.
What is your deleted item retention time set to? You can delete as much email as you like, but if DIR is set then the content is not really deleted until that time expires.
Simon.
It is very unusual to get a large amount of space back on the database size unless you have deleted a large amount of date - ie by having a lot of mailboxes removed.
Don't forget that Exchange uses the whitespace in the database. It should use it before the size of the database is increased. The value of offline defrags is limited in that regard.
Also note that the behaviour of the limit was changed in Exchange 2003 SP2, and the limit now takes in to account the amount of white space. It is possible to have physical file sizes that are larger than 75gb by the fact that there is a lot of white space in the database.
I presume that you mean you have a policy that deleted 300-900mb of email a week.
What is your deleted item retention time set to? You can delete as much email as you like, but if DIR is set then the content is not really deleted until that time expires.
Simon.
ASKER
White space...I did not see how much white space there was before I started. How do I find that out?
Yes, it was 300-900 MB.
You may have hit on something with the retention. It currently is set to 1000 days. So, if I set it back to 30 days, then run ESEUTIL, do you suppose I will gain white space back?
Just to clearify my understanding...The retention time means how long items will be retained after they are PERMANENTLY deleted (from someone emtying their Deleted Items folder). Is that correct? So do you think that changing to 30 days will free up space?
(I had to change it way back when to 1000 because of legal issues to).
Thanks for you help...
Yes, it was 300-900 MB.
You may have hit on something with the retention. It currently is set to 1000 days. So, if I set it back to 30 days, then run ESEUTIL, do you suppose I will gain white space back?
Just to clearify my understanding...The retention time means how long items will be retained after they are PERMANENTLY deleted (from someone emtying their Deleted Items folder). Is that correct? So do you think that changing to 30 days will free up space?
(I had to change it way back when to 1000 because of legal issues to).
Thanks for you help...
Event ID 1221 overnight will tell you how much white space you have in the database.
White space is only created when the content is purged from the database. If you have DIR set to 1000 days then you will not purge anything from the database until almost three years after it has been cleared from the user's deleted items folder.
You will need to set the DIR time back to 30 days then wait for at least two passes off the online defrag which takes place overnight before you will see any significant amounts of white space being created.
If the DIR time had been set to 30 days to begin with then you probably wouldn't see much change in the database size as the white space would be used and then flushed at frequent intervals.
In this particular case you may benefit from an offline defrag, but you shouldn't consider it to be something that you do on a regular basis.
If you have to retain email for legal reasons then you should be looking at one of the archiving tools that will store the email separately from the email database. From a legal position storing the email in the email database is often not good enough as the user can still modify the data after it has been received and there is no record of that change. (Note I am not a lawyer, I don't play one on TV and I don't post as one on EE).
Simon.
White space is only created when the content is purged from the database. If you have DIR set to 1000 days then you will not purge anything from the database until almost three years after it has been cleared from the user's deleted items folder.
You will need to set the DIR time back to 30 days then wait for at least two passes off the online defrag which takes place overnight before you will see any significant amounts of white space being created.
If the DIR time had been set to 30 days to begin with then you probably wouldn't see much change in the database size as the white space would be used and then flushed at frequent intervals.
In this particular case you may benefit from an offline defrag, but you shouldn't consider it to be something that you do on a regular basis.
If you have to retain email for legal reasons then you should be looking at one of the archiving tools that will store the email separately from the email database. From a legal position storing the email in the email database is often not good enough as the user can still modify the data after it has been received and there is no record of that change. (Note I am not a lawyer, I don't play one on TV and I don't post as one on EE).
Simon.
ASKER
So it sounds from what you are saying that if I change DIR back to 30 and rerun the EUSTIL next weekend, I should be able to recover quite a bit of white space and reduce the size of the DB, right?
Bill
Bill
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks Simon,
I actually am getting too close for comport to the database limit and also, I am pretty sure that I will be gaining about 50% of the space back. We were directed not to purge anything for about a year and that is no longer in affect. As far as down time, I generally run the defrag overnight on a weekend so it is not a huge problem (thankfully I have understanding clients!).
Again, thanks for your attention to this questin and for expanding my knowledge in this area. Keep an eye open for my upcoming questions an the DST upgrade!
Best...
Bill
I actually am getting too close for comport to the database limit and also, I am pretty sure that I will be gaining about 50% of the space back. We were directed not to purge anything for about a year and that is no longer in affect. As far as down time, I generally run the defrag overnight on a weekend so it is not a huge problem (thankfully I have understanding clients!).
Again, thanks for your attention to this questin and for expanding my knowledge in this area. Keep an eye open for my upcoming questions an the DST upgrade!
Best...
Bill
I don't touch any of the DST questions. Being in the UK the issue doesn't affect me, so I am keeping well clear.
Note what I said about about how Exchange measures the database. It is no longer the hard physical size limit - but the amount of data in the database.
Simon.
Note what I said about about how Exchange measures the database. It is no longer the hard physical size limit - but the amount of data in the database.
Simon.
I take it that the process completed w/o error(s)?
What was the difference in users' mailbox sizes after your policy ran this week? If fewer items were deleted this week, that could easily explain the difference in your offline defragmentation (eseutil /d). It can only reclaim whitespace when there is some to reclaim (not trying to be smart w/ you, just stating a fact).