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ギガのデータに使用されます。
その間、私はこれを見つけました、完全な脳のげっぷ。再構築ジョブで90のフィルファクターと考えていたものを示しましたが、これは「空き領域の割合を変更する」と表現されているため、そこで90の値を使用して、実際にはフィルファクター10を使用していました。 DOH。 10倍に成長したのも当然です。正しいFILL FACTORで再構築してから縮小します。しかし、入力してくれたみんなに感謝します。
インデックスを再構築すると、DBに余分なスラックスペースが生じます。これは、インデックスの再作成プロセスの自然な副産物です。サーバーは、現在のバージョンと並んで新しい、できれば連続したバージョンのインデックスを構築し、完了時に現在のバージョンを削除します。
再インデックス後の縮小は無意味です!
インデックスを再断片化するだけです!縮小は、DB内のデータを再割り当てすることにより、スラックスペースを削除します。
Microsoftで働いていたときに縮小を含むDBCC
コードを担当したPaul Randalからの素晴らしい記事です。なぜ縮小すべきでないかについてです。
再構築オプション 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以上のデータベース(ストレージの速度にも依存します)の場合、未使用領域の解放にはかなりの時間がかかるため、そのまま実行します。