Don't forget there are BIG differences between a FILER 'WAFL SCAN REALLOCATE' and an "ESEUTIL /d".
In general it is a good rule to offline defrag your Exchange databases on a regular basis - it reclaims unused space. I don't know about others, but for me it can reclaim 10GBs of disk space. It is just a nice coincidence that performing an ESEUTIL defrag lays down a new copy of the database on the FILER and the LAYOUT ratio by definition is low.
My point is that (in my opinion) just doing a WAFL SCAN REALLOCATE (provided you can get it to work) isn't enough. Eventually you need to run an ESEUTIL.
- Scott W.
-----Original Message----- From: Borders, Rich [mailto:Rich.Borders@netapp.com] Sent: Tuesday, June 08, 2004 9:28 AM To: Mark Simmons; SKIP HOFMANN Cc: avarni@tech.cj.com; Waters, G Scott THE LOG.SEC TEAM; toasters@mathworks.com Subject: RE: Defraging the excahgne DB
< I am replying in-line >
Filer defrag requires two things ( as a general rule ):
20 percent volume space free, and no snapshots. The rest is shuffling blocks into a more application friendly pattern.
From the point of view of the client nothing should change surely?
If you do offline defrags and meet the above requirements, you will effectively have an offline application and a well organized 'efficient' database afterwards.
If it did, that would be a fairly significant problem with all files, not just Exchange's database.
Technically, you can defrag a file, or the volume. The wafl scan reallocate function is trying to get the blocks closer to their layer 0 and one pointers. Defrags are really only a problem if you don't get the first two pre-req's right.
See above.
And if so is
it safe to use on your exchange DB?
Yes.
At least on 6.3.2 -- I've noticed that WAFL SCAN REALLOCATE will 'pause' indefinately IFF you're over your snapshot reserve.
It is usually a funciton of not finding any blocks that aren't in worst fragmented shape that what you are already in. A factor of 20% free volume space with NO snapshots all but ensures this will not happen.
You should have no snapshots.
No one in NGS support should have told you it will never complete. In 6.3 and greater, it was more optimized and cleaned up, but that was a testamanet to the way block handling was done and some major efficiencies that were built into the OS of Data OnTap.
It goes for a while and then stalls.
See above.
The remarkable thing about an offline defrag is that it effectively copies the entire mailstore in application defrag back to the Filer. This means that the application is defraged as it is written. The wafl is defragged due to the nature of the blockmap and nvram/journaling. It is almost perfect.
It is fixed, and getting better. Keep your eye open as there will be some new things to come also.
I would also like to offer a thinking 'outside the box' and say that it is a cool idea to QSM the mail store from one volume to another since a QSM is a process that is going to defrag on WAFL ( not application though ) and then update on a scheduled basis. Once snapmirrored, you can stop and quiesce the application, then quiesce and break the QSM and that makes the destination read / writable. You point the exchange server to the destination, and voila, you have a reallocate and only a short downtime.
] ] - Scott W.
That is all for now.
/rich
Comments in-line.
--On 08 June 2004 17:13 -0400 "Waters, G Scott THE LOG.SEC TEAM" gswaters@apgea.army.mil wrote:
Right. I mean, fundamentally a file on a filer is a linear array of bytes to both the filer and to Exchange.
Exchange lays stuff out inside that linear array of bytes, and conceivably reordering that might make Exchange more efficient in some arcane way, and reclaim some space... though that sounds like a fundamental problem with Exchange to me. Leave that though.
The filer lays out the linear array of bytes over its disk blocks, and in its metadata files, and having it rearrange those things might make it more efficient in some arcane way. But filers are meant to be pretty-darned-good all the time and not need this kind of attention, so I'm inclined to think this is a hold over from nasty fs's like NTFS and FAT which seem to go out of their way to get messy and where steady-state performance isn't that much off pretty-poor performance.
The point is that neither activity should actually change in any way the way that the filer serves the data or the way the Exchange server uses the data except, maybe sometime things happen might happen quicker than had the respective tidying up not been done. Any change in what data is served or accessed would straightaway be a bug.
Hence my question, why would it not be safe?
Another salient question would have been, what do you want to achieve?
And one more would be, what makes you think that Exchange using a filer is in any way under-performing?
And finally, why would you want to expend occasional effort/downtime to gain some extra performance when that performance will decay away necessitating another expenditure of effort/downtime, when the filer and Exchange between them will probably settle into a not-perfect-but-not-pathological steady-state anyway?
Scott W wrote: **** And one more would be, what makes you think that Exchange using a filer is in any way under-performing?
And finally, why would you want to expend occasional effort/downtime to gain some extra performance when that performance will decay away necessitating another expenditure of effort/downtime, when the filer and
Exchange between them will probably settle into a not-perfect-but-not-pathological steady-state anyway? ****
Chronological instantiation of data in a database is inefficient. When we "defrag", we get back about 30GB for each of the 8 info stores we maintain.
-
James Brigman -
Mark Simmons -
Waters, G Scott THE LOG.SEC TEAM