none
Exchange 2010 Database growth - Calendar versioning RRS feed

  • Question

  • This seems to be solved already, but I just want to put it out there to see if anyone else is experiencing the same thing.  We are running Exchange 2010 SP2 RU4.  We were seeing unexplained growth on our mailbox databases.  Each of our two databases are about 200GB and mailbox limits were set to 2GB.  The databases were growing at about 18-20% per month.  Unfortunately, I was not able to isolate the growth to a specific database because they were on the same volume and I wasn't monitoring the size of each specific database at the time.  I used tools such as ExMon to try to isolate it to particular users, but I could not find anything abnormal.  

    I ran a report that showed me the contents of mailbox recovery items and there were several that had gotten very large - over 10GB.  On these mailboxes there were millions of items in the "Recovery Items" folder, not the subfolders where I've read the messages should be.  All of these messages were calendar entries and most were duplicated thousands of times.  I manually cleared these mailboxes.  I also turned off the CalendarVersionStore feature and changed the recovery items retention from 14 days to 3 days.  

    With these changes, the available database space went from a few hundred MB to 30GB in one database and 50GB in another.  I've been monitoring the database size and available space for the last couple of weeks and database growth seems to have decreased significantly (I am considering a drop in Available Database Space to be database growth since I don't think the actual database files will increase as long as there is space available).  Instead of seeing the database sizes always go down by 1GB+ a day, it seems to be steady and fluctuating up and down.

    So, I don't know for sure that the CalendarVersioning feature was causing the growth, but it seems the most likely suspect.  Changing the recovery items retention would increase space in the short term, but it seems like the growth would continue at the same rate.  If anyone else has any ideas, I'd love to hear them because I could be missing something obvious. 

    Monday, October 22, 2012 4:06 PM

Answers

  • I think thats a good theory actually. The Cal versioning has been quite buggy until recently ( and there may still other issues related to it)

    One thing, the calendar versioning for any give mailbox will be disabled under the following conditions:

    If the folder size is greater than the RecoverableItemsWarningQuota, Calendar Version Logging is disabled for the mailbox. The RecoverableItemsWarningQuota value that is used depends on the mailbox’s settings:

    1. If the mailbox has the UseDatabaseQuotaDefaults set to $true, then the mailbox database’s RecoverableItemsWarningQuota will be used.
    2. If the mailbox has the UseDatabaseQuotaDefaults set to $false, then the mailbox’s RecoverableItemsWarningQuota will be used.

    Im sure you have seen this already, but in case you have not:

    http://blogs.technet.com/b/exchange/archive/2012/06/01/holy-cow-changes-to-recoverable-items-versioning-in-exchange-2010-sp2-ru3.aspx

    Monday, October 22, 2012 5:12 PM
    Moderator
  • Thanks, Andy. I was not aware that the Calendar Versioning would disable automatically in those circumstances.  I was confused as to why my mailboxes with the very large RecoverableItems size already had Calendar Versioning disabled, so that explains it.  Any idea how to turn off Calendar Versioning by default?

    I dont think you can disable it by default short of adding it as a cmdlet extension during mailbox creation.

    If you wanted to script something or do it in bulk like "get-mailbox | set-mailbox" one-liner style, that is probably the best way.

    Monday, October 22, 2012 6:56 PM
    Moderator

All replies

  • I think thats a good theory actually. The Cal versioning has been quite buggy until recently ( and there may still other issues related to it)

    One thing, the calendar versioning for any give mailbox will be disabled under the following conditions:

    If the folder size is greater than the RecoverableItemsWarningQuota, Calendar Version Logging is disabled for the mailbox. The RecoverableItemsWarningQuota value that is used depends on the mailbox’s settings:

    1. If the mailbox has the UseDatabaseQuotaDefaults set to $true, then the mailbox database’s RecoverableItemsWarningQuota will be used.
    2. If the mailbox has the UseDatabaseQuotaDefaults set to $false, then the mailbox’s RecoverableItemsWarningQuota will be used.

    Im sure you have seen this already, but in case you have not:

    http://blogs.technet.com/b/exchange/archive/2012/06/01/holy-cow-changes-to-recoverable-items-versioning-in-exchange-2010-sp2-ru3.aspx

    Monday, October 22, 2012 5:12 PM
    Moderator
  • Thanks, Andy. I was not aware that the Calendar Versioning would disable automatically in those circumstances.  I was confused as to why my mailboxes with the very large RecoverableItems size already had Calendar Versioning disabled, so that explains it.  Any idea how to turn off Calendar Versioning by default?

    Monday, October 22, 2012 6:50 PM
  • Thanks, Andy. I was not aware that the Calendar Versioning would disable automatically in those circumstances.  I was confused as to why my mailboxes with the very large RecoverableItems size already had Calendar Versioning disabled, so that explains it.  Any idea how to turn off Calendar Versioning by default?

    I dont think you can disable it by default short of adding it as a cmdlet extension during mailbox creation.

    If you wanted to script something or do it in bulk like "get-mailbox | set-mailbox" one-liner style, that is probably the best way.

    Monday, October 22, 2012 6:56 PM
    Moderator
  • Hi 

    if you want to disable calendar versioning you can do it only by powershell like below:

    Set-Mailbox -Identity "JSmith" -CalendarVersionStoreDisabled:$true
    Start-ManagedFolderAssistant -Identity "JSmith"

    you can also use something like this to find mailboxes with recoverableitems size greater than 100MB

    Set-AdServerSettings -ViewEntireForest $True

    $mbxs = Get-Mailboxstatistics -server MX01 | select displayname, @{expression = {$_.TotalDeletedItemSize.Value.ToMB()}; label="TotalDeletedItemSize"} | where {$_.TotalDeletedItemSize -gt 100}
    foreach ($mbx in $mbxs){
    Set-Mailbox -Identity $mbx.DisplayName -CalendarVersionStoreDisabled:$true

    }

    or if you want to only remove specified emails from recoverableitems


    Set-AdServerSettings -ViewEntireForest $True

    $mbxs = Get-Mailboxstatistics -Database "DB01" | select displayname, @{expression = {$_.TotalDeletedItemSize.Value.ToMB()}; label="TotalDeletedItemSize"} | where {$_.TotalDeletedItemSize -gt 100}
    foreach ($mbx in $mbxs){
    Search-Mailbox -Identity $mbx.DisplayName -searchQuery "Received:< $('2012-10-05') or Sent:< $('2012-10-05')"  -SearchDumpsterOnly -DeleteContent -Force:$TRUE
    }

    you need to try with dates parametr in my country I use above for US I think better is mm/dd/yyyy but you need to try.

     

    you can also find more information here:

    Exchange 2010 Database size growing problem

    Monday, October 22, 2012 8:02 PM
  • Hi

    I found a team blog

    http://blogs.technet.com/b/exchange/archive/2012/06/01/holy-cow-changes-to-recoverable-items-versioning-in-exchange-2010-sp2-ru3.aspx

    It said, "Calendar Version Logging is enabled by default on mailboxes in Exchange 2010. You can disable or enable this on a mailbox via the CalendarVersionStoreDisabled property. Note, the property name is CalendarVersionStoreDisabled, so the default value of $false means that Calendar Version Logging is enabled by default. "

    Hope it helps

    Cheers


    Zi Feng

    TechNet Community Support

    Tuesday, October 23, 2012 8:40 AM
    Moderator
  • Wanted to follow up on this after almost a month after these changes.  

    Before we made the changes I mentioned above, our Exchange database volume was growing by over 50GB per month. In the past 3 weeks, total database sizes have not grown by more than 1GB.  

    Thursday, November 8, 2012 3:46 PM