# Query Store ve Değişiklik Yönetimi: Performans Regresyonunu Yakalamak

Bir deployment sonrası sorgular yavaşladı. Kim ne değiştirdi? Hangi değişiklik bu regresyona yol açtı? Query Store bu soruları yanıtlamak için güçlü bir araç.

Query Store Nedir? Query Store, SQL Server 2016 ile gelen ve sorgu planlarını ile performans istatistiklerini otomatik olarak kaydeden bir özellik. Önceki versiyonlar dahil her şey kaydediliyor: hangi sorgu hangi planla çalıştı, ne kadar sürdü, kaç kez çalıştı. Zaman içindeki değişim görünür. sql-- Query Store'u etkinleştir ALTER DATABASE VeritabaniAdi SET QUERY\_STORE = ON WITH ( OPERATION\_MODE = READ\_WRITE, CLEANUP\_POLICY = (STALE\_QUERY\_THRESHOLD\_DAYS = 90), DATA\_FLUSH\_INTERVAL\_SECONDS = 900, MAX\_STORAGE\_SIZE\_MB = 1000 );

Deployment Sonrası Performans Karşılaştırması Query Store'un en güçlü kullanım alanlarından biri deployment öncesi ve sonrası karşılaştırma. sql-- Deployment sonrası performansı gerileyen sorgular SELECT TOP 20 q.query\_id, qt.query\_sql\_text, rs\_before.avg\_duration / 1000.0 AS OncekiSure\_ms, rs\_after.avg\_duration / 1000.0 AS SonrakiSure\_ms, (rs\_after.avg\_duration - rs\_before.avg\_duration) / 1000.0 AS FarkMs, rs\_after.avg\_duration \* 100.0 / NULLIF(rs\_before.avg\_duration, 0) - 100 AS YuzdeDegisim FROM sys.query\_store\_query q JOIN sys.query\_store\_query\_text qt ON q.query\_text\_id = qt.query\_text\_id JOIN sys.query\_store\_plan p\_before ON q.query\_id = p\_before.query\_id JOIN sys.query\_store\_runtime\_stats rs\_before ON p\_before.plan\_id = rs\_before.plan\_id JOIN sys.query\_store\_plan p\_after ON q.query\_id = p\_after.query\_id JOIN sys.query\_store\_runtime\_stats rs\_after ON p\_after.plan\_id = rs\_after.plan\_id JOIN sys.query\_store\_runtime\_stats\_interval i\_before ON rs\_before.runtime\_stats\_interval\_id = i\_before.runtime\_stats\_interval\_id JOIN sys.query\_store\_runtime\_stats\_interval i\_after ON rs\_after.runtime\_stats\_interval\_id = i\_after.runtime\_stats\_interval\_id WHERE i\_before.start\_time < '2024-03-15 18:00' -- deployment öncesi AND i\_after.start\_time > '2024-03-15 18:00' -- deployment sonrası AND rs\_after.avg\_duration > rs\_before.avg\_duration \* 1.2 -- %20 yavaşlama ORDER BY YuzdeDegisim DESC;

Plan Forcing ile Geçici Çözüm Deployment sonrası bir sorgu yavaşladı ve rollback yapılamıyor. Query Store plan forcing ile önceki iyi planı zorla uygulayabilirsiniz. sql-- Önceki iyi planı zorla uygula EXEC sys.sp\_query\_store\_force\_plan @query\_id = 42, @plan\_id = 15; Bu kalıcı çözüm değil. Asıl sorun (neden plan değişti) araştırılmalı ve düzeltilmeli. Ama acil durumda zaman kazandırır.

Query Store ve Değişiklik Yönetimi Entegrasyonu Her deployment öncesinde kritik sorguların performans istatistikleri kaydedilmeli. Deployment sonrasında karşılaştırma yapılmalı. Önemli bir regresyon varsa doğrulama adımı geçilmemeli. Bu adım değişiklik yönetim sürecinin doğrulama fazına eklenmeli: teknik doğrulama değil, performans doğrulaması.

Sonuç Query Store değişiklik yönetiminin görünmez bir katmanını görünür kılar: performans. Deployment öncesi ve sonrası karşılaştırma, regresyonu erken yakalamak için en güçlü araçlardan biri. Detaylı bilgi için: sqlchangeguard.com