<<< I am replying in-line >>> 
 
	From: SKIP HOFMANN [mailto:SKIP.HOFMANN@ttisg.com] 
	Sent: Thursday, June 03, 2004 1:33 PM
	To: toasters(a)mathworks.com
	Subject: Defraging the excahgne DB
	
	
	Howdy
	 
	I have my exchange 5.5 DB pub and priv and my filler it's a
FAS250 and I want to know a few things
	 
	#1 can I run the eseutil utility if the DB is on my FAS 250 to
defrag the DB?
<<< This is doable as it is an offline defrag. The curious thing about
doing this is that you are accomplishing the APPLICATION defrag, and at
the same time getting a great by-product of a WAFL defrag. ( Essentially
a database re-write ) >>>
	 
	#2 is it the filer that determines if the exchange DB is
fragmented or not, and if it is how would I defrag the DB?
	 
<<<The Application can fragment ( very common and accounted for by an
online and offline defrag funciton in Exchange ) and the Filer can
fragment. I say that tounge in cheek because the fragmentation is really
only identified when you access the data. Since the database is one
large file the request for data in it is atypical, the data 'fragments'
over time. The blocks of the filer rarely match up to the blocks of the
database, so the issues becomes when you want to get a LOT of sequential
data from a large file ( aka mail store verify ) you will be essentially
asking the filer to scan through it's blocks at a super high rate of
speed.>>>
	#3 what happens to all other data that is stored on the same vol
as the exchange DB once I defrag this vol? ie snap shots 
<<<The Mail store can be reallocated or the volume can. I would
recommend the snapshots be removed as you can really get yourself into a
pickle by 'RE'-writing a database with an application defrag, or a WAFL
reallocate. If you are short on space, you need to get the snapshots out
of there. Snapshots are locked images and if the file system is
'fragmented' then it is unlikely that you are doing much more than
spinning your wheels if you are trying to defragment into a fragemnted
snapshot. >>>
	 
	#4 I ran a waffle scan and I got a reading of 1.8 si this
fragmented?
That is basically a ratio of actual file size ( df essentially ) to
block allocation. Ex. A one terabyte volume has a 500 gig database. If
it's layout is 1 then the File is essentially using the exact number of
blocks that a Filer of 500 gigs needs. If the layout were 1.8 then the
500 gig df would still be 500 but the block allocation would actually be
closer to the 900 gig . This is usually not an issue until the ratio
takes the block allocation higher then the volume size. A 2.1 layout
would mean that a 500 gig df would be 1.05 TB. This means you are
rescanning on a request of data on the last .05 TB. If the Filer were a
900 gig df, then a layout of 1.8 would be MUCH more impactful. It is not
the end of the world, you just have to manage it. You are on the right
track I can see, so good luck.
	Thanks a bunch
	 
	Skip
Rich Borders