8 dk okuma
Giriş
SQL Server parameter sniffing, aynı parametrik sorgunun bazı değerlerde çok hızlı, bazı değerlerde ise beklenmedik ölçüde yavaş çalışmasının en sık karşılaşılan nedenlerinden biridir. Sorunun kaynağı çoğu zaman parametre kullanmak değil; ilk derlemede oluşan ve önbelleğe alınan yürütme planının farklı veri dağılımlarına uygun olmamasıdır. Bu nedenle doğru yaklaşım parameter sniffing davranışını sistem genelinde kapatmak değil, önce plan davranışını ve iş yükünü ölçmek, ardından en dar kapsamlı çözümü seçmektir.
SQL Server derleme veya yeniden derleme sırasında mevcut parametre değerlerini Query Optimizer’a iletebilir. Bu davranış plan yeniden kullanımını destekler ve çoğu iş yükünde faydalıdır. Ancak veri dağılımı dengesiz olduğunda bir müşteri, mağaza, tarih aralığı veya durum kodu için iyi olan plan başka bir değer için pahalı hale gelebilir. Bu rehberde problemi teşhis etmekten SQL Server 2022 Parameter Sensitive Plan optimizasyonuna kadar üretimde uygulanabilir bir yol haritası kuracağız.
Parameter sniffing, Query Store ve PSP senaryolarını çalışan SQL örnekleriyle inceleyin.
İçindekiler
- SQL Server Parameter Sniffing Nedir?
- Sorunun Gerçek Belirtilerini Yakala
- Execution Plan ve Query Store ile Teşhis Et
- Veri Dağılımını ve İstatistikleri Kontrol Et
- SQL Server 2022 PSP Optimizasyonunu Kullan
- RECOMPILE ve OPTIMIZE FOR Seçeneklerini Doğru Kullan
- Query Store Hints ile Kodsuz Müdahale Et
- Sonuç
- Güvenilir Araştırma Kaynakları
1. SQL Server Parameter Sniffing Nedir?
Parameter sniffing, SQL Server’ın parametrik bir sorguyu derlerken o anda kullanılan parametre değerlerini dikkate almasıdır. Amaç, mevcut değer için iyi bir yürütme planı üretmek ve bu planı sonraki çağrılarda yeniden kullanmaktır. Stored procedure, sp_executesql ve prepared query senaryolarında bu davranış görülebilir.
Plan yeniden kullanımı neden bazen sorun olur?
Örneğin Orders tablosunda CustomerId dağılımı çok dengesiz olsun. Bir müşteri yalnızca 20 satıra sahipken başka bir müşteri 2 milyon satıra sahip olabilir. İlk derleme küçük müşteriyle yapılırsa optimizer Index Seek ve Nested Loops ağırlıklı bir plan seçebilir. Aynı plan çok büyük müşteri için yeniden kullanıldığında milyonlarca lookup oluşabilir. Tersi durumda büyük müşteri için seçilen scan tabanlı plan küçük müşteri çağrılarında gereksiz I/O yaratabilir.
2. Sorunun Gerçek Belirtilerini Yakala
İlk kural, yavaş sorguyu tek bir çalıştırmaya bakarak etiketlememektir. Aynı sorguyu farklı parametre değerleriyle çalıştırın ve duration, CPU, logical reads, returned row count ve execution plan değişkenlerini karşılaştırın. Uygulama bazen hızlı bazen yavaşsa; procedure yeniden derlendikten, servis yeniden başladıktan veya plan cache temizlendikten sonra davranış değişiyorsa parameter sensitivity güçlü bir adaydır.
Aynı zamanda blocking, eksik index, güncel olmayan statistics, memory grant, geçici veritabanı kaynak baskısı ve network gecikmesi gibi alternatif nedenleri elemek gerekir.
3. Execution Plan ve Query Store ile Teşhis Et
Actual Execution Plan üzerinde tahmini satır sayıları ile gerçek satır sayılarını karşılaştırın. Index Seek/Scan seçimi, join algoritmaları, key lookup sayısı, memory grant ve spill belirtileri özellikle değerlidir. Fakat tek bir plan ekranı geçmişi göstermez; burada Query Store devreye girer.
Query Store sorgu metinlerini, planları ve runtime istatistiklerini kalıcı olarak saklayarak aynı query_id için farklı planların zaman içindeki davranışını karşılaştırmayı kolaylaştırır. Ortalama süre tek başına yeterli değildir; farklı interval ve planlardaki execution count, duration, CPU ve logical I/O dağılımını birlikte okuyun.
Sitedeki ilgili proje örneği: Nebim V3 – OpenCart Entegrasyon Programı sayfasında SQL Server tabanlı veri yönetimi ve background worker yaklaşımının üretim mimarisindeki yerini görebilirsiniz.
4. Veri Dağılımını ve İstatistikleri Kontrol Et
Parameter-sensitive plan problemlerinin merkezinde çoğu zaman non-uniform veri dağılımı vardır. Bu yüzden ilgili kolonların statistics histogramını, seçiciliğini ve veri büyümesini inceleyin. İstatistikler eskiyse optimizer gerçek dağılımı doğru tahmin edemeyebilir; ancak körlemesine UPDATE STATISTICS çalıştırmak da her problemi çözmez. Önce hangi statistics nesnesinin plan kararını etkilediğini belirleyin.
ERP ve entegrasyon sistemlerinde bu durum şirket, mağaza, tarih, belge tipi veya işlem durumu gibi alanlarda sık görülür. Burada ticari alan eşlemelerini veya müşteriye özel sorguları paylaşmadan genel prensip nettir: yüksek varyanslı filtre kolonları plan kararlılığı açısından ayrıca izlenmelidir.
5. SQL Server 2022 PSP Optimizasyonunu Kullan
SQL Server 2022 ile gelen Parameter Sensitive Plan optimization, tek bir parametrik statement için birden fazla aktif cached plan oluşturabilen Intelligent Query Processing özelliğidir. Sistem parametre değerlerini aralıklara ayıran bir dispatcher plan üretir ve çalışma anında uygun query variant planını seçebilir. Böylece küçük ve büyük veri kümeleri için tek planı zorunlu kılmak yerine farklı planlar birlikte yaşayabilir.
PSP için SQL Server 2022 veya uyumlu Azure SQL hedefi ve database compatibility level 160 gerekir. Query Store’u açık tutmak varyantları ve davranışı izlemeyi kolaylaştırır. Özelliğin devrede olması her yavaş sorgunun otomatik düzeleceği anlamına gelmez; eligibility, predicate yapısı ve iş yükü hâlâ önemlidir.
6. RECOMPILE ve OPTIMIZE FOR Seçeneklerini Doğru Kullan
OPTION (RECOMPILE)
RECOMPILE her çalıştırmada mevcut değerlerle yeni plan üretir. Parametre dağılımı çok değişkense etkili olabilir; fakat compile CPU maliyetini artırır ve plan yeniden kullanımını ortadan kaldırır. Çok sık çalışan kısa sorgularda varsayılan çözüm haline getirilmemelidir. Daha seyrek çalışan, parametreye aşırı duyarlı rapor sorgularında ise mantıklı olabilir.
OPTIMIZE FOR ve OPTIMIZE FOR UNKNOWN
OPTIMIZE FOR belirli bir temsilî değer üzerinden plan üretmeyi, OPTIMIZE FOR UNKNOWN ise belirli sniffed değere aşırı bağlanmayan genel tahmin yaklaşımını hedefler. Bu seçenekler veri dağılımı ve iş yükü gerçekten anlaşıldığında kullanılmalıdır. Bir “sihirli hint” seçmek yerine, çözümün farklı parametre sınıflarındaki toplam maliyetini ölçün.
7. Query Store Hints ile Kodsuz Müdahale Et
SQL Server 2022 ve desteklenen Azure SQL platformlarında Query Store hints, uygulama kodunu değiştirmeden belirli bir query_id için query hint uygulamayı sağlar. Bu özellikle üçüncü taraf uygulama, eski servis veya hızlı üretim müdahalesi gereken senaryolarda değerlidir. Ancak Microsoft da query hint kullanımını deneyimli geliştirici ve DBA’lar için son çare yaklaşımı olarak konumlandırır.
Üretim akışı şu şekilde olmalıdır: Query Store ile problemi kanıtla, baseline metriklerini kaydet, en dar kapsamlı müdahaleyi uygula, aynı parametre setleriyle tekrar ölç, ardından birkaç iş döngüsü boyunca regresyon olup olmadığını izle. Başarı kriteri yalnızca tek sorgunun hızlanması değil; CPU, I/O, concurrency ve plan kararlılığının birlikte iyileşmesidir.
Backend ve veri katmanını birlikte ele alan çalışma yaklaşımı için Hakkımda / Data & SQL bölümündeki SQL performansı ve sürdürülebilir sistem yaklaşımı da bu konunun doğal bağlamını oluşturuyor.
Sonuç
SQL Server parameter sniffing tek başına bir hata değildir; plan yeniden kullanım mekanizmasının veri dağılımı değişken olduğunda görünür hale gelen yan etkisidir. Sağlıklı çözüm, parameter sniffing’i sistem genelinde kapatmak yerine problemli sorguyu kanıtlarla izole etmektir. Execution Plan ve Query Store ile teşhis, statistics ve veri dağılımı kontrolü, SQL Server 2022 PSP değerlendirmesi ve gerektiğinde RECOMPILE, OPTIMIZE FOR veya Query Store hints gibi hedefli araçlar bu sırayla ele alınmalıdır.
Bu yaklaşım özellikle yüksek hacimli backend, ERP entegrasyonu ve raporlama sistemlerinde önemlidir. Çünkü yanlış bir plan yalnızca tek bir ekranı yavaşlatmaz; connection pool, CPU, disk I/O ve eşzamanlı işlemler üzerinden tüm uygulamayı etkileyebilir. Ölçülebilir, geri alınabilir ve sorgu seviyesinde sınırlı müdahaleler uzun vadede daha güvenli performans yönetimi sağlar.