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 >
> -----Original Message-----
> From: Mark Simmons [mailto:mds@gbnet.net]
> Sent: Tuesday, June 08, 2004 7:45 AM
> To: SKIP HOFMANN
> Cc: 'avarni@tech.cj.com'; Waters, G Scott THE LOG.SEC TEAM;
> Borders, Rich; toasters@mathworks.com
> Subject: Re: Defraging the excahgne DB
>
> Turning the question around, why would it not be safe to
> defragment a file on the filer?
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.
>
> SKIP HOFMANN wrote:
>
> >If you use Waffle scan then this defrags the entire vol
> 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.
> Otherwise
> >I've run this many times with no problems. Make sure you aren't
> >over your snapshot reserve and your scan should 'continue'.
You should have no snapshots.
> >
> >On Mon, 7 Jun 2004, Waters, G Scott THE LOG.SEC TEAM wrote:
> >
> >]
> >] WOW ... this is the exact opposite of what NetApp support told me.
> >]
> >] On a volume used for storing Exchange data, the WAFL SCAN
> REALLOCATE
> >command
> >] will never complete.
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.
> >] We monitor the layout ratios weekly and schedule down time
> to perform an
> >] offline DEFRAG every 4 - 6 weeks.
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.
> >] This is all based on information received at the time ...
> If NetApp has
> >] fixed this then someone enlighten me.
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