“DbccFilesCompact” durumu neden “Askıya Alındı”?

600G veri dosyasında SHRINK dosyası çalıştırıyorum.

Şu anda durum "askıya alındı" olarak rapor ediliyor ve çalıştığı komut raporları sys.dm_exec_requests.percent_completeiçin DbccFilesCompact(ancak çok yavaş)

Neden askıya alındığını ve nasıl daha sorunsuz çalışacağını kontrol etmenin bir yolu var mı?

FYI - Durum Denetimi için SQL Sorgusu

select T.text, R.Status, R.Command, DatabaseName = db_name(R.database_id)
       , R.cpu_time, R.total_elapsed_time, R.percent_complete
from   sys.dm_exec_requests R
       cross apply sys.dm_exec_sql_text(R.sql_handle) T
order by Command

Hayır, neden yavaş çalıştığını kontrol edemezsiniz, ancak size bazı ipuçları verebilirim:

1) SQL 2005'te, kümelenmemiş dizinlerin yönetimi Depolama Altyapısı'ndan (ekibim) Sorgu İşlemciye değiştirildi. Bunun birçok yan etkisi vardır, bunlardan biri yığın veri sayfalarının küçültülerek taşınabilme hızıdır. Kümelenmemiş tüm dizin kayıtları, dizine ekledikleri veri kaydına bir geri bağlantı içerir - bir yığın durumunda, bu, belirli bir veri sayfasındaki kayıt numarasına fiziksel bir bağlantıdır. Bir yığın veri sayfası daralma ile taşındığında, o sayfadaki kayıtlara geri bağlantı veren kümelenmemiş tüm dizin kayıtları sayfanın yeni konumu ile güncellenmelidir. 2000 yılında bu işlem Depolama Motorunun kendisi tarafından çok verimli bir şekilde yapıldı. 2005'ten itibaren, bu kümelenmemiş dizin kayıtlarını güncellemek için Sorgu İşlemcisi çağrılarak yapılmalıdır. Bu bazen 2000'den 100 kat daha yavaştır.

2) Sıra dışı LOB değerleri (gerçek LOB veri türleri veya satır taşması verileri) parçası oldukları veriler veya dizin kaydına bir geri bağlantı içermez. Bir LOB kayıtları sayfası taşındığında, parçası oldukları tüm tablo veya indeks taranarak hangi veri / indeks kayıtlarının onlara işaret ettiğini anlamak için taranmalıdır, böylece yeni konumla güncellenebilirler. Bu da çok, çok yavaş.

3) Veritabanını kullanarak başka bir işlem olabilir, bu da shrink'in sayfaları hareket ettirmesi için gereken kilitleri beklemeyi engellemesine neden olur.

4) Anlık görüntü yalıtımı etkinleştirilmiş olabilir ve küçültme, bu eski sürümleri gerektiren işlemler tamamlanana kadar sürüm deposu bağlantılarına sahip sayfaları taşıyamaz.

5) G / Ç alt sisteminizin gücü düşük olabilir. Düşük tek basamaktan daha yüksek bir disk kuyruğu uzunluğu, darboğazdaki G / Ç alt sisteminiz anlamına gelir.

Bunların herhangi biri veya tümü, yavaş büzülme sürelerine katkıda bulunabilir.

Genel olarak, shrink çalıştırmak istemezsiniz. Ayrıntılar için bu blog yayınına bakın: Veri dosyalarınızı neden küçültmemeniz gerekir .

Bu yardımcı olur umarım!

Tamamlanan yüzdeyi kontrol etmek için bu komut dosyasını çalıştırabilirsiniz!

SELECT 
    percent_complete, 
    start_time, 
    status, 
    command, 
    estimated_completion_time, 
    cpu_time, 
    total_elapsed_time
    --,*
FROM 
    sys.dm_exec_requests
WHERE
    command = 'DbccFilesCompact'

SQL Server 2008 SP1'de bir veritabanını daraltıyorum ve Shrink komutunun ilerlemesini söyleyebileceğim bir yol sp_lock spid yürütmektir ve çoğunlukla dosya 1 üzerine bir kilit koyduktan sonra bittiğinde görebilirsiniz Dosya kimliği 2 kilit ve böylece ve bu şekilde son dosya kimliği üzerinde çalışırken ne zaman söyleyebilirim ve bu neredeyse tamamlandı benim göstergesi.

Teşekkürler,

Alex Aguilar

Sorunun ne olduğunu (benim durumumda) keşfettim ve burada kullandığım çözümü sunuyoruz.

Veritabanını kullanarak hiçbir şeyim yoktu ve ana oturumumda varsayılan veritabanı oldu, ben sp_who2 kullanarak doğruladı. Sonra veritabanına sağ tıkladım, "görevler" i seçin ve sonra "küçült" ve iletişim kutusundaki "tamam" ı tıklayın. Sp_who2 ile tekrar kontrol edersek, durum birkaç dakika boyunca "askıya alınır" ve bundan sonra "özel bir kilit elde edilemez". Kendinizi tahmin edin, ancak iletişim kutusunun kendisinin buna neden olduğundan eminim.

Bu yüzden komut satırı üzerinden gitmeye karar verdim:

DBCC SHRINKDATABASE (myDataBase)

(Cadı her yerde belgelenir), Sonra daralma birkaç saniye sürdü.