Hevesli Biriktirme Hangi Sorunları Gösteriyor

Şu anda SQL Server 2008 R2’de çalışıyor

Bir UPDATE ifadesinin performansını artırmaya çalışıyorum. Şov programında ortaya çıkan bir İstekli Biriktirme işlemi olduğunu fark ettim. Biriktirme işlemleri hakkındaki bilgilerim oldukça basit - güncelleme sırasında tablo için geçici depolama alanı oluşturuyorlar.

Ayrıca, daha kötü yürütme sürelerini önlerken, istekli biriktiricilerin çoğu zaman masa yapısı ve / veya sorgu ifadeleriyle ilgili sorunların göstergesi olduğunu da biliyorum.

Sorum oldukça basit: Sorgu planınızda bir istekli biriktirme gördüğünüzde, ilk olarak hangi sorunları ele alıyorsunuz?

Performansı artırmak için sistemimizin her bölümünü analiz edeceğim - sadece nereden başlayacağım konusunda rehberlik arıyorum.

Bir UPDATE deyiminin performansını artırmaya çalışıyorum. Şov programında ortaya çıkan bir İstekli Biriktirme işlemi olduğunu fark ettim.

İstekli Makaralar, Cadılar Bayramı Koruması da dahil olmak üzere çeşitli nedenlerle veya kümelenmemiş dizinleri korurken G / Ç'yi optimize etmek için eklenebilir .

Uygulama planını görmeden (hatta bir resmini bile görmeden), bu senaryolardan hangisinin sizin durumunuzda geçerli olacağından emin olmak zordur. Veri hassasiyeti önemliyse, SentryOne Plan Gezgini'ni kullanarak analiz için planın anonim versiyonunu yüklemeyi düşünün .

Eager Makarası, yine de konsantre olmanız gereken şey olmayabilir; birçok faktör, verileri değiştiren sorguların gerçek performansını etkiler . Ayarlama çabalarınızı Eager Spool operatörü için gösterilen tahmini yüzde maliyetine dayandırıyorsanız, lütfen bu tahminlerin, donanım yapılandırmanızın özelliklerine uygun olmayan bir model kullanılarak oluşturulduğunu düşünün .

Bazen, diğer engelleme operatörleri bulunduğunda istekli makaradan kaçınılabilir. Bu nedenle, verinin o aşamaya ulaştığı zamana göre sıralandığından emin olmak iyi bir fikirdir. (belki eksik indeksler?)

Cadılar Bayramı koruması için oradaysa, diğerlerinin dediği gibi yapabileceğiniz çok az şey vardır.