多数の行を削除した後、SQL Serverデータベースのサイズが減少しませんでした。
私はSQLは得意ではありませんが、維持するデータベースがあります。
残りの場所がほとんどないため、たとえば2008年のデータをすべて削除することにしました。削除クエリ（約10 000 000行を削除）を実行し、トランザクションログを削除した後、アクションはデータベースのサイズに影響を与えませんでした。他に何かしなければならないことはありますか？
ここで言及されている理由により、縮小は確かに危険です。 Jimboの答えとJohnの答えの中間には幸福な媒体があります...データベースを縮小するかどうかは常に真剣に検討する必要があります。
理想的な世界では、成長するための十分な空き領域を持つDBを作成します。これを「適切なサイジング」と呼びます。この空き領域を確保し、それを返して、合計サイズを使用済みのサイズに維持しようとしないでください。なぜですか？あなたのデータベースは最終的には再び成長するからです。その後、再び縮小します。そして、あなたは、役に立たない縮小とそれに続く成長という恐ろしいパターンに行き詰まるでしょう。そして、いくつかの人が指摘しているように、ずっとインデックスの断片化を増やします。
私はこれについてブログを書いて、「 その縮小ボタンに触れないでください！ 」と忠告しましたが、時には...必要な場合もあります。大規模なデータベースがあり、かなりの領域を解放しただけで、データベースに戻ることを期待していない場合は、再構築によってインデックスの断片化に対処できる限り、縮小を1回の操作と見なしてもかまいません。それら。シュリンク操作は時間がかかる可能性があるため、シュリンクの実行にかかる価格を支払うことができる時間を計画する必要があります。空のDBを作成してそこにデータをコピーするアプローチは機能しますが、データベースが大きくなり、データが大量になると、それが非常に難しくなる可能性があります。
通常の使用法と将来の成長パターンによってそのスペースをDBに戻す予定がある場合は、スペースをそのままにしておくことをお勧めします。
またトランザクションログを「クリア」したとのことですが、どのようにこれを行ったのか知りたいのですが、私が共有した投稿やシリーズの他の投稿を読むと、トランザクションログ管理に関するいくつかのヒントが表示されます。ただし、簡単に言うと、完全復旧モードの場合は、ログを定期的にバックアップして、ログ自体を再利用する必要があります。それ以外の場合-フルモードでのログバックアップがない場合、ログファイルは次第に大きくなり、大きくなり続けます。クラッシュリカバリのためにそのログを維持するだけでなく、トランザクションを再生するための手動バックアップ/トランザクションを元に戻し、回復目的で特定の時点に回復する...単純で、ログが過度に大きくなっている場合、これは（通常）LOTを実行している兆候である可能性があります1つのトランザクションでの作業の数（あなたが言ったかどうかにかかわらずBEGIN TRAN ... do work.... COMMIT TRANまたは、1つの大きなDELETEステートメントを発行して、混乱したデータ全体を1つの暗黙的なトランザクションで削除したかどうか。）
また、ファイルシステムでこの空き領域を探していると想定しています。 SQL内とその大きなファイル内でそれを探している場合-オペレーションの直後を見ると、ゴーストクリーンアップが完了するのを待っている可能性があります。 ゴーストクリーンアップに関するポールランダルのブログ 。
データベースの行を削除しても、実際のデータベースファイルサイズは減少しません。
行を削除した後、データベースを圧縮する必要があります。
SQL Server 2005 DBCC SHRINKDATABASE（Transact-SQL）
これを実行した後、インデックスを再構築する必要があります。縮小すると、通常、インデックスの断片化が発生し、パフォーマンスが大幅に低下する可能性があります。
また、縮小した後、ファイルを再成長させて空き領域を確保することをお勧めします。そうすれば、新しい行が入ってきても、自動拡張はトリガーされません。自動拡張にはパフォーマンスコストがあり、可能な場合は常に（適切なデータベースのサイジングによって）回避したいものです。
データベースを縮小しないでください！
「なぜこれが発生するのですか？データファイルの縮小操作は一度に1つのファイルに対して機能し、GAMビットマップ（ストレージエンジンの内部：GAM、SGAM、PFSおよびその他の割り当てマップを参照）を使用して、次に、可能な限りファイルの前面に向かって移動します。上記の例では、完全に最適化された状態から完全に断片化された状態に、クラスター化インデックスの順序を完全に逆転させています。 」
http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx
「シュリンクデータベースの皮肉を見てください。1人の人がデータベースを縮小してスペースを確保し（パフォーマンスを向上させると考えています）、断片化が増加します（パフォーマンスが低下します）。断片化を減らすために、インデックスを再構築し、データベースは、元のデータベースのサイズよりもはるかに大きくなります（圧縮前）。
データを削除すると、SQL Serverは新しいデータを挿入するために後で使用するためにそのスペースを予約します。データベースを圧縮する必要があります。詳細は こちら をご覧ください。
データベースが「いっぱい」になったためにバックアップテーブルの束を削除しただけで、これが見つかりました。私は「サイズ」プロパティを見て考え続けましたなぜこれが小さくならないのですか？。これを読んだ後、いいえ、データベースを縮小したくありません。私がやりたいのは、削除したばかりのジャンクのスペースを「再利用」することです。私が見ている必要があるのは、「利用可能なスペース」でした。他の誰かもそれを見る必要があるのかもしれないと私は思っている。*
また、テーブルにインデックスがある場合、データの大きなスワスを削除した後に断片化が存在する可能性があることにも注意してください。今日、約7,000万レコードを含むテーブルがあり、約13GB必要でした。私はそれを1639レコードまでクリーンアップしました（残りは単一のバグによって生成されました）が、テーブルはまだ約4.5GBを占めていました。テーブルのすべてのインデックスを再構築した後、85ページ（680kb）しかかかりませんでした。その後、増分シュリンクファイルを使用してスペースを再利用しました（システムのバグを修正して繰り返しを防止しました）。