场景：我使用专用卷（RAID 卷）来存储我的 Exchange 2007 服务器的所有数据。今天，出于好奇，我决定检查一下此数据卷上的文件碎片程度。令我惊讶的是，答案是极其碎片化的。因此，问题分为三部分：
首先，我应该整理这个卷吗（当然是在完整备份之后）？如果不应该，请具体说明为什么不做；如果应该，请说明绝对应该做的理由。
其次，在这个维护期间，每 GB 大约需要多少时间。驱动器都是 7200 RPM SATA 驱动器，安装在硬件 RAID 5 控制器（Perc 5i/6i，记不清了）上，文件非常零散。（每 GB 超过 5000 个文件碎片）。
第三，这里有什么问题吗？在我看来，驱动器不应该有这么多碎片。是否有配置错误导致这种情况发生？
答案1
您是否将数据库文件和事务日志存储在同一卷上？
这可能是造成这种分裂的原因（也可能是确实不建议）。
事务日志是大量动态创建的小文件，而主数据库文件却不断增长；这是造成严重 NTFS 碎片化的理想原因。
我认为除了交易所之外没有别的了数据库就这个数量而言...邮件队列也可能是造成碎片的一大原因。
答案2
关于碎片整理：如果可以避免，就不要这样做。
您有可用空间吗，即使是在外部驱动器上？只需停止 Exchange 服务，将所有内容复制到其他位置，格式化卷，然后再次将所有内容复制回来。
或者，如果您有适当的备份软件和设备，请进行备份/恢复。
现场磁盘碎片整理是生产系统上最慢、最危险的操作之一。而 RAID 5（写入速度相当慢）在这方面确实没有帮助。
答案3
0/3。该卷上除了数据库文件 (*.edb 和 *.stm) 之外还有其他文件吗？我想您可能会说我在问专用程度如何。我曾经看到过由存储在 Exchange 卷上的卷影副本引起的严重碎片。在较小的安装中，在同一卷上看到索引文件、日志文件、smtp 队列、mta 队列并不罕见。其中任何一个都会导致数据库文件碎片化。
操作系统碎片整理不会给您带来问题，但如果您的驱动器上没有大量可用空间，我预计它不会产生太大作用。我认为您会想要停止信息存储服务。大多数关于碎片整理 Exchange 的文档都侧重于 Exchange 数据库中空白空间的逻辑碎片，而不是文件级碎片。http://msexchangeteam.com/archive/2004/10/25/247342.aspx讨论了这一点，并提到在文件级碎片整理期间日志记录对延迟写入感到困惑。
我不太清楚速度/时间的计算。我有点太忙了，没时间做数学题。