scheme：我使用专用卷（RAID卷）来存储我的Exchange 2007服务器的所有数据。 今天，出于好奇，我决定检查这个数据卷上的文件是多么的碎片化。 令我惊讶的是，答案是非常的。 所以，有三个问题：
首先，最重要的是，我应该整理这个卷（经过一个完整的备份当然）？ 具体到为什么不，如果我不应该，或者我绝对应该如果我应该的原因。
其次，在每个千兆字节的维护期间，我应该允许多less时间。 这些驱动器都是硬件RAID 5控制器上的7200 RPM SATA驱动器（Perc 5i / 6i，不记得），这些文件非常分散。 （每千兆字节超过5000个文件碎片）。
第三，这里有什么不对吗？ 在我看来，驱动器不应该是这种支离破碎。 可能有东西configuration不正确，可能导致这种情况发生？
您是否将数据库文件和事务日志存储在同一个卷上？
这将成为这样一个分裂的原因（也是绝对不推荐）。
事务日志是在飞行中创build的大量小文件，而主数据库文件不断增长; 这是重NTFS碎片的理想配方。
我假设没有任何东西在该卷上的Exchange 数据库 …邮件队列也可以是一个很大的碎片来源。
关于碎片整理：不要这样做，如果你能避免它。
你有没有可用的空间，即使在外部驱动器上？ 只需停止Exchange服务，将所有内容复制到其他位置，格式化该卷并将所有内容都复制回来。
或者做一个备份/恢复，如果你有适当的备份软件和设备。
就地磁盘碎片整理是您可以在生产系统上执行的最慢和更危险的操作之一。 而RAID 5（这在写作上相当慢）在这里真的没有帮助。
0/3。 该卷上是否有其他数据库文件（* .edb和* .stm）？ 我想你可以说我问的是如何敬业。 我曾经看到阴影副本存储在交换卷上造成的严重碎片化。 在较小的安装中，在同一卷上看到索引文件，日志文件，smtp队列，mta队列并不罕见。 任何这些都会导致数据库文件碎片化。
一个操作系统碎片整理不会引起你的问题，但如果你没有大量的驱动器上的可用空间，我不希望它做了太多。 我想你会想停止信息存储服务。 大多数关于磁盘碎片整理的文档都侧重于交换数据库中的空白逻辑碎片，而不是文件级碎片。 http://msexchangeteam.com/archive/2004/10/25/247342.aspx讨论了这一点，并提到日志logging在文件级碎片整理期间被延迟写入困惑。
我不确定速度/时间计算。 我有点太忙，不想去做math。