スペースを解放しないインデックスの再構築
昨日、インデックスが再構築され、データベースサイズが2倍になった（新しいサイズの50％が使用されなかった）状況がありました。 Sort in tempdbはoffに設定されており、この再構築が原因であるように感じます（tempdbではなくインデックスの再構築）。
再構築手順が完了/潜在的な障害の後にディスク領域を保持する理由はありますか？
再構築によってファイルシステムのデータファイルが小さくなることを期待している場合、これは機能しません。
実際、データのコピーを保持するために新しいページとエクステントが割り当てられるため、再構築によってディスク上に大きいデータファイルが生成されることもあります。古いページがインデックスから削除されると、実際には何も削除されず、割り当てが解除されるだけです。
インデックスを再構築し、スペースを節約しましたinsideデータファイル。つまり、（このテーブルや他のテーブルに）データを追加しても、新しいデータ用のスペースを確保するためにデータファイルをすぐに拡張する必要はありません。
これは良いことです。ファイルの拡張はコストのかかるブロック操作であり、これを最小限に抑える必要があります。ファイルを縮小して戻すsomeディスク容量一時的失われた原因のようです。データファイルは後で再び大きくなるだけです。その場合、しばらくの間戻ってきたディスクスペースをどのように処理しますか？それを誰かに貸し出し、データベースが再び成長する必要があるときにそれらを立ち退かせますか？読み取り専用としてマークしない限り、再びそのサイズに成長する可能性が高いため、現在のサイズまでそのままにしておきます。
データファイルは単なるコンテナーです。そのままにしておくと、のみが大きくなります。一部の行を削除したり、一部のインデックスを再構築したり、テーブルを削除しただけでは縮小しません。 SQL Serverはそのディスク領域を解放せず、同時にファイルを圧縮しません。たまたま、バッファプールにロードされたインデックスを削除したからといって、メモリをオペレーティングシステムに解放しません。あなたは再びそのスペース/メモリを使用するつもりであり、それを解放し、それを再利用し続けることは高価であることを知っています。だからそれはそれを保持します。
そして、ほとんどすべての場合、あなたはそれをそのようにしたくなるでしょう。 know二度と使用しないスペースを再利用する必要がある場合は、 この投稿 を参照してください。
オフラインで再構築する余裕がある場合は、それほど多くの領域を占有しません。 sort_in_tempdbがオンの場合でも、結果として少なくとも2倍のスペースが必要になります。オンライン再構築では、新しいコピーを再構築するときに元のインデックスを維持し、最後に短いラッチを使用してそれをスワップアウトして暫定的な変更を適用する必要があります。オフラインでの再構築では、インデックスが削除されて再作成されますが、その間、テーブルがブロックされます。