（这篇文章有点冗长，所以对那些坚持到底的人来说，
我有一个客户，他的SBS 2003服务器突然开始崩溃，每晚。 崩溃本身的症状很奇怪。 一般来说，系统会冻结。 我仍然可以看到屏幕上的Windows界面，但系统本身对鼠标和键盘的操作没有反应。 最后，我不得不硬启动服务器，以使其再次运行（丑陋）。
在查看系统日志之后，我注意到在系统的Exchange私人存储开始在线维护过程之后不久就发生了崩溃。 在线维护计划在下class时间每天晚上进行。 我相信这是上午1点到4点。
由于在线维护过程是崩溃的先兆，我将它们全部禁用，直到我能够找出问题的真正根本原因。 例如，我想确定问题与硬件错误无关。
禁用联机维护后，几个星期过去了，服务器运行良好，但是我注意到Exchange Store大小的增长速度比平时快。 我认为这是事实，像在线碎片整理没有发生。 我知道我最终需要再次运行在线维护任务，但是我无法安排他们在平日晚上开始工作，因为每个工作日上午都需要服务器进行生产任务。
对于崩溃的一个预感是，在线维护过程与大约同时发生的其他计划任务（例如，VSS进程，备份等）紧密相关。
为了testing这个预感，我把星期天早上的私人商店的在线维护设置为发生，并且确定在同一时间段内没有其他的计划任务。
星期六晚上我睡着了，完全期待醒来，发现星期天早上醒来，服务器已经崩溃了。 为了我的安慰，它没有坠毁。 我检查了系统日志，注意到在线维护过程已经成功完成。
因此，我倾向于允许在特定服务器上的Exchange数据库的联机维护过程每周（每周日早上）运行一段时间。 这将使我有机会看到我的预感是否正确，或者是否有其他潜在的问题（如错误的硬件）需要纠正。
我的问题是（并感谢阅读我的“小说”到目前为止）…允许在线维护过程每周发生一次而不是每天晚上是否足够？ 每天晚上不执行这个任务的缺点是什么？
数据库维护过程将清理超出为邮箱存储configuration的保留date的项目以及执行其他几项任务。 它允许创build新的项目而不必增加物理文件的大小。 我会看看已删除的项目保留设置，并确保它们是适当的。 至于物理文件大小，在线碎片整理不会收缩物理文件，只有离线碎片整理可以做到这一点。 如果您认为文件增长超过了数据库维护，那么您应该考虑减less已删除的项目保留时间。 至于邮箱存储维护是否导致崩溃，这取决于数据库有多大，以及有多less工作正在清理。 我可以从我的经验告诉你，我认为这是可疑的。 如果是这样，这可能是由于硬件不足或错误。 我使用4个邮箱存储pipe理Exchange 2003服务器（企业版），邮件存储全部超过100GB，由650个邮箱组成，我运行邮箱存储维护stream程时没有任何问题。
我要说的一点是，你应该安排在不同的时间窗口的邮箱存储维护和备份，因为两者不能同时运行。 检测到备份已启动时，恶意软件数据库维护过程将停止。 如果两个任务冲突，那么您的数据库维护过程可能永远不会完成。 它会在下一次停止的时候启动。 您可以检查应用程序事件日志中是否存在事件ID 1207，表示清理过去保留date的项目已完成，事件ID 1209表示主要任务已完成，事件ID 1221表明联机碎片整理已完成。
另请注意，该过程将运行至less15分钟，最长1小时。 在维护计划中configuration的时间是可以运行的时间，而不是运行时间。
以下是过程的概要：
http://support.microsoft.com/default.aspx?scid=kb;en-us;324358
纯粹问到碎片整理，答案将是“这取决于”。 它首先是多么分散？ 邮件服务器的使用频率如何？ 几乎没有使用的邮件服务器将不会遭受太多的碎片。
我想你可以通过看看这个工作需要多长时间来得到一个估计。 这项工作是否容易进入您已经允许进行碎片整理的维护窗口？
如果您运行的碎片整理工作符合您分配的时间，而且您没有遇到运行之间的性能问题（或请求错误），那么是的，只需使用您的解决方法即可对商店进行碎片整理即可。
碎片整理不是为了保持Exchange存储运行。 如果您从不对其进行碎片整理，则Exchange服务器不会死亡。 性能可能随着时间的推移而降低，并最终被抓取，但不会因为没有进行碎片整理而造成数据丢失或损坏。