Verilerin% 95'inin arşivlendiği ve silindiği bir veritabanına karşı 1GB'lik yığınlarda bir dbcc shrinkfile çalıştırmaya çalışıyorum. 9GB'ın veri / dizinler olduğu 235 GB'lık bir dosya ile sızdırıyorum. Bunu 50 GB'a düşürmek istiyorum. Veritabanı dosyaları daralma kötü olduğunu biliyorum, parçalanma vb neden olur. Veri temizleme / shrink bir parçası olarak biz de yeniden idnex komut dosyası var.
Dbcc shrinkfile betiğimi kendi iş istasyonumda (dört çekirdekli, 12GB RAM, 2 x SATA sürücüler) veritabanına çalıştırdığımda, büzülme 8-10 dakika sürer.
Veri toplama sonrası temizleme işleminin aynı kopyasına karşı aynı kodu çalıştırırken, test ortamımızda (80+ çekirdek, 128GB RAM, SSD SAN) 70 dakika sürer. Not etmek gerekirse, shrink dosyası çalışırken bu sunucuda çok az etkinlik vardır. Aynı sonuçlar ile 4 kez çalıştırıldı.
Daha sonra, kalan 9GB'yi farklı bir dosya grubuna ve fiziksel dosyaya taşıma konusunda farklı bir yaklaşım izledim. Kendi iş istasyonumda 50GB'a kadar küçültmek için boş 230GB dosya üzerinde dbcc shrinkfile çalıştırmak, <1 dakika sürüyor.
Aynı yaklaşımla, test ortamında tekrar 70+ dakika sürer.
Test ortamına 70 dakikalık bir çalışma sırasında Brent Ozar'ın senaryosuna göre önce ve sonra waitstats'ın bir anlık görüntüsünü aldım ve waittypes, endişelenecek bir şey göstermedi. Aşağıdaki en iyi 3 satır:
İkinci Numune Süresi Saniyedeki Örnek Süre wait_type Bekleme Süresi (Saniye) Bekleme Sayısı Bekleme Başına Ort. Ms Bekleme Başına 2013-05-28 11: 24: 22.893 3600 WRITELOG 160.8 143066 1.1 2013-05-28 11: 24: 22.893 3600 CXPACKET 20.9 13915 1.5 2013-05-28 11: 24: 22.893 3600 PAGELATCH_EX 11.1 443038 0,0
Windows olay günlüğü olağandışı bir şey göstermiyor. Bu noktada, bağımsız iş istasyonuma kıyasla ninja donanımının neden bu kadar uzun sürdüğünü çiziyorum.
sys.dm_os_latch_stats
@@versionher ikisi de