8のサイズを削減する最良の方法TB DB？
サイズが8 TB=のレガシーSQL Server 2005 DBがあります。このDBから5年より古いデータをパージします。パージプロセスが完了したら、 DBを縮小するか、DBのファイルサイズを小さくします。
縮小（DBCCの縮小）は適切なオプションではありません。したがって、すべてのスペースを再利用できるように、SSISパッケージを介してすべてのテーブル/オブジェクト/データを新しいDBにエクスポートすることを考えていました。 mdfおよびndfファイルのサイズを縮小する他の方法はありますか？
または、すべてのデータを新しいファイルグループにエクスポートして、元のファイルグループを削除することもできます。ただし、ほとんどのテーブルはヒープであり、クラスター化インデックスはありません。クラスタ化インデックスなしですべてのデータ/テーブルを別のファイルグループに移動することは可能ですか？また、すべてのデータを別のファイルグループに移動した場合、プライマリファイルグループを削除できますか？
別のオプションを使用してください。新しいファイルグループを作成し、そこにデータを移動してから、古いファイルグループを削除します。それはPaul Randall 's advice です：
では、doを実行する必要がある場合はどうでしょうか？たとえば、非常に大規模なデータベースの大部分を削除していて、データベースが大きくなる可能性が低い場合、または削除する前にファイルを空にする必要がある場合は、
私がお勧めしたい方法は次のとおりです：
新しいファイルグループを作成します。 CREATE INDEX…WITH（DROP_EXISTING = ON）ON構文を使用して、影響を受けるすべてのテーブルとインデックスを新しいファイルグループに移動し、テーブルを移動して同時にフラグメント化を削除します。とにかく縮小する古いファイルグループを削除します（または、プライマリファイルグループの場合は縮小します）。
基本的には、古いファイルを縮小する前に、もう少しスペースをプロビジョニングする必要がありますが、それははるかにクリーンなメカニズムです。
どうしても選択肢がなく、データファイルの縮小操作を実行する必要がある場合は、インデックスの断片化が発生することに注意してください。パフォーマンスの問題が発生する場合は、後でそれを削除する手順を実行する必要があります。データファイルの増加を引き起こさずにインデックスの断片化を削除する唯一の方法は、DBCC INDEXDEFRAGまたはALTER INDEX…REORGANIZEを使用することです。これらのコマンドは、インデックスの再構築操作の場合にまったく新しいインデックスを構築する必要がなく、1つの8KBページの追加スペースのみを必要とします。
結論–絶対にデータファイルの縮小を実行しないようにしてください。
ほとんどのテーブルがHEAPSの場合、縮小は実行可能なオプションのように聞こえます。 Shrinkの最大の問題は、インデックスに対する処理です。
縮小は一度に行う必要はなく、段階的に行う必要があるため、扱いやすいチャンクで削減できます。
データ型のレビューを実行します。移行中に列をBIGINTからINTに変更できる場合は、追加のスペースを節約できます。列のフットプリントを削減すると、インデックスの修復が煩雑になります。
Sys.dm_db_index_usage_statsを使用してインデックスの使用状況の監視を実行します。スキャン、シーク、またはルックアップのないインデックスは削除する必要があります（注：これらの数値は、サーバーの再起動時にリセットされます）。クラスター化インデックスのスキャンは、テーブルスキャンとまったく同じです。インデックスを削除することで、面倒な縮小が少なくなります。