Yavaş bir sorgunun araştırılması sırasında, yürütme planının son derece düşük olduğu görülmüştür (tahmini yürütme sayısının 1 olduğu 9 milyon yürütmeyi gerçekleştiren iç içe döngü). Gerçekten güncel olmayan bazı istatistiklerin istatistikleri yeniden oluşturduğumu ve performans sorununun etkili bir şekilde çözüldüğünü doğruladıktan sonra.
Bu veritabanında Otomatik Güncelleme İstatistikleri etkin (varsayılan olarak açık). % 20 + 500 satır değişikliği (güncelleme / ekleme / silme) temelinde otomatik istatistik güncellemeleri için bir eşik olduğunu anlıyorum. Bu eşik, birden çok dizinde büyük ölçüde aşılmış gibi görünüyor, çünkü (A) otomatik güncellemelerde bir sorun var veya (B) Güncelleme stratejisinde çevrimiçi olarak bulabildiğimden daha fazlası var dokümantasyon.
İstatistikleri güncellemek için zamanlanmış bir görevin ayarlanabileceğini takdir ediyorum ve bu, başka bir çözüm bulunamazsa alacağımız yaklaşım olabilir, ancak bu kadar çok sayıda değişikliğin neden bir bazı istatistikler için otomatik güncelleme - zamanlanmış bir görev tarafından hangi istatistiklerin güncellenmesi gerektiğine karar vermemize neden yardımcı olabileceğini anlamak.
Bazı ek notlar:
1) Sorun, verilerin bir yük testi ile yaratıldığı ve bu nedenle kısa bir sürede büyük miktarda veri eklendiği bir veritabanında not edildi, böylece otomatik güncelleme periyodik olarak gerçekleştiğinde (örn. çoğu) o zaman bu, gözlemlenen davranışın bir kısmını açıklayabilir. Ayrıca yük testlerimiz veritabanını yoğun bir şekilde vurgulama eğilimindedir, bu nedenle SQL'in ağır yük varken istatistik güncellemelerini ertelediğini merak ediyorum (ve daha sonra istatistikleri herhangi bir nedenle güncellemiyor).
2) Bu sorunu art arda INSERT, SELECT ve DELETE ifadeleri içeren bir test komut dosyasıyla yeniden oluşturmaya çalışırken, sorun oluşmadı. Yük ayırma komut dosyası ayrı ayrı satır ekleme eğiliminde iken, burada ayrım bu ifadelerin her SQL ifadesi başına birçok satır etkilediğini merak ediyorum.
3) Söz konusu DB 'Basit' kurtarma modeline ayarlanmıştır.
İlgili bazı bağlantılar:
- Yavaş Çalışan Sorguları Analiz İçin Kontrol Listesi
- Sorgu Performansını İyileştirmek için İstatistikleri Kullanma
Ben de microsoft connect ile bu sorunu ortaya çıkardı:
GÜNCELLEME 2011-06-30:
Daha fazla araştırmada, eşik seviyelerinin ötesinde güncel olmayan istatistiklerin (örneğin 500 satır +% 20) sorun sorgusu tarafından kullanılmayan istatistikler olduğunu düşünüyorum, bu nedenle muhtemelen bir sorgu çalıştırıldığında güncellenecek Onları gerektirir. Sorgu tarafından kullanılan istatistikler için bunlar düzenli olarak güncellenmektedir. Geriye kalan sorun, bu istatistiklerin yalnızca nispeten az sayıda eklemeden sonra sorgu planı optimize edicisini büyük ölçüde yanıltıcı olmasıdır (örneğin, yukarıda bahsedilen 9 milyona kadar neden olması, tahmini sayının 1 olduğu yeri arar).
Şu anki sorunum, sorunun kötü bir birincil anahtar seçimiyle ilgili olması, anahtarın NEWID () kullanılarak oluşturulan benzersiz bir tanımlayıcı olması ve bu nedenle çok hızlı bir şekilde parçalanmış bir dizin oluşturmasıdır - özellikle SQL'deki varsayılan dolgu faktörü olarak Sunucu% 100. Benim önsezim, bu bir şekilde nispeten az sayıda satır eklemesinden sonra yanıltıcı istatistiklerle sonuçlanıyor - istatistikleri yeniden hesaplama eşiğinden daha az. Endeksleri kısmen yeniden oluşturmadan çok fazla veri oluşturduğum için bu muhtemelen bir sorun değil, bu nedenle kötü istatistikler sonuçta ortaya çıkan çok yüksek dizin parçalanmasının bir sonucu olabilir. Uzun bir süre boyunca gerçek bir sistemde daha iyi bir performans fikri elde etmek için yük testime SQL Server bakım döngüleri eklemem gerektiğini düşünüyorum.
GÜNCELLEME 2012-01-10:
Dikkate alınması gereken başka bir faktör. Eski ve / veya yanıltıcı istatistiklerin ortaya çıkmasıyla ilgili belirli eksiklikleri gidermek için SQL Server 2005'e iki izleme bayrağı eklendi (ve 2008'de hala var gibi görünüyor). Söz konusu bayraklar:
DBCC TRACEON(2389)
DBCC TRACEON(2390)MSDN: Ian Jose'nin WebLog: Artan Sütunlara İlişkin Artan Anahtarlar ve Otomatik Hızlı Düzeltilmiş İstatistik İstatistikleri, Fabiano Amorim
Zararlı etkileri olabileceğinden, bu bayrakları etkinleştirmeye karar verirken elbette çok dikkatli olmalısınız.