Database not shrinking 2

[DotNetNewbie]

Hi,

I have recently put in place mailbox limits for my company and know that a large number of users have deleted a vast amount of emails (4-5Gb), however the priv1.mdb does not seem to have shrunk to reflect this.

Is it like Exchange 2000 whereby I need to take the databases offline to do the defrag?

Many thanks

.net

 

[zbnet]

Exchange 2003, like all previous versions of Exchange, doesn't reduce the files used to store the databases in (priv.edb and priv.stm). The files only ever grow. And they only ever grow when the file runs out of white space.

When items in the store are deleted by everyone who had a pointer to them, and the Deleted Item Retention period has expired, then the next online database maintenance run marks the space used by these items in the database as 'white space'. White space can be reused by new email. So the true size of your database is the size of the file minus the amount of white space (add the edb and stm figures together for the total store size).

You can discover how much white space a DB has by looking for the overnight 1221 event log that is written for it by the online maintenance - makes sure you get the correct figure, these events are written for the priv and the pub DBs. In fact the nightly online maintenance does a pretty good job of shuffling all the data in the store to one end of the file and all the white space in the store to the other end of the file, to optimise the access of existing email and make the storage of new email easier (that's a simplistic view, but you get the picture).

I wouldn't bother taking a DB offline to run ESEUTIL to shrink the file down again unless you had a pretty significant amount of white space (say 30%) that wasn't going to be reused for some time - otherwise it's a waste of time: the first thing Exchange does with a newly-compacted DB is to extend the file again to create more white space for the new emails that arrive!

 

[58sniper]

I've given zbnet a star for the excellent answer.

Exchange reuses whitespace more efficiently than if it has to expand the file size first. Unless there is a >30% amount of whitespace, leave it alone. The only way to get rid of the whitespace is with an offline defrag, which can take many hours, depending on how big the DB is.

This has been discussed many times here, and you might find more info via a search of the site.

Pat Richard MVP

 

[DotNetNewbie]

zbnet,

Many thanks for your time and your answer, very informative indeed, I too have given you a star for your efforts.

58sniper - yeah me bad, I should know better and use the search.

Cheers Gents

.net