locked
Exchange 2003 store significantly larger than total size of mailboxes RRS feed

  • Question

  • Our Exchange 2003 Std SP2 mailbox store (currently configured for a 70Gb limit in registry) currently contains (according to the sum of all mailbox sizes in ESM) just under 26Gb of mail.  Online defrag doesn't appear to complete every night (event id 701 is logged as it starts, sometimes it completes, but there don't appear to be any further events logged on days where it doesn't complete).

    Online defrag did complete recently, and reported approx 16Gb of free space available, however, event id 9688 was later logged, reporting the following:

    Exchange store 'First Storage Group\Mailbox Store (BRISBANE)': The logical size of this database (the logical size equals the physical size of the .edb file and the .stm file minus the logical free space in each) is 69 GB. This database size is approaching the size limit of 70 GB.

    We've run a number of offline defrags, but they never reclaim more than a few Gb of space.

    I'm used to seeing a few discrepancies in sizes due to retention etc, but none of the figures here match up, and I have no idea whether or not we'll soon have the database suddenly dismounted for exceeding the limit.

    Tuesday, October 18, 2011 12:09 AM

Answers

  • First I think you need to understand what happens when you remove an item from a mailbox, and when space actually becomes free space within a database.  When you delete an item, it's simply marked as deleted.  The item is still there, and will hang around for a bit.  It will certainly hang around until your deleted items retention period expires. 

    As this is Exchange 2003 with SIS, expiration of deleted items retention is no guarantee that anything will happen.  During the next online maintenance cycle after the expiration of deleted items retention, the reference count for the item is reduced by 1.  If I sent you a mail, and our mailboxes are on the same database, there are two pointers to the same item; one in my sent items and one in your inbox.  If you delete the copy in your inbox and wait the deleted items retention period, the item still exists because there is a copy in my sent items.  The reference count was reduced from 2 to 1, but it still has a reference count greater than 0 so it stays.

    Assuming that all references to an item are deleted, and you waited for deleted items retention to expire after the deletion of the last reference, and online maintenance has run and the reference count is now zero, we're almost in business.  Now you get to wait one more time for OLM and the online defrag task to run. During this process, all the pages with a zero reference count get consolidated into database free space within the edb file, and the amount of free space is reported in the event 1221... almost.

    This is Exchange 2003, and you actually have two different types of store.  You have the STM file for parts or properties of MAPI messages and you have the STM file that stores messages or select properties like attachments in MIME format.  There is a certain amount of duplication between the two.  It all depends on what client you use to access mail, and what format the message was in when it arrived/departed.  Convertion between MIME/MAPI is often called "promotion".  Probably the worst case scenario for this scheme is when the majority of messages arrive in MAPI format and are opened/read in MIME format or visa versa.  This was a common problem back in the day, and a good reason to upgrade your Exchange server BTW.

    J

     

    Tuesday, October 18, 2011 1:52 AM

All replies

  • Hi,

    I would suggest to crreate a new mailbox database and then move all the mailboxes to that new database. I have seen that even with offline defrag it does not reclaim all the space as it still contain system files etc.

    Tuesday, October 18, 2011 1:32 AM
  • First I think you need to understand what happens when you remove an item from a mailbox, and when space actually becomes free space within a database.  When you delete an item, it's simply marked as deleted.  The item is still there, and will hang around for a bit.  It will certainly hang around until your deleted items retention period expires. 

    As this is Exchange 2003 with SIS, expiration of deleted items retention is no guarantee that anything will happen.  During the next online maintenance cycle after the expiration of deleted items retention, the reference count for the item is reduced by 1.  If I sent you a mail, and our mailboxes are on the same database, there are two pointers to the same item; one in my sent items and one in your inbox.  If you delete the copy in your inbox and wait the deleted items retention period, the item still exists because there is a copy in my sent items.  The reference count was reduced from 2 to 1, but it still has a reference count greater than 0 so it stays.

    Assuming that all references to an item are deleted, and you waited for deleted items retention to expire after the deletion of the last reference, and online maintenance has run and the reference count is now zero, we're almost in business.  Now you get to wait one more time for OLM and the online defrag task to run. During this process, all the pages with a zero reference count get consolidated into database free space within the edb file, and the amount of free space is reported in the event 1221... almost.

    This is Exchange 2003, and you actually have two different types of store.  You have the STM file for parts or properties of MAPI messages and you have the STM file that stores messages or select properties like attachments in MIME format.  There is a certain amount of duplication between the two.  It all depends on what client you use to access mail, and what format the message was in when it arrived/departed.  Convertion between MIME/MAPI is often called "promotion".  Probably the worst case scenario for this scheme is when the majority of messages arrive in MAPI format and are opened/read in MIME format or visa versa.  This was a common problem back in the day, and a good reason to upgrade your Exchange server BTW.

    J

     

    Tuesday, October 18, 2011 1:52 AM
  • Hi Guys,

    Thanks for the comments.  Unfortunately I can't create a new database as it's Exchange Standard.  Regarding John's comments - I believe I have a fair understanding of how the database should behave, however, in this case, I've dropped retention to 0, online defrag has completed a full pass, and the reported logical size of the store by is approximately 44Gb higher than it should be.

    We'll be upgrading to 2010 or whatever's current when this server reaches end of life, but we try not to make a habit of performing costly migrations and forcing our clients to re-license their software in order to resolve issues.

    Thursday, October 20, 2011 12:56 AM