Query Store ve Değişiklik Yönetimi: Performans Regresyonunu Yakalamak
I’m a passionate software engineer specializing in SQL change management, database security, and DevOps automation. With over 17 years of experience in the banking sector, I focus on building tools and processes that make database deployments safer, more auditable, and automated.
As the creator of SQL Change Guard, I develop solutions that use risk scoring and AI-powered code analysis to detect dangerous SQL scripts before they reach production. I’m dedicated to helping teams minimize downtime and data loss through smarter change governance.
When I’m not coding, I enjoy sharing insights about secure development practices, WPF desktop applications, and integrating modern CI/CD pipelines.
Feel free to connect or reach out at info@sqlchangeguard.com
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