Re: Another Exchange Defrag argument
- From: Leythos <Void@xxxxxxxxxxx>
- Date: Tue, 13 Feb 2007 16:16:17 -0600
On Tue, 13 Feb 2007 12:27:02 -0800, TPGBrennan wrote:
I agree doing an offline defrag should be a last resort for several reasons.
However, a question has come up about the use of a third-party file-level
defrag utility on Exchange servers.
We run Exchange 2003 Enterprise Edition so the store size is not limited to
16GB. The stores are fragmented, some with a thousand fragments. Online
defragmentation is not going to help with this potential I/O problem; it will
simply arrange the white space within the database neatly. As the database
continues to grow it will grab some of the fragmented free space on the
volume, making the database file even more fragmented.
Is there any real information available about the I/O penalty of having an
Exchange database file fragmented, or the potential issues with running a
file level defrag utililty to defrag both the white space and the overall
database file. The current versions of full-time defrag programs are not
very I/O intensive so that is not a valid concern.
I can't help with Exchange, but, if you consider SQL, well, I've always
seen improvement in queries when defragmenting the SQL Database files.
In some instances, where a 740GB database was unable to provide web
queries before they timed out, we took the database off-line and then did
a defrag with Diskeeper, reattached the database, and the web site started
working like it was new again. We did no other changes, just the file
level defrag.
I've seen this across many servers with SQL databases - much like the lack
of free space in a database with a clustered index. If you can stop the
SQL service and defragment on a schedule you get back lots of performance
(but that would depend on your situation).
I believe that many services that hold their own databases benefit from
this, but it depends on the way the service uses the database.
--
Leythos
spam999free@xxxxxxxxxx (remove 999 for proper email address)
.
- Prev by Date: Re: Question on KB926666 which can lead to KB932599
- Next by Date: Re: Can't telnet to port 25
- Previous by thread: Re: Another Exchange Defrag argument
- Next by thread: Upgrading from mixed to native mode
- Index(es):
Relevant Pages
|