シナリオ:専用ボリューム(RAIDボリューム)を使用して、Exchange2007サーバーのすべてのデータを保存します。今日、好奇心から、このデータボリューム上のファイルがどのように断片化されているかを確認することにしました。驚いたことに、その答えは非常に重要です。したがって、3つの部分からなる質問:
何よりもまず、このボリュームをデフラグする必要があります(もちろん完全バックアップの後)?すべきでない理由、またはすべきである場合に絶対にすべき理由について具体的に説明してください。
次に、ギガバイトあたりのこのメンテナンス期間中にどのくらいの時間を許可する必要がありますか。ドライブはすべてハードウェアRAID5コントローラー(Perc 5i/6i、覚えていない)上の7200 RPM SATAドライブであり、ファイルは非常に断片化されています。 (ギガバイトあたり5000を超えるファイルフラグメント)。
第三に、ここに何か問題がありますか?ドライブはこれほど断片化されるべきではないように私には思えます。これを引き起こす可能性のある何かが正しく構成されていない可能性がありますか?
データベースファイルとトランザクションログを同じボリュームに保存していますか?
これがそのような断片化の原因になります(また、間違いなく推奨されません)。
トランザクションログはその場で作成される多くの小さなファイルですが、メインのデータベースファイルは継続的に増大します。これは、NTFSの大量の断片化に理想的なレシピです。
そのボリュームにはExchange database以外は何もないと思います...メールキューも断片化の大きな原因。
デフラグについて:回避できる場合は、実行しないでください。
外付けドライブでも空き容量はありますか? Exchangeサービスを停止し、すべてを別の場所にコピーし、ボリュームをフォーマットして、すべてを再度コピーするだけです。
または、適切なバックアップソフトウェアとデバイスがある場合は、バックアップ/復元を実行します。
インプレースディスクデフラグは、本番システムで実行できる最も遅くて危険な操作の1つです。そして、RAID 5(書き込みが非常に遅い)は、ここでは実際には役に立ちません。
0/3。そのボリュームにデータベースファイル(* .edbと* .stm)以外のものはありますか?どれだけ献身的であるかを尋ねていると言えるでしょう。シャドウコピーが交換ボリュームに保存されているために発生する深刻な断片化をかつて見ました。小規模なインストールでは、同じボリュームにインデックスファイル、ログファイル、SMTPキュー、MTAキューが表示されることは珍しくありません。これらのいずれかは、データベースファイルの断片化にもつながります。
OSのデフラグによって問題が発生することはありませんが、ドライブに大量の空き領域がない場合は、それほど多くのことを行うことは期待できません。インフォメーションストアサービスをやめたいと思います。交換のデフラグについて説明しているほとんどのドキュメントは、ファイルレベルの断片化ではなく、交換データベース内の空白の論理的な断片化に焦点を当てています。 http://msexchangeteam.com/archive/2004/10/25/247342.aspx これについて説明し、ファイルレベルのデフラグ中の書き込みの遅延についてログが混乱していることに言及しています。
速度/時間の計算についてはよくわかりません。私は少し忙しすぎて数学を試すことができません。