Ne söyleyebilirim yordam önbellek isabet oranı% 95'in altında bir sorundur. Kutumda, değerler% 85 ile% 95 arasında değişiyor.
Bu sorunu nasıl düzeltirim? Sunucu, RAM olmamalıdır, bu yüzden bir sorun olmamalıdır. Başka ne olabilir ki?
Yanıtlar:
E-tablonuzdaki önemli veri noktalarını özetleyelim (ve yuvarlayalım!):
Total Use Count 1
--------------------------------------- -----------------------
Total Plans Total MBs Avg Use Count Total Plans Total MBs
----------- --------- ------------- ----------- ---------
Adhoc 55,987 3,054 3 38,314 2,036
Proc 709 1,502 1,549 135 527İlk satır, plan önbelleğinizin yaklaşık 2 / 3'ünü kaplayan kötü şeyleri gösterir (çoğunlukla sadece bir kez kullanılan, birkaç küçük istisna dışında). Bunlardan olabildiğince kurtulmaya çalışmalısınız. İkinci sıra iyi şeyleri gösterir. Bunlar, plan önbelleğinizde istediğiniz şeylerdir (yüksek miktarda yeniden kullanıma sahip planlar). Verilerin geri kalanı büyük ölçüde alakasız IMHO'dur. Diğer bir nokta da: erişimin yalnızca saklı yordamlar yoluyla olduğunu söylüyorsunuz, ancak bu yordamlar dinamik SQL kullanıyorsa, bu ifadeler AdHocplanlar değil, Procplanlar olarak önbelleğe alınır .
2008'de veya daha büyük bir sürümde, açıp bir optimize for ad hoc workloadssonraki soruna geçmeyi söyleyebilirim - bu, tek kullanımlık planlarınızın şu anda işgal ettiği MB'lerin miktarını bir şeyin yanına götürür. Ne yazık ki, 2005'te, ifade düzeyinde OPTION (RECOMPILE)ve / veya daha az / dinamik dinamik SQL kullanmamak için saklı yordamları yeniden düzenlemek veya veritabanı düzeyinde zorunlu parametreleştirmeyi açmak dışında seçenekleriniz oldukça sınırlıdır . değişmezleri plan eşleme amaçları için parametreler olarak ele alarak benzer sorgular. Plan kılavuzlarından bahsetmekten bile çekiniyorum çünkü ürkek için değiller ve - bu cevabın ilerleyen bölümlerinde tartışacağım gibi - plan önbelleğinizin kesinlikle performansınızın kaynağı olduğunu bilmedikçe bu yolda ilerlemeye değdiğinden emin değilim konu.
İstediğim @@VERSIONSP2 önce, planı önbelleğe tahsis edilebilir bellek miktarına ilişkin algoritma nispeten kaçak kaz oldu çünkü. SP2'den itibaren bunu biraz sıkılaştırdılar (değişiklik bu yazı ve bu yazıda belgeleniyor ve açıklanıyor ). Sizin durumunuzda, plan önbelleği nispeten doludur, bu nedenle önbellek özlemleri almanız şaşırtıcı değildir. 26 GB = üst sınır 5,8 GB; E-tabloda ~ 4,5 GB görüyorum, ancak burada bilmediğim bazı hesaplama veya yapılandırma farkı olabilir.
Bu MSDN makale bahsediyor optimize for ad hoc workloadssunucuya 2008 yılında eklendi ve muhtemelen artık tüm tavsiye sunucu düzeyinde bu ayarı, ayar yokluğunda (sizin önbelleklerini için daha fazla bellek tahsis etmek izin verecek olan izleme bayrağı 8032 bahseder ayarı müşterilerimiz veya en azından% 99'u artık 2005'te değil). Bu izleme bayrağını 2005 SP3 veya SP4'te hiç test etmedim ve dürüstçe ne zaman tanıtıldığından emin değilim. Ayrıca, sorununuzu çözüp çözmeyeceğini veya sadece kaydırıp kaydırmayacağını bilmiyorum, çünkü önbelleklere% 50 daha fazla RAM ayırmış olsanız bile, hala dolduruyor ve doğası gereği çok fazla önbellek özlüyor olmalısınız. saklı yordamlar.
Ya da, elbette, doğrudan plan önbelleği ile ilgili çözülmesi gereken bir sorun varsa. Önbellek isabet oranınızın beklediğiniz kadar yüksek olmaması, soruna neden olduğu anlamına gelmez ve elbette bunun tersi% 100 önbellek isabet oranında bile - ki bu çok fazla göz önüne alındığında gerçekçi görünmüyor planlarınız tek kullanımlık ve ad hoc'tur - kullanıcılarınız yine de tamamen başka bir şeyin neden olduğu performans sorunlarından muzdarip olabilir.
Benim önerim, önbellek isabet oranını planlamaktan daha iyi sigara tabancaları aramak. Kullanıcılarınızın performans şikayetleriyle ilgili daha ayrıntılı bilgi edinin. Tüm sorgular her zaman yavaş mı? Belirli sorgular? Günün / haftanın / iş döngüsünün belirli zamanları? Yalnızca raporlama sorguları yavaş mı? SQL Server'ın en iyi uygulamalarına ilişkin bu kuşkusuz kuru ve uzun belgeyi, özellikle performans sorunlarını tanımlamak, teşhis etmek ve çözmek için mantıklı bir yaklaşım formüle etmenize yardımcı olabilecek beklemeler ve kuyruklar bölümünden ciddi bir şekilde okuyun . Bir gösterge tablosunda bazı sayıların daha iyi görünmesini sağlamak - soruna doğrudan katkıda bulunmadığını bile bilmediğiniz bir sayı - çok tatmin edici olabilir, ancak kullanıcılarınızın performans sorunlarını çözmezse, sizi gerçekten elde etmedi herhangi bir yer.
Bunlar ayrıca derleme / yeniden derleme ve önbellek yeniden kullanımını planlamak için de yararlı olabilir. Bunlardan bazıları 2008'e odaklanmıştır (özellikle geçici iş yükleri ayarıyla ilgili olanlar), ancak bilgilerin çoğu 2005 için ve / veya yükseltmenin faydalarını daha iyi anlamak için yararlıdır (ipucu, ipucu).