SQLデータベースの物理ファイルの断片化
DBAとして心配する必要がある断片化には、実際には3種類あることを知っています。 インデックスクラスタ化インデックス（テーブル）の断片化を含むSQLデータファイル、で断片化。DBCC SHOWCONTIG（SQL 2000）またはsys.dm_ db_ index_ physical_ stats（2005+）を使用してこれを識別します。 SQLログファイル内のVLFフラグメンテーション。DBCC LOGINFOを実行して、各SQLログファイルに含まれるVLFの数を確認します。 ハードドライブ上のデータベースファイルの物理ファイルの断片化。Windowsの「ディスクデフラグツール」ユーティリティを使用してこれを診断します。（この素晴らしいブログ投稿に触発されて） インデックスの断片化には多くの注意が払われています（Paul RandallによるこのServerfaultの優れた回答を参照）。それが私の質問の焦点ではありません。 合理的な予測データファイルとログサイズを計画することにより、データベースが最初に作成されたときに物理的な断片化（およびVLF断片化）を防ぐことができることを知っています。識別された物理的な断片化： まず第一に、物理的な断片化はエンタープライズSANでも関係がありますか？SANドライブでWindowsデフラグツールを使用できますか、またはSANチームが内部デフラグユーティリティを使用する必要がありますか？SAN ツールで実行した場合、Windowsツールから取得した断片化分析は正確ですか？ SQLパフォーマンスの物理的な断片化はどれほど大きな問題ですか？（前の質問の結果が出るまで、内部ドライブアレイを想定しましょう。）内部インデックスの断片化よりも大したことですか？または、それは本当に同じ種類の問題ですか（ドライブは順次読み取りの代わりにランダム読み取りを行う必要があります） ドライブが物理的に断片化されている場合、インデックスの最適化（または再構築）は時間の無駄ですか？もう一方に対処する前に、一方を修正する必要がありますか？ 運用SQLボックスで物理ファイルの断片化を修正する最良の方法は何ですか？SQLサービスをオフにしてWindows Defragを実行できることは知っていますが、完全バックアップを実行し、データベースを削除してから、バックアップから空のドライブに復元する手法についても聞きました。この後者の手法は推奨されますか？このようなバックアップから復元んまた、内部インデックスの断片化を解消する、ゼロからインデックスを構築しますか？または、バックアップが行われたときと同じページ順序を単に返すだけですか？（問題があれば、Quest Lightspeedの圧縮バックアップを使用しています。） 更新：これまでのところ、SANドライブを最適化するか（NO）、物理的に断片化されたドライブでインデックスの最適化を行う価値があるか（YES）については良い回答があります。 最適化を実際に行うための最良の方法を検討したい人はいますか？または、500GB程度の大きな断片化されたドライブを最適化するのにかかると予想される時間の長さの推定値は？明らかに、これは私のサーバーがダウンする時間だからです！ また、物理的な断片化を修正することでSQLパフォーマンスが向上したという逸話的な情報があれば、それも素晴らしいことです。Mikeのブログ投稿では、問題の発見について説明していますが、どのような改善が行われたかについては明確ではありません。