（这篇文章有点长，所以非常感谢那些坚持读到最后的人）
我有一个客户的 SBS 2003 服务器突然每晚都会崩溃。崩溃本身的症状很奇怪。通常系统会冻结。我仍然可以在屏幕上看到 Windows 界面，但系统本身对鼠标和键盘操作没有反应。最后我不得不硬启动服务器才能让它再次运行（太丑了）。
在查看系统日志后，我注意到崩溃发生在系统的 Exchange 私人商店的在线维护过程开始后不久。在线维护计划在每天晚上下班时间进行。我相信时间是凌晨 1 点到 4 点。
由于在线维护进程是崩溃的前兆，因此我将它们全部禁用，直到我找出问题的真正根本原因。例如，我想确定问题与硬件故障无关。
禁用在线维护几周后，服务器运行正常，但我注意到 Exchange 存储大小增长速度比平时快。我把这归咎于没有进行在线碎片整理之类的事情。我知道我最终需要重新运行在线维护任务，但我无法安排它们在工作日晚上启动，因为服务器每个工作日早上都需要执行生产任务。
我对崩溃的一个预感是，在线维护过程与大约在同一时间发生的其他计划任务（例如，VSS 过程、备份等）发生冲突。
为了验证这个猜测，我将私人商店的在线维护设置为周日凌晨进行，并确保在同一时期没有安排其他计划任务。
周六晚上我睡着了，满以为周日早上醒来时会发现服务器已经崩溃了。让我松了一口气的是，服务器并没有崩溃。我检查了系统日志，发现在线维护过程已成功完成。
因此，就目前情况而言，我倾向于允许此特定服务器上的 Exchange 数据库的在线维护过程每周（每个星期日早上）运行一段时间。这将使我有机会看看我的直觉是否正确，或者是否存在其他需要纠正的潜在问题（例如硬件故障）。
我的问题是（感谢您阅读我的“小说”到这里）... 允许在线维护过程每周进行一次而不是每晚进行一次是否足够？不每晚执行此任务有什么缺点？
答案1
数据库维护过程会清理邮箱存储配置的保留日期以外的项目，并执行其他几项任务。它允许创建新项目，而无需增加物理文件大小。我会查看已删除项目的保留设置，并确保它们合适。至于物理文件大小，在线碎片整理不会缩小物理文件，只有离线碎片整理才会这样做。如果您认为文件增长速度超过了数据库维护速度，那么您应该考虑减少已删除项目的保留时间。至于邮箱存储维护是否导致崩溃，这取决于数据库有多大以及清理工作量有多大。根据我的经验，我可以告诉你，我认为这是值得怀疑的。如果是，可能是由于硬件不足或故障。我管理一个 Exchange 2003 服务器（企业版），其中有 4 个邮箱存储，全部超过 100GB，由 650 个邮箱组成，我运行邮箱存储维护过程没有任何问题。
我想说的一点是，您应该在不同的时间窗口安排邮箱存储维护和备份，因为两者不能同时运行。当检测到备份已开始时，恶意邮箱数据库维护过程将停止。如果这两个任务发生冲突，那么您的数据库维护过程可能永远无法完成。它将在下次中断的地方继续。您可以检查应用程序事件日志中的事件 ID 1207，这表示保留日期之后的项目清理已完成，事件 ID 1209 表示维护任务已完成，事件 ID 1221 表示在线碎片整理已完成。
还请注意，该过程将运行至少 15 分钟，最多 1 小时。您在维护计划中配置的时间是它可以运行的时间，而不是它将运行的时间。
以下是该过程的简要说明：
http://support.microsoft.com/default.aspx?scid=kb;en-us;324358
答案2
如果单纯询问碎片整理，答案是“视情况而定”。首先，碎片化程度如何？邮件服务器的使用频率如何？一个几乎不使用的邮件服务器首先几乎不会遭受太多碎片化。
我想你可以通过查看这项工作需要多长时间来得到一个大概的估计。这项工作是否适合你为碎片整理预留的维护时间？
如果您运行的碎片整理适合您分配的时间，并且您在运行之间没有遇到性能问题（或引发错误），那么是的，使用您的解决方法计划对商店进行碎片整理就足够了。
碎片整理并不是为了让 Exchange 存储保持运行。如果您从不进行碎片整理，Exchange 服务器就不会死机。性能可能会随着时间的推移而下降，最终变得缓慢，但它不会因为没有进行碎片整理而丢失数据或损坏。