テーブルを切り詰めた後（圧縮以外）、大規模なデータベースのプライマリファイルグループからディスク領域を再利用します。
8 TB SQL Server 2014 SP1データベース、1つのプライマリファイルグループ、異なるドライブ上の複数のファイルに分散しています。これは、複数のセカンダリ（一部は非同期）を持つAlwaysOn AGの一部です。
このデータベースの1つの古いテーブルは6TBであり、切り捨てました。このディスク領域を再利用するために、次のいずれかを行うことができますDBCC ShrinkDatabaseまたはShrinkFile。
現在はディスク領域の回復にのみ焦点を当てているため、断片化のような縮小や、データベースの再成長などの通常の問題は気にしません。
しかし、これらの縮小操作は非常に遅く、これを行うためのより高速な方法を探しています。
まず、変更は同期されたセカンダリに同期する必要があるため、これらは遅いですか？
第二に、収縮をより速くする方法はありますか？
他のいくつかのオプションを考えました：
別のデータベースを作成し、すべての（古いものを除く）テーブルをそこに移動します...ただし、AGをすべてセットアップする必要がある場合があります。
別のファイルグループを作成し、すべての（古いものを除く）テーブルをそこに移動しています...しかし、古いテーブルはプライマリファイルグループにあり、削除できませんよね？
大きなテーブルを削除またはトランケートした後にデータベースを「縮小」するために業界で使用した方法はどれですか。
私は読んだ 必要に応じてどのように縮小する*正しい*？ だが、答えが私の質問を満たさない..縮小以外のオプションはありますか？テーブルをプライマリファイルグループから移動して削除できますか？
このような大きなデータベースファイルの圧縮操作を実行するには、しばらく時間がかかります。正直なところ、DBCCコマンドを実行して、できるだけ長く実行できるようにすることを検討する必要があります。それをやらせてください。
縮小操作が完了する前に停止した場合、変更はロールバックされないため、ある日2時間、別の日4時間など、週末または終日実行できるようになるまで続きます。素早く完了するまで。
スクリプトを実行して、各実行の前後にもDBの空き容量を確認します。
この方法では、新しいDB構造などにエクスポートせず、独自の処理を実行できます。もう少し調査を行いますが、同じように聞こえるケースで、私は過去に関与しました（データローダーがすべて間違ったことをした巨大なデータウェアハウス-tempdbではなくtempテーブルに実際のDBを使用しました）、それは起こりましただった。問題を追跡し、データローダーを再トレーニングしてから、クリーンアップを行いました。その後、パフォーマンスよりもスペースを優先する断片化などの処理に取り組みました。
言及された問題のため、私たちは常にファイルを小さなチャンクに縮小しています。私の経験では、SQL Serverは縮小する前にファイルの最後からページを移動する必要があるため、縮小は最初は耐え難いほど遅いと思います。しかし、あなたが進むにつれて、それはますます速くなります。
データベースファイルを圧縮する必要がある場合は、通常、新しいファイルをファイルグループに追加し（初期サイズ=残りのデータのサイズ）、DBCC SHRINKFILE (N'<old_file>' , EMPTYFILE)を使用して残りのデータを新しいファイルに移動し、古いファイルをドロップします終わった時に。
PRIMARYファイルグループの場合、移動できないsysテーブルがあるため、少し複雑ですが、DBCCがこれに関するエラーを表示した場合、通常、他のすべてのものを新しいファイルに移動したため、次のことができます。元のプライマリファイルをたとえば20 MBで自動拡張を無効にします。
AGについては使用していませんので、パフォーマンスについては何も言えません。
可能であれば、SHINKFILEを実行する前に復旧モデルをSIMPLEに設定できます（後でそれをFULL/BULKに設定してから、新しい完全バックアップを作成します）。