2009-06-05 19 views
3

SQL Server 2005には、(sp_spaceusedに従って)約3.5 GBの大きな表があります。それは1000万レコードといくつかのインデックスを持っています。SQL Server 2005:削除された列のディスク容量

私は、レコードの長さが半分になるように、たくさんの列を落としました。私の驚いたことに、これを行うには時間がかかりました。明らかに、sp_spaceusedは同じ撮影空間を報告していましたが、SQLサーバーは列を削除するときに実際に何もしていませんでした。

このテーブルのすべてのデータを別の新しいテーブルに移動し、切り捨て、すべてのデータを元に戻して再構築しました。

これ以降、データは2.8 GBとなっていますが、これは以前より少なくなりましたが、私はより大きな低下を予想しました。

このテーブルがもともとこれらのカラムを持っていたという事実はまだそこに残っている可能性はありますか?

十分に切り捨てましたか?私はそれをドロップし、小さな列のセットを使用して再度作成する必要がありますか?

また、実際に2.8 GBのデータがありますか?

ありがとうございます!

答えて

2

「もっと大きなドロップを期待していた」とはどのように計算しましたか?データは8Kページで提供されることに注意してください。つまり、個々の行が小さい場合であっても、必ずしもページを格納するために必要なページが少なくて済むわけではありません。 たとえば(極端な例)、行がそれぞれ7.5Kだった場合、1ページあたり1行しか収まらない。あなたはいくつかの列をドロップします。あなたの行は5Kですが、それでも1ページあたり1行です。

4

クラスタ化インデックスを再構築する必要があります(デフォルトでは、プライマリキーはクラスタ化キーです)。

ALTER INDEX (your clustered index) ON TABLE (your table) REBUILD 

データが本当にあなたのクラスタ化インデックスのリーフレベルである - あなたはそれを再構築したら、それは「コンパクト化」になり、行はあまりにも、あなたのデータベースのサイズを小さく、非常に少数のデータページに格納する必要があります。

それでも問題が解決しない場合は、データベース上でDBCC SHRINKDATABASEを実行して、実際に領域を再利用する必要があります。これらの2つのステップは、実際には、より小さなデータベースファイルを実際に取得する必要があります!

Marc

+0

3.5GBのテーブルであると仮定すると、システムの稼働中は正常に動作しますか? – marquito

+1

@marquito:この操作を完了するためにダウンタイムが必要です。ありがとう、@ marc_s。 –

+0

私も同じ状況に直面しているので、手順を実行したり、その結果に直面するのを待たなければならないことを知っておくとよいでしょう。 :) – marquito

関連する問題