SQL Server Query Store: Nasıl Açılır, Hangi Ayarlar Kullanılmalı, Plan Regresyonu Nasıl Düzeltilir?

“Bu sorgu dün hızlıydı, bugün neden yavaş?” sorusu, SQL Server’da en sık sorulan ve plan cache’e bakarak cevaplanması en zor sorulardan biridir. Plan cache yalnızca şu anki planı tutar; servis yeniden başladığında, bellek baskısında ya da istatistikler güncellendiğinde geçmiş kaybolur. Query Store ise sorguları, planlarını ve çalışma istatistiklerini zaman içinde veritabanının kendi içinde saklar. Bir planın ne zaman değiştiğini, değişiklikten önce ve sonra ne kadar sürdüğünü görebilir, gerekirse eski planı zorlayabilirsiniz.

Bu rehberde Query Store’un nasıl açılacağını, üretim için hangi ayarların kullanılacağını, plan regresyonlarının nasıl bulunup düzeltileceğini ve sık karşılaşılan sorunları anlatıyoruz.

Query Store Ne Tutar?

• Sorgu metni ve her sorgu için üretilen tüm planlar.
• Her plan için zaman aralıklarına bölünmüş çalışma istatistikleri: süre, CPU, okuma, yazma, bellek, satır sayısı.
• SQL Server 2017 ve sonrasında sorgu bazında bekleme istatistikleri.

Veriler veritabanının içinde saklanır; yedekle birlikte taşınır ve servis yeniden başladığında kaybolmaz. Query Store SQL Server 2016 ile geldi; SQL Server 2022’de yeni oluşturulan veritabanlarında varsayılan olarak açıktır. Daha eski sürümlerde ya da upgrade edilmiş veritabanlarında kapalı olabilir.

Query Store Açık mı?

SELECT DB_NAME() AS database_name,
       actual_state_desc, desired_state_desc, readonly_reason,
       current_storage_size_mb, max_storage_size_mb,
       query_capture_mode_desc, stale_query_threshold_days
FROM sys.database_query_store_options;

actual_state_desc, desired_state_desc‘ten farklıysa (örneğin READ_WRITE istenmiş ama READ_ONLY’ye düşmüşse) Query Store veri toplamayı durdurmuştur. En sık neden, ayrılan alanın dolmasıdır; readonly_reason nedeni gösterir.

Üretim İçin Önerilen Ayarlar

ALTER DATABASE SatisDB SET QUERY_STORE = ON
(
    OPERATION_MODE = READ_WRITE,
    QUERY_CAPTURE_MODE = AUTO,              -- seyrek ve önemsiz sorguları atlar
    MAX_STORAGE_SIZE_MB = 2048,
    SIZE_BASED_CLEANUP_MODE = AUTO,          -- alan dolmadan eskiyi temizler
    CLEANUP_POLICY = (STALE_QUERY_THRESHOLD_DAYS = 30),
    INTERVAL_LENGTH_MINUTES = 60,
    WAIT_STATS_CAPTURE_MODE = ON
);

• QUERY_CAPTURE_MODE = AUTO: SQL Server 2019 ve sonrasında varsayılandır. ALL modu, ad hoc sorguların yoğun olduğu sistemlerde Query Store’u hızla doldurur.
• MAX_STORAGE_SIZE_MB: Varsayılan 1 GB çoğu veritabanı için yeterlidir; çok sayıda farklı sorgu çalıştıran sistemlerde artırın ve büyümeyi izleyin. Çok büyük değerler, Query Store raporlarını ve temizliği yavaşlatabilir.
• SIZE_BASED_CLEANUP_MODE = AUTO: Alan sınıra yaklaştığında en eski ve en az önemli verileri temizleyerek READ_ONLY’ye düşmeyi önler.

Plan Regresyonunu Bulmak

SSMS’te veritabanının altındaki Query Store klasöründe hazır raporlar vardır. En kullanışlıları Regressed Queries (performansı kötüleşen sorgular) ve Top Resource Consuming Queries‘tir. Aynı bilgiyi T-SQL ile de alabilirsiniz; aşağıdaki sorgu son 24 saatte en çok CPU tüketen sorguları ve kaç farklı plan kullandıklarını listeler:

SELECT TOP (20)
       q.query_id,
       COUNT(DISTINCT p.plan_id)                             AS plan_count,
       SUM(rs.count_executions)                              AS executions,
       SUM(rs.avg_cpu_time * rs.count_executions) / 1000     AS total_cpu_ms,
       SUM(rs.avg_duration * rs.count_executions)
         / NULLIF(SUM(rs.count_executions), 0) / 1000        AS avg_duration_ms,
       MAX(SUBSTRING(qt.query_sql_text, 1, 200))             AS query_text
FROM sys.query_store_query AS q
JOIN sys.query_store_query_text AS qt ON qt.query_text_id = q.query_text_id
JOIN sys.query_store_plan AS p ON p.query_id = q.query_id
JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id = p.plan_id
JOIN sys.query_store_runtime_stats_interval AS i
     ON i.runtime_stats_interval_id = rs.runtime_stats_interval_id
WHERE i.start_time > DATEADD(HOUR, -24, SYSUTCDATETIME())
GROUP BY q.query_id
ORDER BY total_cpu_ms DESC;

plan_count değeri 1’den büyük ve sorgunun süresi belirli bir tarihten sonra artmışsa, büyük olasılıkla bir plan değişikliği yaşanmıştır.

İyi Planı Zorlamak

Eski plan belirgin şekilde daha iyiyse, o planı zorlayarak sorunu dakikalar içinde giderebilirsiniz:

EXEC sys.sp_query_store_force_plan @query_id = 42, @plan_id = 17;

-- Zorlanmış planlar ve başarısız zorlama girişimleri
SELECT plan_id, query_id, is_forced_plan, force_failure_count, last_force_failure_reason_desc
FROM sys.query_store_plan
WHERE is_forced_plan = 1;

Plan zorlamak bir yara bandıdır, kalıcı çözüm değil. Planın neden değiştiğini (istatistik, parametre hassasiyeti, eksik index, veri dağılımı) araştırın. Zorlanan planı kullanan bir index silinirse zorlama başarısız olur; force_failure_count bunu gösterir.

Upgrade ve Compatibility Level Değişikliklerinde

Query Store’un en değerli kullanım alanlarından biri sürüm geçişleridir. Önerilen sıra: upgrade sonrasında veritabanını eski compatibility level’da tutun, Query Store’un bir süre baseline toplamasına izin verin, ardından compatibility level’ı yükseltin ve gerileyen sorguları Regressed Queries raporuyla yakalayın. Ayrıntılar compatibility level rehberimizde.

Always On ve Query Store

SQL Server 2025’ten önce Query Store yalnızca primary replikadaki iş yükünü kaydeder; okunabilir secondary’lerde çalışan rapor sorgularının geçmişi tutulmaz. SQL Server 2025 ile Query Store secondary replikalar için de kullanılabilir hale geldi.

Query Store Kontrol Listesi

• Tüm kullanıcı veritabanlarında Query Store READ_WRITE durumda.
• Capture mode AUTO, boyut ve temizlik ayarları yapılandırılmış.
• actual_state_desc izleniyor; READ_ONLY’ye düşme uyarı üretiyor.
• Zorlanmış planlar belgelenmiş ve kök nedenleri araştırılmış.
• Compatibility level değişikliklerinden önce baseline toplanıyor.