多数の行を削除した後、SQL Serverデータベースのサイズは減少しませんでした。

私はSQLが得意ではありませんが、保守するデータベースがあります。

残っている場所がほとんどないので、たとえば2008年のすべてのデータを削除することにしました。削除クエリ（約100,000行が削除されました）を実行し、トランザクションログを削除した後、アクションはデータベースのサイズには影響しませんでした。他に何かしなければならないことはありますか？

収縮は、ここで述べた理由から確かに危険です。Jimboの答えとJohnの答えの間には幸せな媒体があります...データベースを縮小するかどうかを常に真剣に検討する必要があります。

理想的な世界では、成長するための十分な空き領域を持つDBを作成します。これをデータベースの「適切なサイジング」と呼びます。この空き領域をそこに残し、それを元に戻そうとしても、合計サイズを使用済みサイズのままにしようとはしません。データベースは最終的に再び成長するため..その後、再び縮小します..この無用な縮小のひどいパターンに固執し、その後に成長が続きます-そして、全体が、いくつかの指摘したように、インデックスの断片化を増やします。

私はこのことについてブログに書いたのですが、私は人々に「その縮小ボタンに触れないでください！」大規模なデータベースがあり、かなりのスペースを解放し、それまで再び成長することを期待しない場合-その後、再構築を通じてインデックスの断片化を処理できる限り、縮小を一度の操作として検討しても構いませんそれら。シュリンク操作には時間がかかる場合があるため、シュリンクランニングの代価を支払うことができる時間を計画したいでしょう。空のDBを作成してそこにデータをコピーするアプローチは機能しますが、大規模なデータベースと大量のデータを使用する場合は非常に困難になる可能性があります。

通常の使用状況と将来の成長パターンを介して、そのスペースをDBに追加し直す予定がある場合は、そこにスペースを残したいだけです。

また トランザクションログを「クリア」したと言いました。これをどのように行ったか知りたいのですが、私が共有した記事やシリーズの他の記事を読むと、トランザクションログ管理に関するヒントが表示されます。しかし、要するに-完全復旧モードの場合は、定期的なログバックアップを行って、ログ自体を再利用する必要があります。それ以外の場合-フルモードではログバックアップなし-ログファイルは成長し続け、成長し続け、クラッシュリカバリのためにそのログを維持したいだけでなく、手動でバックアップしてトランザクションを再生/トランザクションを元に戻し、回復のために特定の時点まで回復します...単純で、ログが過度に大きくなっている場合は、BEGIN TRAN ... do work.... COMMIT TRANまたはDELETE、1つの暗黙のトランザクションで1 つの大きなステートメントを発行し、大量のデータを削除したかどうか）

また、ファイルシステムでこの空き領域を探していると想定しています。SQLおよびその大きなファイル内でそれを探している場合-操作の直後に探している場合、ゴーストのクリーンアップが完了するのを待っている可能性があります。Paul RandalがGhost Cleanupについてのブログを書いています。

データベースの行を削除しても、実際のデータベースファイルのサイズは小さくなりません。

行を削除した後、データベースを圧縮する必要があります。

SQL Server 2005 DBCC SHRINKDATABASE（Transact-SQL）

これを実行した後、インデックスを再構築する必要があります。通常、縮小はインデックスの断片化を引き起こし、パフォーマンスの大幅な低下につながる可能性があります。

また、圧縮後にファイルを再成長させて、空き領域を確保することもお勧めします。そうすれば、新しい行が入っても、自動成長はトリガーされません。Autogrowthにはパフォーマンスコストがあり、可能な場合は（適切なデータベースサイズ設定を通じて）回避したいものです。

データベースを圧縮しないでください！

「これはなぜ起こるのですか？データファイルの縮小操作は一度に1つのファイルで機能し、GAMビットマップ（ストレージエンジン内部：GAM、SGAM、PFS、およびその他の割り当てマップを参照）を使用して、上記の場合、クラスター化インデックスの順序が完全に逆になり、完全に最適化された状態から完全に断片化された状態になります。 」

http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx

「シュリンクデータベースの皮肉を見てください。データベースを圧縮してスペースを確保すると（パフォーマンスが向上すると思います）、断片化の増加（パフォーマンスの低下）につながります。断片化を軽減するには、インデックスを再構築し、データベースを元のサイズよりも大幅に大きくする（縮小する前）。まあ、縮小することで、彼が通常探していたものを得ることができませんでした。」

http://blog.sqlauthority.com/2011/01/19/sql-server-shrinking-database-is-bad-increases-fragmentation-reduces-performance/

データを削除すると、SQL Serverは、新しいデータを挿入するために後で使用するためにその領域を確保します。データベースを縮小する必要があります。詳細はこちらをご覧ください。

これは、データベースが「使い果たされた」ために大量のバックアップテーブルを削除したためです。私は「サイズ」プロパティを見続け、なぜこれが小さくならないのかと考えました。。これを読んだ後、いや、データベースを縮小したくありません。私がしたいのは、削除したジャンクのスペースを「回収」することです。私が見る必要があったのは「利用可能なスペース」でした。多分それは他の誰かがそれを見る必要があるかもしれないと思っています。*

テーブルにインデックスがある場合、大量のデータを削除した後に断片化が発生する可能性があることにも注意してください。今日、テーブルに約7,000万件のレコードがあり、約13GBを使用していました。1639個のレコードに整理しました（残りは1つのバグによって生成されました）が、テーブルはまだ約4.5GBを占有しました。テーブルのすべてのインデックスを再構築した後、たった85ページ（680kb）しかかかりませんでした。その後、インクリメンタルシュリンクファイルを使用してスペースを再利用しました（繰り返しを防ぐためにシステムのバグを修正しました）。