SBS 2003 Exchange Storeの毎週のオンラインデフラグは十分な頻度ですか？
（この投稿は少し長いので、最後までそれを続ける人のためのアドバイス）
SBS2003サーバーが毎晩突然クラッシュし始めたクライアントがいます。クラッシュ自体の症状は奇妙でした。通常、システムはフリーズします。画面にWindowsインターフェイスは表示されていましたが、システム自体がマウスとキーボードの操作に反応しませんでした。最終的には、サーバーを再び動作させるためにサーバーをハードブートする必要があります（醜い）。
システムログを確認した後、システムのExchangeプライベートストアでのオンラインメンテナンスプロセスが開始された直後にクラッシュが発生していることに気付きました。オンラインメンテナンスは、毎晩営業時間外に行われるようにスケジュールされていました。午前1時から午前4時までに設定されたと思います。
オンラインメンテナンスプロセスはクラッシュの前兆であったため、問題の真の根本的な原因を突き止めるまで、それらをすべて無効にしました。たとえば、問題がハードウェアの障害に関連していないことを確認したかったのです。
オンラインメンテナンスを無効にしてから数週間が経過し、サーバーは正常に動作しましたが、Exchangeストアのサイズが通常よりも速く増加していることに気付きました。私はこれを、オンラインでの最適化などが行われていなかったという事実にまでこだわった。最終的にオンラインメンテナンスタスクを再度実行する必要があることはわかっていましたが、サーバーは平日の朝に最初に本番タスクに必要だったため、平日の夜に開始するようにスケジュールできませんでした。
クラッシュについて私が抱いた1つの予感は、オンラインメンテナンスプロセスが、ほぼ同時に発生していた他のスケジュールされたタスク（VSSプロセス、バックアップなど）と頭を悩ませていたことです。
その予感をテストするために、私はプライベートストアのオンラインメンテナンスを日曜日の朝の未明に行うように設定し、同じ期間に他のスケジュールされたタスクが予定されていないことを確認しました。
私は土曜日の夜、目を覚ますことを完全に期待して眠りに落ち、日曜日の朝に目が覚めるまでにサーバーがクラッシュしたことに気づきました。安心して、クラッシュしていませんでした。システムログを確認したところ、オンラインメンテナンスプロセスが正常に完了したことがわかりました。
したがって、現状では、この特定のサーバー上のExchangeデータベースのオンライン保守プロセスをしばらくの間毎週（毎週日曜日の朝）実行できるようにする傾向があります。これにより、自分の勘が正しいかどうか、または修正が必要な他の根本的な問題（ハードウェアの障害など）があるかどうかを確認する機会が得られます。
私の質問は（そしてこれまでの私の「小説」を読んでくれてありがとう）...オンライン保守プロセスを毎晩ではなく週に1回実行できるようにするのは適切ですか？このタスクを毎晩実行しないことの欠点は何ですか？
データベース保守プロセスは、メールボックスストアに構成された保存日を超えたアイテムをクリーンアップし、他のいくつかのタスクを実行します。これにより、物理ファイルサイズを大きくすることなく、新しいアイテムを作成できます。削除済みアイテムの保持設定を調べて、それらが適切であることを確認します。物理ファイルサイズに関しては、オンラインデフラグは物理ファイルを縮小せず、オフラインデフラグのみが縮小します。ファイルの増加がデータベースの保守を上回っていると思われる場合は、削除されたアイテムの保持時間を短縮することを検討する必要があります。メールボックスストアのメンテナンスがクラッシュの原因であるかどうかに関しては、データベースのサイズと、データベースのクリーンアップに行われている作業量によって異なります。私の経験から、それは疑わしいと思います。そうである場合は、ハードウェアが不十分または故障している可能性があります。 Exchange 2003サーバー（Enterprise Edition）を管理しており、すべて100GBを超える4つのメールボックスストア（650のメールボックスで構成）があり、メールボックスストアの保守プロセスを問題なく実行しています。
私が言いたいのは、メールボックスストアのメンテナンスとバックアップを異なる時間枠でスケジュールする必要があるということです。2つを同時に実行することはできないからです。マルボックスデータベースのメンテナンスプロセスは、バックアップの開始を検出すると停止します。 2つのタスクが競合する場合は、データベースの保守プロセスが完了しない可能性があります。次回中断したところから再開します。アプリケーションイベントログで、保存日を過ぎたアイテムのクリーンアップが完了したことを示すイベントID 1207、メンテナンスタスクが完了したことを示すイベントID 1209、およびオンラインデフラグが完了したことを示すイベントID1221を確認できます。
また、プロセスは最小15分、最大1時間実行されることに注意してください。メンテナンススケジュールで構成する時間は、実行できる時間であり、実行される時間ではありません。
プロセスの内容の概要は次のとおりです。
http://support.Microsoft.com/default.aspx?scid=kb;en-us;324358
純粋にデフラグについて尋ねると、答えは「状況によって異なります」になります。そもそもそれはどのくらい断片化されていますか？メールサーバーはどのくらい使用されていますか？かろうじて使用されているメールサーバーは、そもそもほとんど断片化されません。
仕事にかかる時間を見て、球場の見積もりを得ることができると思います。デフラグ用に許可したメンテナンスウィンドウにジョブが簡単に収まりますか？
実行するデフラグが割り当てられた時間に適合していて、実行間でパフォーマンスの問題が発生していない（またはエラーを要求していない）場合は、回避策のスケジューリングを使用してストアをデフラグするだけで十分です。
デフラグは、Exchangeストアの実行を維持することを目的としたものではありません。デフラグを行わない場合、Exchangeサーバーは停止しません。パフォーマンスは時間の経過とともに低下し、最終的にはクロールする可能性がありますが、デフラグされていないという理由だけでデータが失われたり破損したりすることはありません。