2011-05-24 03:57 PM - edited 2015-12-18 01:26 AM
I am hoping someone can help me out here.
I have an old Exchange 2003 setup running on a FAS2020, and there's a daily scheduled Exchange policy task that performs a "online defrag" of our databases.
I assume this is a very bad idea and therefore i have done the right thing in disabling it?
And is it normal that an Exchange 2003 defrag (all SGs are <100Gb) causes such a performance hit on the filer?
The FAS2020s are not very powerful, and I was going crazy trying to find out what process was sucking IOPs from the FAS during the evenings - and it seems that this is the culprit.
Anyone had similar issues or know if I've done the right thing here?
2011-05-25 01:11 AM
You will probably need to run defrag on your Exchange databases with some frequency or Exchange will show its true face and slow to a creep and you'll be in trouble with pretty much everyone. Microsoft default settings for defrag are very aggressive and basically they don't think that your storage has anything else to do than optimize their concept of mail storage all night, every night.
The best plan is to probably find out how often it really needs to be done (there is probably some tool or log that will help here, I'm not an Exchange admin) and then to run 'reallocate' jobs on the NetApp side after the Exchange defrag is done. Then you will have the most optimal layout.
2011-05-25 03:48 AM
Can you explain a little bit more about the "reallocate" please? I've not used this before on our filers - in fact, it was the first I've heard of it!
I was always led to believe that Filers required no "defragging" due to the way the Waffle file system worked - in fact, I am sure that was one of the selling points!
Anyway, I've read-up about "reallocation" but I still cannot fathom why or in which cases its important to use.
In this case it looks like you're suggesting that after Exchange has done an online defrag, I should then perform a filer "defrag/reallocation" on the Exchange volumes?
(Regarding the Exchange online defrag and whether its needed, this is something that Microsoft seems to recommend. Without it Exchange performance can slow down. So disabling online defrag in Exchange is not an option. We will simply schedule it weekly/bi-weekly rather than daily ;-).
2011-05-25 04:27 AM
You can read more about reallocation in the ONTAP System Administration Guide for your release on the NOW site, under "System performance and resources"... i.e.:
2011-05-25 05:06 AM
Again, thanks for the link.
I am now sure reallocation will improve my performance issues. After reading the guide, running a "reallocation measure -o" and hearing your experiences, I think its clear that my larger volumes are highly fragmented and therefore impacting operations that require many sequential reads - like Exchange/SQL verification.
2011-05-25 11:01 PM
You may find the following Windows IT Pro White Paper useful for information on defragmrnting your server without having to take it offline, etc:
It is definitely vital to defrag your server's files and to keep fragmentation levels low. You should take a look at using Diskeeper 2011 as it is completely transparent and will defrag your server without having to take it offline. It alss prevents most fragmentation from occurring in the first place. You can get a free trial for the Server and/or Enterprise server at their site.
2011-05-26 05:36 AM
The discussion here is about standard maintenance routines that you will find in most databases. "Vacuuming" or re-indexing or optimizing or defrag'ing are standard optimizing routines that many software packages require to work around "fragmentation" atrophy that happens as the data structures grow through insert and delete operations. In this case it is not a "no-no". The only thing you really need to remember is: Application first. Reallocate second.
2011-05-26 05:48 AM
I guess it wasn't entirely apparent for me that you were addressing your comments to the "diskkeeper" software, per se. Since these threads will also be read, perhaps in haste, as reference information in the future, I just tried to clarify that what the original poster wanted wasn't defragging per se.
So, diskkeeper may be a "no-no" but "vacuuming" routines from applications are required and a subsequent reallocate will give or reclaim performance advantages.