locked
Need guidance on online maintenance strategy - Exchange 2007 RRS feed

  • Question

  • I have a fairly large Exchange 2007 SP3 UR6 deployment running on Server 2003 R2 SP2. All Databases connected to a SAN backend, Mailbox servers are all SCC's of varrying size.

    I set this environment up from scratch in 2008 when we migrated from Groupwise and have managed it ever since.

    In my infinite wisdom, I recently undertook a task to find a solution to a problem that may have not existed. While working late one night, I noticed all my Exchange Servers had very high CPU and disk utilization at a time when they shouldnt. I traced it down to online maintenance running on all DB's. I remember when we first set up the system, I had set online maintenance to run between 12am and 7am T-Th and 24 hours on Sat, Sun and until 7am Monday morning. I had not really been keeping up with the logs of maintenance ending, I have also never offline defragged any of my DB's.

    I then came up with an ingenious plan to schedule each DB to fit within a certain window, but only running 2 nights a week per DB.

    Long story short, this has not been adequite. I need a strategy or best practice to do this, I know I cant run it during the day, and I know I cant run it during backups. Some of my smaller DB's will finish within a 2-4 hour window, while others will take up to 12 hours to complete. I am not doing checksumming or page zeroing, but at some point, I feel I need to turn on checksumming, because we switched from streaming to VSS backups about 9 months ago. But I want to get this under control first.

    I was thinking of setting my large DB's to run every day, is it a big deal if they have to "resume" several times to actually finish? My storage is set up so each DB is on it's own SAN lun, is it ok for multiples to run at once?

    Once I get this straightened out, is it OK for me to just turn on checksumming in the registry? Any precaution I should take first?

    Any thoughts on the subject will be appreciated.

    Tuesday, May 1, 2012 12:27 PM

Answers

  • For best practice when it comes to OLM for 2007, you want to stagger your OLM between DBs meaning don't start them all at the same time nor don't do all DBs on the same night. You could also be running into memory working set trimming, although there could be several reasons why this happens, one thing you want to make sure is that your page file is RAM + 10MB still applies for x64bit systems.

    OLM checksumming is optional, I think most people tend to pass up on this and rely just on the native checksumming provided by your VSS backups.

    Also running OLM all day during the weekday can be counter productive.

    If you really want to size the correct window you will have to capture perfmon stats for online defrag pages counters.

    Exchange 2007 SP1 ESE Changes - Part 2
    http://blogs.technet.com/b/exchange/archive/2007/12/06/3404504.aspx

    If you want to verify if you're experiencing memory working set trimming you will also need to capture your perfmon stats.

    Excessive paging on Exchange 2007 servers when working sets are trimmed

    http://blogs.technet.com/b/mikelag/archive/2007/12/19/working-set-trimming.aspx


    James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com


    Tuesday, May 1, 2012 1:52 PM

All replies

  • For best practice when it comes to OLM for 2007, you want to stagger your OLM between DBs meaning don't start them all at the same time nor don't do all DBs on the same night. You could also be running into memory working set trimming, although there could be several reasons why this happens, one thing you want to make sure is that your page file is RAM + 10MB still applies for x64bit systems.

    OLM checksumming is optional, I think most people tend to pass up on this and rely just on the native checksumming provided by your VSS backups.

    Also running OLM all day during the weekday can be counter productive.

    If you really want to size the correct window you will have to capture perfmon stats for online defrag pages counters.

    Exchange 2007 SP1 ESE Changes - Part 2
    http://blogs.technet.com/b/exchange/archive/2007/12/06/3404504.aspx

    If you want to verify if you're experiencing memory working set trimming you will also need to capture your perfmon stats.

    Excessive paging on Exchange 2007 servers when working sets are trimmed

    http://blogs.technet.com/b/mikelag/archive/2007/12/19/working-set-trimming.aspx


    James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com


    Tuesday, May 1, 2012 1:52 PM
  • Yea, pagefile is already set correctly.

    After making my last changes, I have OLM running from 5:30p-10p M-F, 2AM-6:30AM Tu-Th and 2:30am Fri to 6:30am Mon, so it's got a solid 52 hours running on Weekends. Based on Size, I have dedicated only 1 DB to run OLM at a time. In blocks of 4-10 hours, depending on size of the DB.

    I have 10 DB's on some of my larger servers, and the size ranges from 14 gig to 80 gig. The largest ones are not finishing in 10 hours, even though they have the whole server resources to themselves.

    Specs on Servers:
    HP DL380 G5, with 2x Quad Core 3.1 ghz Intel Xeon 5460 with 32 gigs of memory, Fiber Channel HP EVA San with 15k rpm FC drives

    Really no activity on the weekends, so the servers should have all resources dedicated to them.

    Tuesday, May 1, 2012 2:42 PM
  • What is the actual issue you're trying to address? OLM taking 10hours (which can be normal) too much cpu memory usage during OLM? If so what impact is it having to the users?

    A full pass of OLM doesnt need to complete every day, you can get by with having a full pass done every 3-4 days, by just reduing the window if 10 hours is too long to complete and let it do a full pass over 3-4 days or even a week should be fine.


    James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

    Tuesday, May 1, 2012 3:02 PM