Dizinleri Yeniden Oluşturma, DB şimdi 10 kat daha büyük

Yaklaşık 15 konser bir SQL Server veritabanı (2008 R2 SP1) var. Bakımın bir süredir çalışmadığı ortaya çıktı, bu yüzden tüm dizinleri yeniden oluşturmak için bir bakım planı oluşturdum, çok parçalanmışlardı.

İş bitti ve parçalanma gitti, ama şimdi veritabanı 120 konserin üzerinde! Tüm yeniden yapılanmaları yapmak için ekstra alan kullanacağını anlıyorum, ancak şimdi iş bittiğinde, tüm bu alanın boş alan olacağını düşünürdüm, ancak boş alan sadece 3 konser olarak gösterilir, bu yüzden 117 konser kullanılıyor dizin yeniden oluşturma işi bitmiş olsa bile.

Ben çok karışık ve bazı rehberlik kullanabilirsiniz, makul bir boyuta geri db olsun, bunun için disk alanımız yok.

Şimdiden teşekkürler!

Her iki sorgunun sonuçları da şöyledir:

log_reuse_wait_desc HİÇBİR ŞEY

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

3. dosya bir .ndf dosyasıdır, kullanılmayan alanda sadece 3688'i gösteren dosyadır, ancak yaklaşık 15 gig veri için 111289 kullanılır.

Bu arada bunu tam olarak anladım, toplam beyin geğirmek. Yeniden oluşturma işinde 90 doldurma faktörü olduğunu düşündüğümü belirtmiştim, ancak "boş alan yüzdesini değiştir" olarak ifade edildi, bu yüzden orada 90 değerini kullanarak, aslında 10 doldurma faktörü kullanıyordum! DOH. 10 kat büyüdüğüne şaşmamalı. Doğru dolgu faktörü ile yeniden inşa edeceğim, sonra küçüleceğim. Yine de giriş için herkese teşekkürler.

Dizinlerin yeniden oluşturulması DB'de fazla boş alan oluşmasına neden olur. Bu, yeniden dizin oluşturma işleminin doğal bir yan ürünüdür - sunucu, geçerli sürümün yanında dizinin yeni, umarım bitişik bir sürümünü oluşturuyor, ardından tamamlandığında geçerli sürümü bırakıyor.

Yeniden endekslemeden sonra küçülmek anlamsızdır!

Sadece dizini yeniden parçalayacaksınız! Küçülme, DB içindeki verileri yeniden tahsis ederek boş alanı kaldırır.

İşte Microsoft'ta çalışırken, DBCCdaralmalar da dahil olmak üzere koddan sorumlu olan Paul Randal'dan neden küçülmemeniz gerektiğine dair güzel bir makale .

Yeniden oluşturma seçeneğini kullanmış olmalısınız SORT_IN_TEMPDB=ON.

Sizin durumunuzda, söz konusu tabloların bulunduğu gerçek veri dosyaları dizinleri sıralamak için kullanılmıştır. Bu 120GB alanın çoğu hala kullanılmıyor ve gerektiğinde sayfa verileriyle doldurulacak.

Bu sorgu ile kullanılan / boş alan durumunu görebilirsiniz ( buradan alınır ):

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

Belirli bir veritabanı dosyasını (veri veya günlük) küçültmek için, burada bazı bilgileri görebilirsiniz . Bundan önce bir uyarı, kullanılmayan alanı bırakmak 100+ Gb veritabanları için (depolama hızına da bağlıdır) oldukça uzun sürüyor, bu yüzden çalışmasına izin verin.

Başka bir ayrıntı olmadan, alanını geri kazanmadan önce bir işlem günlüğü yedeklemesi yapmanız gerektiğinden şüpheleniyorum.

Bak ne diyeceđim select name, log_reuse_wait_desc from sys.databases. Log_reuse_wait_desc sütunu diyorsa LOG_BACKUP, tran günlüğünün yedeğini alana kadar alan geri kazanamaz.