locked
Database maintenance in a DAG environment RRS feed

  • Question

  • I started working for a company that recently upgraded their Exchange environment to a 2010 DAG scenario.  They had been used to periodically dismounting their mailbox DB and running a third party program to compact the database to free up space.  I'm trying to help them find out if there's a way to do this now that we're on the DAG.  I.e. something that wouldn't involve suspending, dismounting, updating DBs.  

    I know mailbox DBs have scheduled maintenance windows in Exchange.  Is this comparable?  


    ---------- Ron Bass Systems Engineer Confie Seguros

    Friday, February 19, 2016 10:33 PM

Answers

  • Hi Ron,

    You shouldn't need to do an offline defrag via ESEUTIL /D since online defrag run in 24*7, it's more risk and cost more time when run ESEUTIL to maintenance database. For your reference:
    http://blogs.technet.com/b/rmilne/archive/2013/08/23/offline-defrag-and-dag-databases_2c00_-oh-my_2100_.aspx


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Allen Wang
    TechNet Community Support

    Monday, February 22, 2016 8:39 AM
    Moderator
  • Remember that deleted items are retained for the deleted item retention period and won't show up in users' "Folder Size" but that content is still in the store until it expires and is purged.

    1.  Moving mailboxes doesn't reclaim any space.  Moving all mailboxes from a database allows you to delete the database and reclaim its space.  If you don't use circular logging, mailbox moves generate transaction logs, which you'll need a plan to deal with.

    2.  It's probably a good idea to extend the maintenance window over the whole weekend.  That's something I routinely do.  That won't help anything if you're not bumping into that window, though.

    3.  It's worth looking into, I guess.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Monday, February 29, 2016 11:31 PM

All replies

  • That third-party program wouldn't be "Go Exchange" would it?  That product's slogan should be "Automating the Unnecessary".  Periodic defragmentation and compaction of Exchange databases has never been necessary nor has it ever been a recommended best practice.

    Stop doing that.

    If you have a database that has grown excessively large from white space because of an unusual incident, the best practice is to create a new mailbox database, move the mailboxes to it, then delete the bloated database.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Saturday, February 20, 2016 12:13 AM
  • The program's name is PerfectDisk.  It basically runs an ESEUTIL command.  Here's their take:

    http://na13.salesforce.com/_ui/selfservice/pkb/PublicKnowledgeSolution/d?orgId=00D30000001FVTK&id=501a0000000vqmW


    ---------- Ron Bass Systems Engineer, Confie Seguros

    Saturday, February 20, 2016 1:07 AM
  • Not going to even read it.  There's no need for it, never has been.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Saturday, February 20, 2016 6:00 AM
  • Hi Ron,

    You shouldn't need to do an offline defrag via ESEUTIL /D since online defrag run in 24*7, it's more risk and cost more time when run ESEUTIL to maintenance database. For your reference:
    http://blogs.technet.com/b/rmilne/archive/2013/08/23/offline-defrag-and-dag-databases_2c00_-oh-my_2100_.aspx


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Allen Wang
    TechNet Community Support

    Monday, February 22, 2016 8:39 AM
    Moderator
  • Thanks guys, this helps a lot.  I'm drilling deeper into exactly why they want to do this kind of whitespace reclaiming.  It sounds like we are using scripts to go into people’s mailboxes, move e-mails and attachments into our third-party Mail Archiver (or redirect them with links), and then delete them from Exchange.  

    So, I'm not sure if Exchange is just taking its sweet time reclaiming this white space, or if the automatic maintenance fails to do this entirely.  My boss says it fails to do this entirely, but I question that.  So, if I want to push our department away from manual DB defrag/compact, I see a couple options:

    1. Perform scripts to round-robin mailbox moves, so that each mailbox gets its whitespace reclaimed that way.  Or is there a way to force a per-mailbox cleanup? (basically, "move" a mailbox back into its own DB).

    2. Increase the Exchange maintenance window.  Right not it's the default 1am-5am nightly, we could do longer weeknightly and even longer on the weekend.  

    3. Troubleshoot whether our current archive scripting / third-party mail archiver is corrupting the mailboxes in some way which is preventing Exchange from running proper maintenance.  Then provide some kind of alternate plan.

    Thoughts?


    ---------- Ron Bass Systems Engineer, Confie Seguros

    Monday, February 29, 2016 10:42 PM
  • Remember that deleted items are retained for the deleted item retention period and won't show up in users' "Folder Size" but that content is still in the store until it expires and is purged.

    1.  Moving mailboxes doesn't reclaim any space.  Moving all mailboxes from a database allows you to delete the database and reclaim its space.  If you don't use circular logging, mailbox moves generate transaction logs, which you'll need a plan to deal with.

    2.  It's probably a good idea to extend the maintenance window over the whole weekend.  That's something I routinely do.  That won't help anything if you're not bumping into that window, though.

    3.  It's worth looking into, I guess.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Monday, February 29, 2016 11:31 PM
  • How would I check to see if we're bumping into the limits of our maintenance window?  Or better yet, overall performance counters in the maintenance window?

    I'm also seeing that when background maintenance reclaims whitespace, it doesn't return it to the file system.  What does it do with the whitespace?  Does it just keep it around as a buffer?

    Here's the article I was looking at: http://blogs.technet.com/b/exchange/archive/2011/12/14/database-maintenance-in-exchange-2010.aspx  


    ---------- Ron Bass Systems Engineer, Confie Seguros

    Tuesday, March 1, 2016 1:26 AM
  • If I recall correctly, the event log should tell you at the end of the maintenance window if it's not done.

    It's not technically a buffer, reclaimed white space is available for reuse.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Tuesday, March 1, 2016 1:39 AM