データベースを縮小してもよいのはいつですか？
縮小は悪魔です。ページの順序が逆になり、皮膚がん、データの断片化、地球温暖化の原因になります。リストは続きます...つまり、100 GBのデータベースがあり、50 GBのデータを削除するとします-1つのテーブルではなく、データベース全体のレベルで古いデータの一般的な剪定を行い、テーブル-これはデータベースを縮小するための適切なユースケースを構成しますか？
そうでない場合、データベースからこのような高い割合のデータを削除した後、家をきれいにするために適切な手順は何ですか？インデックスの再構築と統計の更新の2つが考えられます。ほかに何か？
再編成して縮小することは決して推奨されません。
データベースがオフラインで提供しているアプリを使用できる場合は、縮小する前にすべてのインデックスとプライマリ/外部キー制約を削除することで、プロセスを高速化し、インデックスの断片化を減らすことができます（これにより、移動するデータが少なくなるため、データページは現在存在しないインデックスページではなくシャッフルされ、プロセスが高速化します）、すべてのインデックスとキーを再作成します。
縮小後にインデックスを再作成すると、大幅に断片化する必要がなくなります。縮小中にインデックスを削除しても、再構築しても、ファイルのページ割り当てに小さな「穴」が多く残らず、後で断片化が発生する可能性があります。
アプリケーションをオフラインにできる場合の別のオプションは、すべてのデータを同じ構造の新しいデータベースに移行することです。構築プロセスがしっかりしている場合は、空のDBをすばやく構築できます。現在のDBから作成しない場合は、すばやく作成できます（現在のDBのバックアップを復元し、テーブルのすべてのコンテンツを切り捨て/削除して、完全に圧縮します）。
インデックス化されたデータの多く（この場合は100％）を変更する場合、これははるかに効率的であるため、宛先のすべてのインデックスを削除して後で再作成することもできます。コピープロセスを高速化するには、異なる物理ドライブにある宛先データベースのデータファイルをソースに配置します（SSDを使用している場合を除き、ヘッドの動きを減らす必要がない場合）、それらを移動できます。完了したら、ソースの場所に移動します。
また、宛先を新規として作成する場合（ソースのコピーをブランクにするのではなく）、現在のすべてのデータと数か月分の成長を含む初期サイズで宛先を作成します。これにより、データコピーが再び少し速くなります。プロセス全体で新しいスペースが時々割り当てられるわけではありません。
データを新しいデータベースに移行すると、縮小操作の目的のアクションが複製されるため、縮小を使用するよりも優れている可能性がありますが、断片化がはるかに少ない可能性があります（再編成と縮小の意図しない結果です）。縮小は、単にファイルの終わり近くからブロックを取得し、それらを最初の近くの最初のスペースに配置して、関連するデータを一緒に保持する努力をしません。
後で部分的に使用されるページが少なくなる可能性が高いため、結果としてスペースの点でも効率が上がると思います。縮小は、部分的に使用されているページを移動するだけです。データを移動すると、特にテーブルのクラスター化されたキー/インデックス（テーブルに1つある）の順序で宛先に挿入し、他のインデックスを作成する場合、ページ全体が表示される可能性が高くなります。データがすべて移行された後。
もちろん、アプリをまったくオフラインにできない場合は、縮小を実行することが唯一の選択肢です。そのため、reallyスペースを再利用する必要がある場合は、それに合わせてください。データ、アクセスパターン、一般的なワーキングセットのサイズ、RAMサーバーの容量など）に応じて、余分な内部断片化は、結局それほど重要ではない場合があります。
コピー操作の場合、SSISまたはベースT-SQLのいずれかも同様に機能します（SSISオプションは効率が低下する可能性がありますが、後で維持するのが容易になる可能性があります）。インデックスと共に最後にFK関係を作成すると、どちらの場合も「テーブルごとにコピーする」という簡単な操作を実行できます。もちろん、1回限りの場合、おそらく縮小+再編成も問題ありませんが、通常の縮小を決して考慮しないように人々を怖がらせたいのです！ （私は人々が毎日それらをスケジュールすることを知っています）。
データベースは再び大きくなるのでしょうか？その場合、縮小操作に費やす努力は無駄になります。ファイルサイズを小さくしてからデータを追加すると、ファイルが再び大きくなるため、トランザクションはその成長が起こるのを待たなければなりません。次善の自動拡張設定や遅いドライブがある場合、この拡張アクティビティは非常に苦痛になるでしょう。
データベースを縮小する場合、解放されたディスク領域を何に使用しますか？繰り返しますが、このデータベースが再び大きくなった場合に備えて、そのスペースを空けておくつもりであれば、ホイールを回転させるだけです。
ファイルにこのすべての空き領域が確保されたので、実行することを検討するかもしれませんが、インデックスを再構築して、より適切に最適化します（そして、空き領域がある場合、これを行うのはそれほど簡単です-小さなクローゼットと大きな寝室のセーターを交換することを検討してください）。
したがって、これが主要なクリーンアップ操作であり、本当に同じレベルのデータに再び上昇しないのでない限り、そのままにして、他の最適化領域に焦点を当てます。
スペースが不足し、データがそれほど大きくなるはずがない場合は、縮小しますが、通常の成長を可能にする適切なFILL FACTORを使用してインデックスを再構築します。
最終的な目標が実際にバックアップサイズを縮小することである場合は、トランザクションログを消去する包括的なバックアップ戦略を実装し、dbをバックアップするときに圧縮オプションを使用してください。
通常5 GBが頻繁に増加することが予想される場合を除き、5 GBの自動拡張はお勧めしません。そうしないと、断続的なパフォーマンスの問題が発生する可能性があります。最初に、データサイズを、たとえば1年間に必要と思われるサイズに設定し、自動拡張を、テストしたサイズが運用パフォーマンスに影響を与えないように設定する必要があります。 Mike Walshによる SQL Serverのデータベース縮小ボタンに触れないでください！ を参照してください。
縮小する前にインデックスを再構築すると、インデックスのレイアウトが不適切になります。再構築して縮小するのは良くありません。縮小すると、インデックスが破損して領域が回復します。事前に再構築してから縮小しても意味がありません。 Thomas LaRockによる 自動縮小を使用する場合 を参照してください。
遅くこの方法に戻ってきます。それでも、テスト環境での縮小の使用について長い間検討し、テストしてきました。トピックごとに、縮小が実行可能なオプションであるare回があります。しかし、それをいつどのように適用するかを知ることは、長期的にも短期的にも適切に実行するために不可欠です。
私たちのシナリオでは、最近、圧縮、パーティション化、アーカイブ、冗長データの単純な古い削除など、多数の変更を大規模DBに追加しました。その結果、プライマリデータファイルの使用済み部分は、以前の半分以下になりました。しかし、そのすべての荷物を持ち歩くことの意味は何ですか？特に、ウェブ上のいくつかの記事とは逆に、データファイルのサイズはバックアップ/復元期間と直接相関します。これは、多くの記事が想定しているのとは異なり、実際のシナリオでは、削除したものよりも多くのデータが特定のページに読み込まれるためです。
さらに言えば、これは縮小のための素晴らしいシナリオを開きます：
- データベース内のすべてのオブジェクトとそのファイルグループを見つけるスクリプトを作成し（多くの例はオンラインです）、これを使用してドロップ句を作成し、すべてのインデックスと制約の定義を作成します。
- 新しいファイルとファイルグループを作成し、それをデフォルトにします。
- すべての非クラスター化インデックスを削除します（一部のインデックスは制約になる場合があります）。
- DROP_EXISTING = ONを使用して、新しいファイルグループにクラスター化インデックスを作成します（これは、多くの代替手段と比較して、最初に非常に高速で最小限のログが記録される操作です）。
- 非クラスター化インデックスを再作成します。
- 最後に、古いデータファイル（通常はPRIMARY）を縮小します。
この方法で残される唯一のデータは、DBのシステムオブジェクト、統計、手順などです。縮小ははるかに速く、かなり高速である必要があり、メインデータオブジェクトのインデックスをさらにメンテナンスする必要はありません。メインデータオブジェクトは、適切に作成され、将来の断片化のリスクが最小限に抑えられます。
これが縮小後の再インデックスよりもうまく機能するかどうかはわかりませんが、別のオプションは、適切なサイズの新しいデータファイルを作成し、すべてのデータをそれに移動することです。その場合は、最初にインデックスを再作成して、実際のデータサイズがわかるようにします。 1つの問題は、これがプライマリデータファイルの最初のファイルである場合、空にできないと思います。それを縮小して、後でデータを戻すことができれば、ページの反転が回避されます。ただし、ソリッドステートへの移行を検討している場合は、とにかく大きな違いはありません。