web-dev-qa-db-ja.com

インデックスの再構築、DBのサイズが10倍に

SQL Serverデータベース（2008 R2 SP1）があり、約15ギガバイトでした。メンテナンスがしばらくの間実行されていなかったことが判明したため、すべてのインデックスを再構築するためのメンテナンスプランを作成しましたが、それらは非常に断片化されていました。

ジョブは終了し、断片化はなくなりましたが、データベースは120ギガを超えています。すべての再構築を行うために余分なスペースを使用することはわかっていましたが、ジョブが完了すると、そのスペースはすべてフリースペースになると思いますが、フリースペースは3ギグしか表示されないため、117ギグが使用されています。インデックスの再構築ジョブが終了した場合でも。

私は非常に混乱しており、いくつかのガイダンスを使用できます。データベースを適切なサイズに戻します。これを行うためのディスク領域がありません。

前もって感謝します！

投稿された両方のクエリの結果は次のとおりです。

log_reuse_wait_desc NOTHING

name    TotalSpaceInMB  UsedSpaceInMB   FreeSpaceInMB
LIVE_Data   152             123             28
LIVE_Log    18939           89              18849
LIVE_1_Data 114977          111289          3688

3番目のファイルは.ndfファイルです。これは、未使用のスペースに3688のみを示すファイルですが、111289は約15ギガのデータに使用されます。

sql-serversql-server-2008sql-server-2008-r2
13
AS2012

その間、私はこれを見つけました、完全な脳のげっぷ。再構築ジョブで90のフィルファクターと考えていたものを示しましたが、これは「空き領域の割合を変更する」と表現されているため、そこで90の値を使用して、実際にはフィルファクター10を使用していました。 DOH。 10倍に成長したのも当然です。正しいFILL FACTORで再構築してから縮小します。しかし、入力してくれたみんなに感謝します。

15
AS2012

インデックスを再構築すると、DBに余分なスラックスペースが生じます。これは、インデックスの再作成プロセスの自然な副産物です。サーバーは、現在のバージョンと並んで新しい、できれば連続したバージョンのインデックスを構築し、完了時に現在のバージョンを削除します。

再インデックス後の縮小は無意味です！

インデックスを再断片化するだけです！縮小は、DB内のデータを再割り当てすることにより、スラックスペースを削除します。

Microsoftで働いていたときに縮小を含むDBCCコードを担当したPaul Randalからの素晴らしい記事です。なぜ縮小すべきでないかについてです。

2
JNK

再構築オプション SORT_IN_TEMPDB=ON 。

あなたのケースでは、問題のテーブルが配置されている実際のデータファイルがインデックスのソートに使用されています。その120GBのスペースの多くはまだ使用されておらず、必要に応じてページデータで埋められます。

このクエリを使用すると、使用済み/空き領域の状態を確認できます（ here から取得）：

use [YourDatabaseNameHere]
go

select
    name,
    cast((size/128.0) as int) as TotalSpaceInMB,
    cast((cast(fileproperty(name, 'SpaceUsed') as int)/128.0) as int) as UsedSpaceInMB,
    cast((size/128.0 - cast(fileproperty(name, 'SpaceUsed') AS int)/128.0) as int) as FreeSpaceInMB
from
    sys.database_files

特定のデータベースファイル（データまたはログ）を圧縮する場合は、いくつかの情報 ここ を確認できます。その前の警告である100 GB以上のデータベース（ストレージの速度にも依存します）の場合、未使用領域の解放にはかなりの時間がかかるため、そのまま実行します。

0
Marcel N.