SQL Server Query Store ile Plan Regresyonlarını Yönetmek

6 dk okuma

Dağıtım sonrası yavaşlamaları geçmiş plan verisiyle kanıtlamak, güvenli müdahale seçmek ve sonucu ölçmek için uygulama rehberi.

Giriş

Bir sürüm yayına çıktıktan sonra belirli ekranların veya API çağrılarının yavaşladığını görmek, SQL Server kullanan ekiplerin en maliyetli üretim sorunlarından biridir. SQL Server Query Store, aynı sorgunun zaman içinde hangi yürütme planlarıyla çalıştığını ve bu planların süre, CPU ile mantıksal okuma davranışını saklayarak tartışmayı tahminden kanıta taşır. Ama amaç her kötü ölçümde planı zorlamak değildir: doğru hedef, regresyonu ayırt etmek, değişikliği en küçük riskle uygulamak ve sonucu ölçerek kalıcı kararı vermektir.

İçindekiler

• Plan regresyonu nedir ve neden görünmez kalır
• Query Store için güvenli başlangıç çizgisi
• Regresyon sinyalini ayırmak
• Sağlıklı planı seçmek
• Müdahale seçeneklerini risk sırasıyla değerlendirmek
• Sonucu ölçmek ve geri alma eşiği koymak
• Operasyonel kontrol listesi
• Sonuç
• Güvenilir Araştırma Kaynakları

1. Plan regresyonu nedir ve neden görünmez kalır

Plan regresyonu, sorgu metni aynı veya işlevsel olarak eşdeğer kalırken seçilen yürütme planının belirgin biçimde daha pahalı hale gelmesidir. Yeni istatistik dağılımı, değişen parametre deseni, veri hacmi ya da dağıtımın dolaylı etkisi tetikleyici olabilir. Sorun çoğu zaman tek bir sorgunun genel ortalamasında kaybolur: günün belirli saatinde, belirli müşteri segmentinde veya yalnızca yeni veri dağılımında görünür. Bu nedenle yalnızca “ortalama süre arttı” alarmı teşhis değildir.

İlk ayrımda, mevcut parameter sniffing rehberindeki parametre-bağımlı davranış ile dağıtım sonrası gerçek plan değişimini birbirinden ayırmak önemlidir. Query Store burada plan kimliği, çalışma aralığı ve ölçüm geçmişini aynı zeminde toplar.

2. Query Store için güvenli başlangıç çizgisi

Önce izleme kapsamını ve saklama politikasını iş yüküne göre belirleyin. Çok kısa geçmiş, karşılaştırılacak sağlıklı dönemi yok eder; kontrolsüz saklama ise altyapı maliyetini büyütür. Üretim veritabanında değişiklikten önce mevcut kapasite, beklenen sorgu hacmi ve bakım penceresi kayda alınmalıdır. Operasyon ekibi için en yararlı başlangıç çizgisi; kritik işlem adları, normal süre aralığı, hata oranı ve sürüm zaman damgasıdır.

Bu yaklaşım, sadece sorgu metnine bakmaktan daha güvenilirdir. Mevcut  yavaş sorgu analiz rehberi ile birlikte kullanıldığında, kaynak baskısı ile plan değişimi ayrımı daha net yapılır.

3. Regresyon sinyalini ayırmak

Zaman penceresini olayla eşleştirin

Önce sürüm dağıtımı, veri yükü, bakım işi veya indeks değişikliği gibi olayların zamanını işaretleyin. Ardından ilgili sorgunun bu pencere öncesi ve sonrasındaki planlarını; yürütme sayısı, ortalama süre ve uç değerlerle karşılaştırın. Tek bir ani sıçrama yerine tekrarlayan eğilim arayın.

Sorgu kimliğini bağlamla doğrulayın

Sorgu kimliği tek başına işlevi açıklamaz. Çağrıyı yapan uygulama sürümü, endpoint veya iş süreci ile ilişkilendirin. Böylece aynı görünen iki sorgunun farklı iş yükü etkileri birbirine karışmaz. Gözlemlenebilirlik tarafında uygulama telemetrisi ile veritabanı ölçümlerini birlikte okumak, kök neden süresini kısaltır.

4. Sağlıklı planı seçmek

Eski plan otomatik olarak doğru plan değildir. Sağlıklı aday; yeterli yürütme sayısına sahip, normal veri dağılımında tutarlı davranmış ve iş kuralını değiştirmeden sonuç üretmiş plandır. Önce test veya kontrollü ön üretim ortamında benzer hacimle teyit edin. İndeks önerisi söz konusuysa, mevcut indeks stratejileri yazısındaki yazma maliyeti ve seçicilik kontrollerini de uygulayın.

5. Müdahale seçeneklerini risk sırasıyla değerlendirmek

En düşük riskli yol genellikle uygulama ve veri bağlamını doğrulamaktır: yanlış parametre tipi, beklenmeyen filtre veya yeni dağıtım davranışı var mı? Sonra istatistik ve indeks sağlığı değerlendirilir. Plan zorlaması ancak regresyon güçlü kanıtla belirlenmiş, seçilen plan yeterli örnekle doğrulanmış ve sahipliği açıkça tanımlanmışsa geçici ya da kontrollü bir koruma katmanı olmalıdır. Kalıcı çözümün yerini alan görünmez bir ayar olmamalıdır.

6. Sonucu ölçmek ve geri alma eşiği koymak

Müdahaleden önce başarı ölçütünü yazın: örneğin p95 süre, CPU zamanı, hata oranı ve kritik işlem sayısı. Değişiklik sonrası aynı pencerede karşılaştırma yapın. Beklenen iyileşme görülmezse veya başka iş yüklerinde maliyet yükselirse geri alma koşulu çalışmalıdır. Bu disiplin, üretimde “iyileşti gibi görünüyor” kararını önler.

7. Operasyonel kontrol listesi

• Dağıtım ve performans olaylarının zaman çizelgesini kaydetin.
• Sorguyu uygulama çağrısı ve iş süreciyle eşleştirin.
• Plan geçmişini yeterli örnek sayısı ve aynı çalışma aralığıyla karşılaştırın.
• Plan zorlaması öncesi doğrulama, sahiplik ve geri alma ölçütlerini yazın.
• Müdahale sonrası p95, CPU, mantıksal okuma ve hata oranını birlikte izleyin.

Sonuç

SQL Server Query Store, dağıtım sonrası yavaşlamayı tek bir ekran görüntüsünden değil, zaman içinde biriken plan ve performans kanıtından yönetmeyi sağlar. En iyi sonuç; regresyonu bağlamıyla saptayan, en küçük müdahaleyi seçen ve her değişikliği ölçülebilir bir geri alma koşuluyla yöneten ekiplerde alınır.

Güvenilir Araştırma Kaynakları

Microsoft Learn — Query Store ile performans izleme

Microsoft Learn — Query Store en iyi uygulamaları