SQL ServerでDBが縮小することが多いため、心配する必要があります。SQL 2005のストレージエンジンの責任者であるPaul Randalは、ShrinkDBは非常に貧弱に書かれていると述べています。一番最後にデータを取り、それを一番最初に置いて空のスペースを見つけ、DBファイルの「終わり」に空きスペースができるまでこれを続けます。この時点で、SQL Serverからスペースを解放してOSに戻すことができます。データベースファイルを効果的に元に戻しているため、通常は大量の断片化が発生します。彼の見解については、このブログ投稿またはこのMCM内部ビデオで読むことができます。
すべての場合と同様に、実際にこれらを最初に環境でテストする必要があります。データを別のファイルグループに移動することをお勧めします。クラスタ化されたインデックスを使用してオンラインでインデックスを再構築し、新しいファイルグループでインデックスを再作成できます。その後、古いものをドロップしてスペースを解放すると、断片化はほとんどありません。これが機能している間、これは約120％余分なスペースを必要とすることに注意してください。これの問題は、あなたが持っていないように見える追加の空きスペースさえも必要とすることです。これはエンタープライズ機能です。
空き領域がそれほど多くない場合は、弾丸をかまして、DBを少しずつゆっくりと縮小して、長時間実行されるプロセスを回避する必要があります。データは大幅に断片化され、すべてのインデックスを再作成する必要があることに注意してください。すべてのインデックスを再作成した後、使用済みスペースを少し増やし、追加の空きスペースを確保することに注意してください。こちらからブレントのアドバイスをご覧ください。
どれだけの空き領域が適しているかというと、断片化とファイル拡張のアクティビティにどれだけ余裕があるかが問題になります。IFIが有効になっていると、ファイルの増加はほぼ瞬時ですが、それでも断片化が発生します。大体の目安として、必要だと思うだけのスペースを事前に割り当てるか、必要に応じて、成長を監視し、チャンク単位で定期的に調整します。これにより、物理的な断片化が抑えられます。
また、ログファイルの増加はより重要です。追加のログファイルにより、VLFフラグメンテーションが発生する場合があります。これにより、復元が大幅に遅くなり、チェックポイントや切り捨てに影響を与える可能性があります。 断片化したログを使用した場合のパフォーマンスリスクをいくつか示します。行いDBCC LOGINFO();、各データベースに。Kim Trippあたりの数を50程度に保つようにしてください。ただし、数百に達する場合は、断片化の問題があり、操作をサポートするためにログファイルを拡張する必要がありました。Paul Randalごとにログファイルがどうあるべきかを確認する良い方法は、ログファイルを1週間成長させてインデックスを再作成することです。これは良い点かもしれませんが、万が一に備えてもう少し空き領域を増やすことができます。ログがDBCC LOGINFO（）で断片化されていないことを確認してください。繰り返しますが、そうであれば、彼らは大きく成長しました。を使用してログファイルを縮小および再展開するこの方法。