Scheduled Maintenance (Full Version)

All Forums >> [Microsoft Exchange 2007] >> Management



Message

catzodellamarina -> Scheduled Maintenance (4.Feb.2009 1:12:03 PM)

Yesterday I disabled about 40 Gig worth of mailboxes that have been moved off my server.  Knowing that my Deletion settings were 30/30, I set them to 0 and unchecked the "Do not delete.." box.  I set the schedule to run for 4 hrs completeing at 7am this morning.

When I came in, I checked the DB size and I've gained nothing.  What does a guy have to do to force Exchange to give me back some space?

Also what exactly does the Maintenance run?  Does it defrag during this time?  Are there manual Powershell commands I can run during working hours?



Nazim -> RE: Scheduled Maintenance (4.Feb.2009 1:43:32 PM)

You need to perform an offline defrag of the exchange database to shrink the size of the DB.



catzodellamarina -> RE: Scheduled Maintenance (4.Feb.2009 1:48:30 PM)

I'm actually trying to avoid that due to the size - 460Gig.  I'm moving mailboxes to 5 new storage groups so they'll be more managable.  I read that moving to new SG's with new DB's actually eliminates the step for a defrag.  True?



John Weber -> RE: Scheduled Maintenance (4.Feb.2009 2:15:59 PM)

if you check your event log, you will see that the edb now has "whitespace" - google exchange whitespace for more info.

If you insist on reducing the physical space consumed by the edb, you are going to have to dismount the database/store - you are running multiple databases yes? - and eseutil /mh, and /g, and /d.

google exchange eseutil defrag.

If I was you, I would not do it - I would make sure that my exchange, a business critical application, is getting the drive space it needs.

Just my $0.02



John Weber -> RE: Scheduled Maintenance (4.Feb.2009 2:20:14 PM)

yes, this is what I would do.



catzodellamarina -> RE: Scheduled Maintenance (4.Feb.2009 2:24:45 PM)

Thanks guys.  Yes, we're in the middle of this discussion.  I do need to run offline defrag to get my space back.  Now it's just finding the time to do it.  Anyone have an idea how long a defrag to get whitespace back will take on a 460 Gig db?  I KNOW I'm going to be asked this and when I say "Unknown" I'll be sent back to the drawing board.  Around here they want hard numbers not guesses.



Nazim -> RE: Scheduled Maintenance (4.Feb.2009 3:23:56 PM)

How many mailboxes are currently present in this 460 Gig DB?
The offline defrag does 4-6 Gig  per hour depending on the HDD Hardware.



catzodellamarina -> RE: Scheduled Maintenance (4.Feb.2009 3:34:32 PM)

I've read that backing up an Exchange db at the same time as running Maint, causes the online defrag to be suspended until after the backups have completed. 

Does this rule apply when you're runing a doc level backup as well?


487 mailboxes



John Weber -> RE: Scheduled Maintenance (4.Feb.2009 5:05:58 PM)

If I was you, I would create new storagegroups/databases and move the users.
Be a lot faster and down time would be limited to those users who are actively moving.

Be a bit of a hit on storage.

eseutil time varies based on hardware speed - primarily (assuming good server host) on your drive/array performance.



catzodellamarina -> Moves (4.Feb.2009 5:17:51 PM)

Yes, I'm moving small users to new SG's.  I will not have enough space remaining to finish the move.  We've basically painted ourselves into a corner when we made 1 SG, 1 DB, and a mob rules for 400 people.  Looks like 3 days of downtime is the sacrifice needed to get this corrected.



Nazim -> RE: Moves (4.Feb.2009 6:06:58 PM)

Did you find out how much of white space does this DB has ?
If its gona take downtime of 3 days i would just move all the users from this DB, Just delete this DB. Create a new DB and move back the user.



catzodellamarina -> RE: Moves (5.Feb.2009 10:33:58 AM)

According to the event - 133 GB of free space is available.  It looks like I got 10 GB of it back overnight. 



Nazim -> RE: Moves (5.Feb.2009 6:25:02 PM)

But still the physical size of the DB will not decrease until an offline defrag is performed.



catzodellamarina -> RE: Moves (6.Feb.2009 2:33:08 PM)

It sounds unanimous that I must run an offline defrag.  I met with mgmt. on this and we're prepared to run next weekend.  We'd all like to avoid ever having to run an Offline again.  Is this realistic?  Explain to me - does everyone have to perform an offline from time to time to get back their whitespace?  OR.. will a small DB, with properly scheduled Online Maint finishing every night, keep a tidy DB and you may never need to run an OFFLINE?

If we had an emergency cleanup of mailboxes, and set "keep deleted to 0 days" would this free space with ONLINE maint?

Does the Offline run until it stops or can it be canceled?  If cancelled will it pickup where it left off or is all your defrag now a mess or changes are disgarded?

When you run OFFLINE maint, do you need equal amount of space available to complete?  If so, can this space be on a different volume?



a.grogan -> RE: Moves (6.Feb.2009 3:08:53 PM)

Hiya chap,

An offline defrag should not be part of a regular maintenance schedule for Exchange - it is difficult to say that you will "never" have to run it again - that will of course depend on what you do from now on.
You can set don't keep deleted mailboxes - but that will not have an effect on the overall size of the store as the mailbox once existed - the space that it occupies will only be reclaimed within the internals of the database (the on-line defrag that has been mentioned) - from the data that you have supplied it looks like that your data store will shrink by 133GB - if might be an idea after the defrag to split the mailboxes up in to a couple of Databases - really a good target size for an Exchange DB is < 200GB.

You can cancel the offline defrag by pressing CTRL-C - however if you restart, it will go from the beginning again (it reads the DB page by page) - typically you need 110% of the size of the DB free on the Defrag drive and you can redirect the defrag to another volume - this should be a local disk.

I did an article here which might help: http://www.telnetport25.com/index.php?option=com_content&view=article&id=118:when-to-use-eseutils-to-defrag-your-databases-or-when-not-to&catid=2:catexchange2003

And I also write and GUI for ESEUTIL located here:

Exchange 2003: http://www.telnetport25.com/index.php?option=com_content&view=article&id=184:exch2003apps&catid=25:exchange-2003-applications&Itemid=32

Exchange 2007: http://www.telnetport25.com/index.php?option=com_content&view=article&id=198:eseutils-gui-version-12-exchange-2007&catid=26:exchange-2007-downloads&Itemid=37

Cheers

A



catzodellamarina -> ESEUTIL explained (6.Feb.2009 4:04:12 PM)

Thanks for the great feedback and links.  The article on runnning the util on a non-Exch server solves my disk space issue.

I've heard 100 - 200 Gig are good sizes to manage a DB.  Is this a Microsoft best practice?



Nazim -> RE: ESEUTIL explained (6.Feb.2009 8:27:00 PM)

Yes, Microsoft recommends 100 GB DB without CR and 200 GB with CR as the maximum database sizes for Exchange 2007.

And as Grogan said you cannot rule out the possibility of defrag in future. But still you can avoid it for a long time by the monitoring the online maintenance and allow the full pass to complete.

Smaller the database less time it takes for the online maintenance to complete the full pass.



catzodellamarina -> New Databases (9.Feb.2009 1:09:34 PM)

I want to thank all for assiting me.  It's been a long road and we're finally getting arms around our Exchange situation.  I think I've found a work around for the lengthy Offline defrag, which has everyone worried in regards to downtime.  How does this sound:
I'm going to attach my CCR servers to the SAN with a f/c cards.
Carve out space on the SAN for all of my mailboxes x 2 (room for future ESEUTIL)
Move ALL mailboxes to SAN, seperated into 5 storage groups - setup with quotas.
Delete the old db.






a.grogan -> RE: New Databases (9.Feb.2009 1:40:55 PM)

Sounds like a good move - however be mindful of the following:

1. If the SAN is shared with other data (e.g. SQL, File Share) make sure that you have enough IO capacity to handle Exchange.

2. Make sure that you take into account the logs and DB best practice rec's when placing the new SG's (RAID 10 for DB - or RAID 5 if you are working to a budget with RAID 1 for the logs - both on separate LUNS).

Cheers



Page: [1]