SQL Serverデータファイルを縮小しますが、一度にすべてではありませんか？

Question

現在150GBのデータベースファイルがありますが、75GBしか使用されていません。これは、すべてのインデックス（他の75GB）を新しいデータファイルに移動したためです。このデータファイルからスペースの少なくとも一部を再利用したいのですが、ファイルを縮小しようとすると、ファイルは無期限に「実行」され、ネットワークの中断またはその他の制御不能な理由で最終的にキャンセルされます（ランニングの日）。「特定のサイズに縮小」機能を使用して、10MBをトリミングするように指定しても、戻らないようです。プロセスが中断されるまでそのままです。

このスペースを少しでも取り戻すことができる別の方法はありますか？

編集：誰かが私のデータベースを縮小すべきではない理由を説明するリンクを投稿しました。わかりました。とにかく縮小したいと思います。このサーバーのディスク容量は貴重であり、データベースはこの未使用の領域に非常に長い間再び拡張されません-前に述べたように、この領域を解放するためにデータファイルからインデックスを移行したので、今では無駄になっています。

BradC · Accepted Answer

いいえ、DBCC SHRINKFILE ('filename', target_size)を使用するのが正しい方法です。

「チャンク」で実行する場合は、ターゲットサイズを徐々に小さく設定するか、キャンセルされる前にできるだけ長く実行することができます。

いくつかのコメント：

許容される空き領域にある程度の余裕を持たせて、適切なターゲットサイズを設定します。たぶん75GBのデータで合計90GB？
シュリンクの実行中に、アクティビティモニターをチェックして、SPIDがブロックされているかどうかを確認します。ファイルの最後のページに開いているトランザクションがある場合、そのトランザクションがコミットされるかロールバックされるまで、shrinkはそのトランザクションを移動できません。
スパイは実際に進歩していますか？（CPUとIO数値が変化しています）
縮小には非常に長い時間がかかる場合がありますが、進行状況を保存する必要があります（つまり、一度に1ページ移動し、キャンセルされると、完了したすべてのページ移動はすでに完了しています）
縮小をキャンセルした後、DBCC SHRINKFILE ('filename', TRUNCATEONLY)を実行してみてください。ファイルの最後ですでに解放されているすべてのスペースを回復する必要があります（私の前のポイントを参照）
必死になったら、シングルユーザーモードでSQLを再起動してみてください。そうすれば、その時点でデータベースに対して他に何も機能していないことがわかります（明らかに、これは本番サーバーでは不可能な場合があります）。
縮小を完了できるようになったら、データベースで完全なインデックスの再作成を行って、縮小によって生じる断片化を排除してください。これにより、解放したばかりのスペースの一部が再利用される場合があります。
それでも縮小を機能させることができない場合は、 this SO question 。縮小が進行しない可能性がある状況がいくつかあるようです。

ozamora · Answer

私たちの環境では、いくつかのオプションに取り組んできました。

古いテーブルを表向きにすることができる場合は、新しいファイルグループに新しいテーブルを作成し、データベースをデフォルトで設定します。時間の経過とともに、前のファイルグループが空になるまで古いテーブルを削除します。次にそれをドロップします。
古いテーブルを表向きにすることはできないが、数時間オフラインにできる履歴データが含まれている場合は、新しいファイルグループを指す新しい空のテーブルを作成します。テーブルを交換し、古いテーブルから新しいテーブルへの行のコピーをバッチで開始します。ただし、これにより断片化が発生する可能性があります。
EMTPYFILEオプションを指定してDBCCSHRINKFILEを発行すると、DBはすべてのオブジェクトを新しいファイルに移動します。次に、古いファイルを削除できます。ただし、これには長い時間がかかる場合があります。
すべてのテーブルのクラスター化インデックス（DROP_EXISTINGの主キー）を新しいファイルグループに再作成します。ただし、これによりテーブルがロックされます。

幸運を

Jim B · Answer

単にスペースを再利用したくないが（特にやりたくない）、データベースの縮小を試みることを主張する場合は、これには非常に長い時間がかかり、トランザクションログの拡張はほぼすべてのスペースをカバーするはずです。データベースから回収しました。ボーナスとして、DBのパフォーマンスが後でフロアを通過するのを見てください。 Paul Randalがあなたを納得させることができない場合（JLがコメントしたが、ここに再投稿します：データファイルを縮小しない理由縮小はひどい考えです、誰もができるかどうかはわかりません。運の縮小は、次のリビジョンでSQLサーバーから削除されます（または、少なくともPaulが推奨するように機能するように変更されます）。