<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.technet.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Do we need to file-level defragment Exchange database drives?</title><link>http://blogs.technet.com/exchange/archive/2004/10/25/247342.aspx</link><description>Every so often there is a question: "Should we run file-level defragmentation software on Exchange servers?" Usually, this comes from confusion that file system defragmentation actually helps Exchange as - well, Exchange databases get fragmented too.</description><dc:language>en-US</dc:language><generator>CommunityServer 2.1 SP1 (Build: 61025.2)</generator><item><title>re: Do we need to file-level defragment Exchange database drives?</title><link>http://blogs.technet.com/exchange/archive/2004/10/25/247342.aspx#247386</link><pubDate>Mon, 25 Oct 2004 19:36:00 GMT</pubDate><guid isPermaLink="false">d5e57398-b9ef-4490-9955-07cbb4e4a80d:247386</guid><dc:creator>Ash</dc:creator><description>Interesting observation.&lt;br&gt;&lt;br&gt;Based on my own experiences I’ve experienced quite a noticeable increase in performance after running regular file-level defrag. This is done off peak hours of course and only after backup as run its due course.&lt;br&gt;&lt;br&gt;Further more I’ve been in disaster recovery situations where we had Eseutil taking 7-8 hours before completing even one pass at a 9Gb badly corrupted store. The reason we found out was 30’000+ fragments at the file level. After we ran defrag a few rounds hours spent with Eseutil decreased to a “mere” 4-5. Obviously the store was in deep trouble regardless.&lt;br&gt;&lt;br&gt;Since Exchange accesses the stores in a random fashion it makes sense that defrag should not make out to a huge difference, but I personal experience is that with regular file-level defrag, you will not really notice the I/O hit. For a system that is continuously busy 24/7 I agree that this might be a problem.&lt;br&gt;&lt;br&gt;</description></item><item><title>re: Do we need to file-level defragment Exchange database drives?</title><link>http://blogs.technet.com/exchange/archive/2004/10/25/247342.aspx#247457</link><pubDate>Mon, 25 Oct 2004 22:37:00 GMT</pubDate><guid isPermaLink="false">d5e57398-b9ef-4490-9955-07cbb4e4a80d:247457</guid><dc:creator>TJ</dc:creator><description>I think the thing to remember is the best way to prevent fragmentation of the store is to first defragment the servers disk drive before creating the store.  And keep other file I/O off that drive.  If possible, NTFS should append your growing store to the next logical block.  &lt;br&gt;&lt;br&gt;Also, if you defragment a second drive, and move your store from one drive to another, you should reduce the fragmentation as well.  &lt;br&gt;&lt;br&gt;I agree defragmenting a RUNNING server is a disaster waiting to happen.</description></item><item><title>Exchange, XP, Office, Article, Holiday Fun</title><link>http://blogs.technet.com/exchange/archive/2004/10/25/247342.aspx#247963</link><pubDate>Tue, 26 Oct 2004 20:09:00 GMT</pubDate><guid isPermaLink="false">d5e57398-b9ef-4490-9955-07cbb4e4a80d:247963</guid><dc:creator>Windows Server Clustering </dc:creator><description /></item><item><title>re: Do we need to file-level defragment Exchange database drives?</title><link>http://blogs.technet.com/exchange/archive/2004/10/25/247342.aspx#248942</link><pubDate>Thu, 28 Oct 2004 07:42:00 GMT</pubDate><guid isPermaLink="false">d5e57398-b9ef-4490-9955-07cbb4e4a80d:248942</guid><dc:creator>Fox</dc:creator><description>&amp;#192;s reply to TJ, I do agree that - at first - it does help to first Defrag your system before creating a store. &lt;br&gt;&lt;br&gt;However, in our case the data stores are moved/created to a completely different volume which was completely empy - just formatted.&lt;br&gt;&lt;br&gt;After migrating all our data from groupwise and a month worth of production, our database has grown to 81GB... when using the analyze feature of defrag I only see a huge amount of red and next to none of blue lines...&lt;br&gt;&lt;br&gt;Perhaps this is due to the nature of the Jetbase engine. Personally I like the system of Oracle better where the database has a particular filesize to start with so there simply won't be any fragmentation. (provided ofcause again that the drive was unfragmented to start with.)</description></item><item><title>re: Do we need to file-level defragment Exchange database drives?</title><link>http://blogs.technet.com/exchange/archive/2004/10/25/247342.aspx#251744</link><pubDate>Wed, 03 Nov 2004 16:41:00 GMT</pubDate><guid isPermaLink="false">d5e57398-b9ef-4490-9955-07cbb4e4a80d:251744</guid><dc:creator>Greg/Microsoft MVP - Windows File Systems</dc:creator><description>Some more observations:&lt;br&gt;&lt;br&gt;- Microsoft's defrag APIs fully and safely support defragmentation of Exchange datastores without first shutting down Exchange services.&lt;br&gt;&lt;br&gt;- While I agree that kicking off a defrag pass on a drive with a heavy I/O load can result in a slowdown in drive performance, it does NOT mean that it is unsafe to do - regardless of application (file serving, Exchange, SQL, etc...)&lt;br&gt;&lt;br&gt;- I have searched for several years now for information from Microsoft indicating that it is unsafe to run a file-level defragmenter on drives where Exchange datastores/files are located and have yet to find any whatsoever.&lt;br&gt;&lt;br&gt;While many Exchange people strongly believe that it is unsafe, they are never able to point to a definitive source (Microsoft) to justify.  Usually it is, &amp;quot;somebody told me it was unsafe&amp;quot; or &amp;quot;I heard it was unsafe&amp;quot;.&lt;br&gt;&lt;br&gt;Greg/Microsoft MVP - Windows File Systems&lt;br&gt;&lt;br&gt;</description></item><item><title>Exchange, XP, Office, Article, Holiday Fun</title><link>http://blogs.technet.com/exchange/archive/2004/10/25/247342.aspx#267018</link><pubDate>Sat, 20 Nov 2004 00:57:00 GMT</pubDate><guid isPermaLink="false">d5e57398-b9ef-4490-9955-07cbb4e4a80d:267018</guid><dc:creator>Windows Server Clustering </dc:creator><description /></item></channel></rss>