İstatistikleri, yürütme planlarını ve 'artan temel sorunu' anlama

İstatistikler, yürütme planları, saklı yordam yürütme arasındaki ilişkiyi (kavramsal olarak) daha iyi anlamaya çalışıyorum.

İstatistiklerin yalnızca saklı yordam için yürütme planı oluştururken kullanıldığını ve gerçek yürütme bağlamında kullanılmadığını söyleyerek doğru muyum? Diğer bir deyişle, bu doğruysa, plan oluşturulduktan sonra (ve düzgün bir şekilde yeniden kullanıldığını varsayarak), "güncel" istatistikler ne kadar önemlidir?

Özellikle , okuduğum bir makalenin ( İstatistikler, satır tahminleri ve artan tarih sütunu ), her gün birkaç müşterimizin veritabanlarıyla karşılaştığım senaryolara çok benzeyen bir senaryoyu açıklayan motive oldum .

Belirli bir saklı yordam kullanarak düzenli olarak sorguladığımız en büyük tablolarımızdan birinde artan bir tarih / saat sütunumuz var.

Günde yüz bin satır eklediğinizde yürütme planlarının eski haline gelmesini nasıl önlersiniz?

Bu sorunla mücadele etmek için istatistikleri sık sık güncelliyoruz, bu saklı yordamın sorgusunda OPTION (RECOMPILE) ipucunu kullanmak anlamlı olur mu?

Herhangi bir tavsiye veya tavsiye takdir edilecektir.

Güncelleme : SQL Server 2012 (SP1) kullanıyorum.

İstatistiklerin yalnızca saklı yordam için yürütme planı oluştururken kullanıldığını ve gerçek yürütme bağlamında kullanılmadığını söyleyerek doğru muyum?

Hayır, olan, saklı yordamın yürütme planının önbelleğe alınmasıdır. Planı tutmaya devam etmek için yeterli bellek olduğu varsayılarak, aşağıdakilerden biri gerçekleşmedikçe değişmeyecektir ( SQL Server belgelerindeki Yürütme Planı Önbelleğe Alma ve Yeniden Kullanma , vurgu eklendi):

• Sorgu tarafından başvurulan bir tablo veya görünümde yapılan değişiklikler (ALTER TABLE ve ALTER VIEW).
• Tek bir prosedürde yapılan ve bu prosedürle ilgili tüm planları önbellekten kaldıracak değişiklikler (ALTER PROCEDURE).
• Yürütme planı tarafından kullanılan dizinlerde yapılan değişiklikler.
• Yürütme planı tarafından kullanılan, UPDATE STATISTICS gibi bir ifadeden açıkça oluşturulan veya otomatik olarak oluşturulan istatistiklerle ilgili güncellemeler.
• Yürütme planı tarafından kullanılan bir dizini bırakmak.
• Sp_recompile için açık bir çağrı.
• Anahtarlarda çok sayıda değişiklik (sorgu tarafından başvurulan bir tabloyu değiştiren diğer kullanıcılardan INSERT veya DELETE deyimleri tarafından oluşturulur).
• Tetikleyicili tablolar için, eklenen veya silinen tablolardaki satır sayısı önemli ölçüde artarsa.
• WITH RECOMPILE seçeneğini kullanarak saklı yordamın yürütülmesi.

İstatistikler güncellenirse, önbelleğe alınan plan otomatik olarak yeni istatistikleri dikkate alır ve yeniden derlenir.

Günde yüz bin satır eklediğinizde yürütme planlarının eski haline gelmesini nasıl önlersiniz?

Bunun bir yolu, yukarıda belirtildiği gibi tabloda çok fazla güncelleme olup olmadığıdır. Birkaç yüz bin değişen satır bu durumu karşılayabilir. Ancak emin olmak veya daha ayrıntılı bir kontrole sahip olmak istiyorsanız: istatistiklerinizi güncelleyerek. SQL Server'ın istatistikleri otomatik olarak oluşturmasına ve yönetmesine veya kendiniz manuel olarak yapmasına izin verebilirsiniz. Her iki yöntemle ilgili daha fazla bilgiyi SQL Server Otomatik Güncelleştirme ve Otomatik İstatistik Oluşturma Seçenekleri'nde bulabilirsiniz . Haftalık dizin yeniden oluşturduğunuzda / yaparsanız, bu da planların güncellenmesini tetikler. İstatistikleri çok sık güncellemek gerçek performans sonuçları vermeyebileceğinden, sizin için en faydalı olanı görmek için bazı testler yapın.

Bu sorunla mücadele etmek için istatistikleri sık sık güncelliyoruz, bu saklı yordamın sorgusunda OPTION (RECOMPILE) ipucunu kullanmak anlamlı olur mu?

Sen yok ihtiyaç kullanımına RECOMPILEalıntı kapalı tabanlı beri yeni durum mevcut olduğunda yürütme planı uygun güncellenir görebilirsiniz yukarıda. Gün sonu istatistik güncellemesinde iyi olabilirsiniz (gerçekten endişeleniyorsanız), ancak şimdiye kadar söylediklerinize göre bunun açıkça bir ihtiyaç olduğunu düşünmüyorum. Yine de, bunun saklı yordam performansınız üzerinde ne gibi etkileri olabileceğini görmek için test eder ve buna göre plan yaparım.

İstatistiklerin yalnızca yürütme planını oluştururken kullanıldığını söylerken doğru muyum?

Hayır, güncel olmayan istatistikler , etkilenen ifadenin iyimserlikle ilgili yeniden derlenmesine neden olabilir .

Düzenli olarak sorguladığımız en büyük tablolarımızdan birinde artan bir tarih / saat sütunumuz var

Yük değerlerinin karşılık gelen istatistik histogramında depolanan değer aralığının dışında (özellikle yukarıda) olmasının neden olduğu alt optimal yürütme planları Artan Anahtar Sorunu olarak bilinir . İstatistikleri yeniden oluşturmak olası bir çözümdür, ancak oldukça kaynak yoğun olabilir. Alternatifler:

• İzleme bayrakları 2389 ve 2390 . Bunun için, önde gelen anahtar olarak sorunlu sütunda bir dizin bulunmalıdır. Bölümlenmiş tablolarla çalışmaz ve yalnızca orijinal kardinalite tahmincisi kullanılırsa SQL Server 2014'te etkilidir. İstatistik nesnesi sabit olarak markalanmışsa, izleme bayrağı 4139 da gerekebilir.

• SQL Server 2014'e yükseltin. Yeni kardinalite tahmincisi , ortalama yoğunluk bilgilerini kullanarak histogramın ötesinde tahmin etmek için mantık içerir. Bu, bazı önemli durumlarda 2389/2390 iz bayraklarından daha az doğru olabilir .

• İzleme bayrağı 2371 olan büyük tablolar için daha sık otomatik istatistik güncelleştirmelerini etkinleştirin . Bu izleme bayrağı ile,% 20 + 500 değişiklikten sonra güncelleme yapmak yerine, yalnızca SQRT(1000 * Table rows)değişiklikler yapılması gerekir. Güncellemeler hala yeterince sık tetiklenmeyebileceğinden, bu daha önce belirtilenler kadar eksiksiz bir çözüm değildir.

Sorununuzun kaynağı, histogramın ötesinde yüklem değerlerine dayanan çok sık plan derlemeleri değilse, ancak parametre koklamasının bir sonucu olarak bu kadar kötü bir planı önbelleğe almanın etkileri hakkında daha fazla ise, şunları da düşünebilirsiniz:

• İzleme bayrağı 4136 kullanılarak parametre koklamasını devre dışı bırakma
• OPTIMIZE FOR (@parameter = value)Bilinen bir temsili değer için bir plan derlemek için kullanma
• Kullanma OPTIMIZE FOR (@parameter UNKNOWN)ortalama dağılım kullanılarak optimize etmek
• Kullanarak OPTIMIZE FOR UNKNOWN(4136 ile aynı, ancak sorgu başına)
• OPTION (RECOMPILE)Her seferinde derlemek için kullanılır , belirli bir değeri koklar. Çalışma zamanı değerlerinin büyük çoğunluğu histogram dahilindeyse, bu etkili olabilir.

Parametresi, koklama gömme ve yeniden derleme seçenekleri hakkında daha fazla bilgi için bkz makalemi SQLperformance.com üzerinde.