SQL Server Query Store: veritabanından üç çekmeceli depoya kayıt, plan değişince yükselen süre grafiği ve kilitlenen iyi plan

SQL Server Query Store: Yavaşlayan Sorgu Nasıl Bulunur ve Düzeltilir?

SQL Server Query Store, sorgu planlarını ve çalışma istatistiklerini zamana göre kaydeder. Ne kaydettiği, plan önbelleğinden farkı, 6 adımda kullanımı, plan zorlamanın doğru olduğu durumlar, sık hatalar ve kontrol listesi.

Kısaca: SQL Server Query Store, veritabanında çalışan sorguların planlarını ve çalışma istatistiklerini zamana göre kaydeden yerleşik bir özelliktir. Dün hızlı çalışan bir rapor bugün yavaşladıysa Query Store ile hangi sorgunun, ne zaman ve hangi plan değişikliğinden sonra yavaşladığını görebilir, gerekirse eski ve hızlı planı uygulama kodunu değiştirmeden zorlayabilirsiniz.

KOBİ’lerde en sık duyulan şikâyet şudur: “Sistem birden yavaşladı, ama kimse bir şey değiştirmedi.” Çoğu zaman gerçekten kimse kod değiştirmemiştir; SQL Server, istatistikler güncellendiği veya veri dağılımı değiştiği için aynı sorgu için yeni bir yürütme planı seçmiştir. Sorun şu ki olay anında elinizde bir önceki planın kaydı yoksa nedeni bulmak tahmine döner. Query Store bu kaydı sizin için tutar.

İçindekiler

SQL Server Query Store nedir ve neleri kaydeder?

Query Store, SQL Server 2016 ve sonraki sürümlerde her veritabanı için ayrı açılan, sorgu metinlerini, yürütme planlarını ve bu planların çalışma süresi, CPU ve okuma gibi istatistiklerini zaman dilimlerine bölerek saklayan bir izleme özelliğidir.

Microsoft’un Query Store belgelerine göre bu bilgiler üç ayrı depoda tutulur:

  • Plan deposu: Her sorgu için kullanılan yürütme planları.
  • Çalışma istatistikleri deposu: Süre, CPU, mantıksal okuma, bellek gibi ölçümler, sabit zaman aralıklarına toplanmış hâlde.
  • Bekleme istatistikleri deposu: Sorgunun neyi beklediği (kilit, disk, CPU, bellek). Bu boyut SQL Server 2017 ile geldi.

Önemli bir ayrıntı: Query Store, SQL Server 2016, 2017 ve 2019’da varsayılan olarak kapalıdır. SQL Server 2022 ile birlikte yeni oluşturulan veritabanlarında varsayılan olarak açık gelir. Eski bir sürümden taşınan veya yedekten dönülen veritabanlarında açık olduğunu varsaymayın, kontrol edin.

Query Store plan önbelleğinden neden daha kullanışlı?

SQL Server zaten planları bellekteki plan önbelleğinde tutar. Ancak plan önbelleği her sorgu için yalnızca son planı saklar ve bellek baskısında planları siler. Yavaşlamanın nedenini geriye dönük araştırmak için bu yetmez.

ÖzellikPlan önbelleğiQuery Store
Sakladığı planYalnızca son planSorgu başına birden fazla plan ve geçmişi
KalıcılıkBellekte; bellek baskısında ve yeniden başlatmada kaybolurVeritabanının içinde saklanır
Zaman boyutuYok, anlık görüntüZaman dilimlerine göre istatistik
Düzeltme imkânıYokEski planı zorlama (plan forcing)
Bekleme bilgisiSunucu geneliSorgu bazında (SQL Server 2017 ve sonrası)

SQL Server Query Store 6 adımda nasıl kullanılır?

SQL Server Query Store: açık anahtarlı veritabanı çevresinde beş adımlı döngü: bekle, gerileyen sorguyu bul, planları karşılaştır, planı zorla, izle

1. Sürümü ve mevcut durumu kontrol edin

Veritabanında sys.database_query_store_options görünümünü sorgulayın. actual_state_desc ile desired_state_desc farklıysa Query Store kendiliğinden başka bir moda geçmiş demektir; en sık görülen durum, ayrılan alan dolduğu için salt okunur moda düşmesidir. Query Store master ve tempdb için açılamaz; ilgileneceğiniz yer ERP ve uygulama veritabanlarıdır.

2. Query Store’u açın ve ayarlarını iş yüküne göre yapın

SQL Server Management Studio’da veritabanı özelliklerindeki Query Store sayfasından veya şu komutla açabilirsiniz: ALTER DATABASE [VeritabaniAdi] SET QUERY_STORE = ON (OPERATION_MODE = READ_WRITE); Ardından yakalama modunu AUTO yapın, boyuta göre otomatik temizliği açık tutun ve eski verinin ne kadar süre saklanacağını belirleyin. Değişikliği iş saatleri dışında yapın ve sunucudaki boş disk alanını önceden kontrol edin.

3. Veri birikmesini bekleyin

Query Store açıldığı andan itibaren kayıt tutar, geçmişi geriye dönük getirmez. Karşılaştırma yapabilmek için en az bir normal iş gününü, ay sonu raporları gibi yoğun dönemleri de kapsayan veriyi bekleyin. Yavaşlama yaşamadan önce açık olması, olay anında elinizde “önce” verisinin bulunması demektir.

4. Gerileyen ve en çok kaynak tüketen sorguları bulun

Management Studio’da veritabanının altındaki Query Store klasöründe Regressed Queries (gerileyen sorgular), Top Resource Consuming Queries (en çok kaynak tüketenler) ve Query Wait Statistics (bekleme istatistikleri) raporlarını açın. Süreyi, CPU’yu veya mantıksal okumayı ölçüt seçin ve yavaşlamanın başladığı zaman aralığına odaklanın. Bekleme kategorisi kilit ağırlıklıysa sorun plan değil engellemedir; bunun için SQL kilitlenmeleri yazımıza bakın.

5. Planları karşılaştırın ve kök nedeni anlayın

Aynı sorgunun iki planını yan yana açın. Yeni planda indeks arama yerine tablo taramasına geçiş, tahmini ve gerçek satır sayıları arasında büyük fark veya eksik indeks uyarısı varsa nedeni büyük ölçüde bulmuşsunuzdur. İstatistik güncelliği ve parçalanma için SQL Server indeks bakımı rehberimiz yol gösterir.

6. Gerekirse iyi planı zorlayın ve sonucu izleyin

Eski plan açıkça daha hızlıysa Regressed Queries ekranında planı seçip Force Plan deyin veya sp_query_store_force_plan yordamını kullanın. Sonra aynı sorgunun süresini birkaç gün izleyin ve zorlanan planları düzenli kontrol edin: şema değişikliği gibi durumlarda zorlama başarısız olabilir ve SQL Server normal derlemeye döner.

Plan zorlama ne zaman doğru çözüm, ne zaman değil?

  • Doğru olduğu durum: Sorgu aynı, veri ve şema aynı, ama SQL Server yeni ve belirgin biçimde daha yavaş bir plan seçmiş. Zorlama, kalıcı çözüm hazırlanırken kullanıcıları hızla rahatlatır.
  • Yetersiz olduğu durum: Eksik indeks, eskimiş istatistik veya kötü yazılmış sorgu varsa zorlama sadece belirtiyi gizler. Kök nedeni düzeltin, sonra zorlamayı kaldırın.
  • Riskli olduğu durum: Veri dağılımı müşteriye veya şubeye göre çok değişiyorsa tek bir plan bazı parametrelerde iyi, bazılarında kötü olabilir. Zorlamadan önce farklı parametrelerle deneyin.

Logo gibi hazır ERP yazılımlarında sorgu metnini değiştiremeyeceğiniz için Query Store özellikle değerlidir. Genel yavaşlık şikâyetlerinde önce Logo veritabanı yavaşladı kontrol listemizi izleyin.

Query Store kullanırken sık yapılan hatalar

  • Sadece sorun çıkınca açmak: Geçmiş kaydı olmadığı için “önce” ve “sonra” karşılaştırılamaz.
  • Salt okunur moda düştüğünü fark etmemek: Alan dolunca kayıt durur; durumu düzenli izleyin.
  • Zorlanan planları unutmak: Aylar sonra şema veya veri değiştiğinde eski plan yeni sorunun kaynağı olabilir.
  • Yordamları silip yeniden oluşturmak: DROP ve CREATE, sorgunun geçmişini koparır; mümkünse ALTER kullanın.
  • Sürüm yükseltmesinden sonra karşılaştırma yapmamak: Yükseltme öncesi ve sonrası planları Query Store ile kıyaslayın; adımlar için SQL Server sürüm yükseltme rehberimize bakın.

Özet ve Query Store kontrol listesi

  • Kritik veritabanlarında Query Store açık ve okuma-yazma modunda mı?
  • Yakalama modu AUTO ve otomatik temizlik açık mı?
  • Gerçek ve istenen durum düzenli kontrol ediliyor mu?
  • Yavaşlama şikâyetinde ilk bakılan yer Regressed Queries ekranı mı?
  • Zorlanan planların listesi ve nedeni yazılı mı?
  • Kök neden düzeltildikten sonra zorlama kaldırılıyor mu?

Özetle SQL Server Query Store, “neden yavaşladı?” sorusunu tahminden kanıta taşır. ÇAP Teknoloji olarak Query Store’u veritabanlarınızda doğru ayarlarla açabilir, yavaşlayan sorguları birlikte analiz edebilir ve kalıcı çözümleri SQL danışmanlığı kapsamında uygulayabiliriz; iletişim sayfamızdan bize ulaşın.

Sıkça Sorulan Sorular

SQL Server Query Store hangi sürümlerde var?

Query Store SQL Server 2016 ve sonraki sürümlerde bulunur. SQL Server 2016, 2017 ve 2019’da varsayılan olarak kapalıdır; SQL Server 2022 ile yeni oluşturulan veritabanlarında varsayılan olarak açık gelir. Mevcut veritabanlarınızda durumu sys.database_query_store_options görünümüyle kontrol edin.

Query Store performansı düşürür mü?

Query Store sürekli kayıt tuttuğu için bir miktar ek yük ve disk alanı kullanır. Bu yükü yönetmek için yakalama modunu AUTO yapın, boyuta göre otomatik temizliği açık tutun ve en son toplu güncellemeleri kurun. Değişikliği önce yoğun olmayan bir saatte yapıp sunucuyu izleyin.

Plan zorlama kalıcı bir çözüm müdür?

Çoğu zaman değildir. Plan zorlama, SQL Server yeni ve daha yavaş bir plan seçtiğinde kullanıcıları hızla rahatlatır. Eksik indeks veya eski istatistik gibi kök nedenler ayrıca düzeltilmeli, zorlanan planlar düzenli kontrol edilmelidir.

Query Store neden salt okunur moda geçer?

En yaygın neden, Query Store için ayrılan alanın dolmasıdır; bu durumda yeni veri kaydedilmez. Ayrılan boyutu artırarak veya eski veriyi temizleyerek tekrar okuma-yazma moduna alabilirsiniz. Gerçek ve istenen durumu düzenli kontrol etmek bu sorunu erken yakalar.

ÇAP Teknoloji, T.C. Sanayi ve Teknoloji Bakanlığı Teknogirişim Rozeti belgesi