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


13

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

ジョブは終了し、断片化はなくなりましたが、データベースは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だけを表示しますが、約15ギガのデータに111289を使用しています。

回答:


15

それまでの間、私はこれを考え出しただけで、脳全体のげっぷ。再構築ジョブで90のフィルファクターだと思っていたものを示しましたが、「空き領域のパーセンテージを変更する」と表現されているので、90の値を使用することで、実際に10のフィルファクターを使用していました!! DOH。10倍に成長したのも不思議ではありません。正しいフィルファクタで再構築してから縮小します。しかし、入力してくれたみんなに感謝します。


1
このウィザードはひどいです。
usr

私は、FILL_FACTORを指定するコマンドラインに慣れており、空き%ではなく、一貫性があればいいのにと思っています。

インデックスを再作成してから縮小しないでください。時間の無駄です。詳細については私の答えをご覧ください。
JNK

1
JNK再構築後にすべてが断片化するため、再構築後に縮小しないでください。しかし、ジェフが偶然すべてのページに90%の空きスペースを追加したこの特定のシナリオでは、スペースを再利用する他の方法はありません:fillfactor 90で再構築し、ファイルを縮小しますが、別の再構築を行う必要がありますfillfactor 90%で再び。または、スペースを取り戻す別の方法がありますか。(多分新しいファイルグループを作成し、新しいファイルグループにドロップして再構築しますが、それはすべての人に
有効

2

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

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

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

Paul Randalからの素晴らしい記事は次のとおりです。PaulRandalは、Microsoftで働いているときに、DBCC縮小を含むコードを担当し、なぜ縮小すべきではないかについて説明しました。


0

再構築オプションを使用する必要がありますSORT_IN_TEMPDB=ON

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

このクエリで使用/空き領域のステータスを確認できます(ここから取得)。

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を超えるデータベースではかなり時間がかかります(ストレージの速度にも依存します)。


ええ、フォーマットしません。ちょっと質問に追加します。

@JeffBane:この情報を質問に引用で追加できますか?そこに何があるのか​​わかりません。
マルセルN.

1
インデックスを再構築する場合、ソートのためにインデックスの2倍のスペース+ 20%が必要になります。したがって、一般に、データベース内のすべてのインデックスを再構築するには、DB内の最大インデックスの120%しか必要ありません。SORT_IN_TEMPDBを使用すると、20%しか勝ちませんが、データファイルにはさらに100%が必要です。さらに、tempdbでsortを使用すると、データファイルに1回インデックスを書き込む代わりに、tempdbに1回書き込み、データファイルに書き込むため、IO負荷が大幅に増加します。そのため、常に理想的とは限りません。
エドワード・ドートランド

-1

他の詳細がなければ、スペースを取り戻す前にトランザクションログのバックアップを行う必要があると思います。

何がselect name, log_reuse_wait_desc from sys.databasesわかるか見てください。log_reuse_wait_descカラムに示されている場合、LOG_BACKUPtranログのバックアップが完了するまでスペースを再利用できません。


トランザクションログのバックアップを行う必要があったとしても、ページが解放されることはありません。
-mrdenny
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.