SBS 2003 Exchange Store的每周在线Defrag是否足够频繁？

Question

(这篇文章有点长，所以对于那些坚持到底的人来说，advTHANKSance )

我有一个客户端，它的SBS 2003服务器每晚突然开始崩溃。坠机的症状本身就很奇怪。一般情况下，系统就会冻结。我仍然可以在屏幕上看到Windows界面，但系统本身对鼠标和键盘操作没有响应。最终，我不得不硬启动服务器，才能让它再次运行(丑陋)。

在查看了系统日志之后，我注意到，在系统的Exchange上的联机维护过程开始之后不久，私有商店就发生了崩溃。在线维护计划每天晚上在下班时间进行。我相信定在凌晨1点到4点。

由于在线维护过程是崩溃的先兆，我将它们全部禁用，直到我能够找出问题的真正根本原因。例如，我想确保这个问题与硬件故障无关。

在禁用在线维护之后几周过去了，服务器运行得很好，但我注意到Exchange商店的大小比平常增长得更快。我认为这是因为像在线碎片整理这样的事情并没有发生。我知道我最终需要让在线维护任务再次运行，但我无法安排它们在工作日晚上开始，因为服务器是生产任务的第一件事--每天早上。

我对崩溃的一种预感是，在线维护过程与其他计划中的任务(例如，VSS进程、备份等)发生了冲突。

为了测试这种预感，我将私人商店的在线维护安排在周日凌晨进行，并确保在同一时间内不会安排其他预定任务。

周六晚上，我完全睡着了，希望醒来后发现服务器在我周日早上醒来时已经崩溃了。让我松了一口气的是，它没有坠毁。我检查了系统日志，并注意到在线维护过程已经成功完成。

因此，我倾向于允许此特定服务器上的Exchange数据库的在线维护过程每周运行一次(每个周日上午)。这将让我有机会看看我的直觉是否正确，或者是否还有其他一些需要纠正的潜在问题(比如硬件故障)。

我的问题是(谢谢你阅读我的“小说”到现在为止).允许在线维护过程每周进行一次而不是每晚进行一次是否足够？不每天晚上做这个任务有什么坏处？

Answer 1

数据库维护过程清除超过为邮箱存储配置的保留日期的项，并执行其他几项任务。它允许在不增加物理文件大小的情况下创建新项。我会查看删除项目保留设置，并确保它们是适当的。至于物理文件大小，联机碎片整理不会缩小物理文件，只有脱机碎片整理才能做到这一点。如果您认为文件的增长速度超过了数据库维护的速度，那么您应该考虑减少已删除项的保留时间。至于邮箱存储维护是否导致崩溃，这取决于数据库的大小和清理它的工作量。我可以从我的经验告诉你，我认为这是值得怀疑的。如果是的话，可能是由于硬件不足或故障造成的。我管理一个Exchange2003Server (Enterprise )，它的4个邮箱存储都超过100 an，由650个邮箱组成，并且我运行邮箱存储维护过程没有任何问题。

我要指出的一点是，您应该将邮箱存储维护和备份安排在不同的时间窗口中，因为两者不能同时运行。当发现备份已启动时，malbox数据库维护过程将停止。如果这两个任务发生冲突，那么您的数据库维护过程可能永远不会完成。下次停下来的时候它会捡起来的。您可以检查应用程序事件日志中的事件ID 1207 (它表示超过保留日期的项的清理已经完成)、事件ID 1209 (表示维护任务完成)和事件ID 1221 (表示联机碎片整理完成)。

还请注意，该进程将运行至少15分钟和最长1小时。您在维护计划中配置的时间是它可以运行的时间，而不是它将运行的时间。

下面是对该流程所做工作的简要介绍：

http://support.microsoft.com/default.aspx?scid=kb;en-us;324358

Answer 2

纯粹问碎片整理，答案将是“这取决于。”首先，它有多零散？邮件服务器的使用率有多高？一开始，很少使用的邮件服务器几乎不会有很大的碎片。

我想你只要看看这份工作需要多长时间，就能得到大致的估计。这份工作是否可以很容易地安装到你允许的维修窗口？

如果运行的碎片整理适合于您分配的时间，并且在运行之间没有遇到性能问题(或请求错误)，那么是的，就可以使用您的变通调度来整理存储。

碎片整理并不能保证Exchange存储的正常运行。如果您从未对其进行碎片整理，Exchange服务器就不会死。性能可能会随着时间的推移而下降，最终会爬行，但它不会因为数据不是碎片而上升、丢失或损坏。