MSSQL Server Query Store Nedir

Bu makalede Sql Server’ın bize sunmuş olduğu Query Store yapısını ele almış olacağız. Şimdi detaylı bir şekilde bu yapının ne olduğu, nasıl aktif edildiği ve parametrelerinin ne olduğunu detaylı bir şekilde ele almış olacağız.

Öncelikle Query Store  Asenkron bir şekilde çalışır ve sisteme herhangi bir yük getirmez.

Query Store yapısı veritabanı bazlı çalışan ve veritabanına gelen sorgulara ait geçmiş bilgileri tutan bir yapı olarak karşımıza çıkmaktadır. Geçmiş dediğimiz kavram sorguların execution planını, okuma yazma bilgilerini, cpu tüketimini, istatistik bilgilerini, hangi sorgunun ne kadar kullanıldığını ve bunun gibi birden fazla işlem için kullanabiliriz.

Veritabanı üzerinde yapılan bazı değişiklikler sorgumuzun zamanla execution planının değişmesine sebebiyet verebilir. Eğer sorgularınızın veritabanından geç cevap alındığına dair bir geri dönüş size varsa bu yapı aktif hale getirilerek sorunu tespit edip sorgularımızı daha hızlı bir yapıya dönüştürebiliriz.

Önemli Not: High Availability yapılarında  biri olan AlwaysOn sisteminde eğer Query Store kullanıyorsanız sisteminin herhangi bir failover anında ikinci sunucuda geç ayağa kalkmasına sebep olabilir. Çünkü  Query Store aktif olan veritabanı ikinci sunucuda da aynı yapıya gelmek isteyecek bunun için bu bilgiler ikinci sunucuda veritabanının çok geç ayağa kalkmasına sebebiyet verebilir.  Traceflag  T7752  failover durumunda query store daki verilerin restoresinin önüne geçer. Dikkat edilemesi gereken bir konudur.

Aşağıdaki komut ile bir veritabanından Query Store yapısının açık olup olmadığını görebiliriz.

select name ,is_query_store_on from sys.databases where is_query_store_on=1

Bu özelliğin aktif edilmesi için veritabanı üzerine sağ tıklanır ve properties kısmına girilir.

Gelen ekranda en altta bulunan Query Store  bölümüne tıklanır. Tüm ön konfigürasyonlar bu ekrandan yapılmaktadır.

Şimdi yukarıdaki bölümlerin en iş yaptığını açıklayalım.

Operation Mode kısmında 3 seçenek karşımıza çıkmaktadır. Biz veritabanı üzerinde hem okunan hem de insert edilen değerlere ait bilgileri toplamak istediğimiz için Read write seçeneği seçilmektedir.

Read write  seçtikten sonra diğer bölümleri default değerlerde bırakmak bile yeterli bence. Sadece yoğun bir sistem kullanıyorsanız Stale Query Threshold kısmında kaydedilen verilerin ne kadar süre sonra kaydedilmemesi gerektiğini belirleyebiliriz. Bu değerin uzun tutulması Max size bölümünde vermiş olduğumuz query store alanının dolmasına sebep olacak Operation Mode otomatik olarak Read only moda geçecektir.  Bu yüzden Stale Query Threshold değerinin 3-5 günlük bir değer verilmesi tercih edilmektedir.

Veritabanızın data file’larının olduğu diskte alan konusunda sıkıntı yoksa Stale Query Threshold değeri artırılabilir. Çünkü Query store kendi veritabanı altında tutulmaktadır.

Data Flush kısmında ki değer de toplanan verinin ne sıklıkla diske yazıldığını belirtir. Makalenin başında da belirttiğim gibi Query Store  Asenkron bir şekilde çalışır ve sisteme herhangi bir yük getirmez.

Statistics Collection Interval: İstatistikleri toplama aralığıdır. Daha düşük bir değer set edilmesi sorunumuzu kısa sürede bulmamıza yardımcı olabilir.

Query Store Capture Mode kısmı, query store’un hangi sorguları yakalayacağını belirler. All tüm sorguların kaydedileceği, none ifadesi hiçbir sorguyu yakalamaz. Sık gelen sorguların sadece yakalanmasını istiyorsak auto seçeneği seçilmelidir.

Size Based Cleanup Mode kısmında, max size limitine yaklaşıldığında otomatik veri temizlemenin otomatik olarak çalışıp çalışmayacağını belirleriz. Default olarak Auto gelir ve böyle bırakmamız tavsiye ediliyor.

Tüm bu değişiklikleri yaptıktan sonra OK tuşuna basarak veya  sol üst tarafta bulunan script kısmına tıklayarak script’ini alabiliriz.

Aşağıdaki resimde Current Disk Usage kısmında sol kısımda bulunan Mavi daire bizim database’in boyutunu sağ taraftaki daire ise Query Store boyutunu göstermektedir. Sağ alt tarafta bulunan Purge Query Data kısmında ise Query Store yapısında  bulunan tüm verileri silebiliriz.

Query Store aktif edilmiş veritabanı altında bu yapının tüm işlemlerini görebiliriz.

Regressed Queries (Gerileyen Sorgular): Daha önce iyi performans gösteren ancak zaman içinde performansı düşen sorguları listeler. Performansı düşen sorguları tespit edip, bu sorguları optimize etmek için kullanılır.

Query id değerindeki her sorgunun sağ tarafında plan id’leri görülmektedir. Burada ilgili planı seçip Force edebiliriz. Query id ile seçilen sorgumuzun execution plan’ını alt kısımda görebiliriz.

Aşağıdaki resimde sağ bölümde bulunan summary for query bölümü sol tarafta seçilen query id planlarının göstermektedir. Query id ve diğer ifadelere göre filtreleme işlemlerini yapabiliriz.

Sağ bölümde seçilen planın execution planı alt tarafta görülmektedir. Ayrıca her bölümün kendine özel filtreleme butonları bulunmaktadır. Sağ üst köşelerinde bulunmaktadır.

Query id bölümünde herhangi bir sorgumuzu seçtiğimizde sorgumuzun genel değerlerini ne kadar çalıştığını maliyetini görebiliriz.

Mecutta bulunan sorgunun cpu, memory ve diğer tüm değerleri Metric kısmından seçip Statistics kısmında toplam değeri max-min değerini seçebiliriz.

Sağ üst köşede bulunan değerleri ne olduğuna değinmek gerekirse: çerçeve içerisine alınmış bölümden arayüz görüntüsünü değiştirmektedir.

Yukarıdaki resimdeki default görüntüden grid format’a dönüştürme işlemini yapabiliriz.

Aşağıdaki resimde çerçeve içerisine alınan bölüme tıklandığında seçtiğimiz sorgunun Tracked Queries(İzlenen Sorgular) yapısını göstermektedir. Database altında da Tracked Queries bulunmaktadır. Buradan geçiş yapılabilir.

İlgili bölüm açıldığında seçtiğimiz plan id’ye özel anlık incelemelerde bulunabiliriz. Çerçeve içerisine alınan bölümden Run denilerek anlık kullanılan plan id’leri görebiliriz. Ayrıca yuvarlak şeklinde olan plan id’lere tıklayınca her plan id’ye özel execution plan görülmektedir.

Sağ bölümde bulunan Configure kısmından filtrelememizi değiştirebiliriz.

Overall Resource Consumption (Genel Kaynak Tüketimi):Veritabanındaki tüm sorguların kaynak tüketimini (CPU, bellek, I/O vb.) genel olarak gösterir. Hangi sorguların en fazla kaynak tükettiğini anlamak ve kaynak kullanımını optimize etmek için kullanılır. Belirli zaman aralığındaki değer göstermektedir. Query store yapısını oluştururken istatistiklerin 1 saat arayla toplanmasından dolayıdır.

Herhangi bir ikonu seçtiğimizde sorgumuzun detaylı bilgileri görülmektedir. Interval start ve ınterval end kısmından hangi zaman diliminde sorgularımızı görebiliriz.

Yukarıda bulunan ikonlardan birine tıkladığımızda bizleri Top Resource Consumers bölümüne yönlendirme işlemi yapmaktadır.

Top Resource Consuming Queries (En Fazla Kaynak Tüketen Sorgular): En fazla CPU, bellek veya I/O kaynağı tüketen sorguları listeler. Performans sorunlarına neden olan sorguları belirlemek ve bu sorguları optimize etmek için kullanılır. Önceki karşılaşılan ekranın aynısı ile karşılaşılmaktadır.

Queries With Forced Plans (Zorlanmış Planları Olan Sorgular): SQL Server tarafından belirli bir yürütme planına zorlanmış sorguları listeler. Zorlanmış planların performansını izlemek ve gerekirse bu planları değiştirmek için kullanılır. Herhangi bir forced yoksa boş ekran dönmektedir.

Queries With High Variation (Yüksek Varyasyon Gösteren Sorgular): Farklı yürütme süreleri veya kaynak tüketimleri gösteren sorguları listeler. Tutarsız performans gösteren sorguları tespit edip, bu sorguları optimize etmek için kullanılır. Aşağıdaki resimde görüldüğü gibi planlarının arasında bir tutarsızlık vardır.

Query Wait Statistics (Sorgu Bekleme İstatistikleri): Sorguların hangi kaynaklar için beklediğini (örneğin, CPU, disk I/O, kilitlenmeler) gösterir. Sorguların neden yavaş çalıştığını anlamak ve bu sorunları gidermek için kullanılır.

Yukarıdaki ilgili bölüme tıklandığında bekleme tipine neden olan sorgunun istatistik değerini görebiliriz.

Tracked Queries (İzlenen Sorgular): Belirli sorguların performansını izlemek için kullanılır. Özellikle kritik sorguların performansını sürekli olarak takip etmek ve bu sorguları optimize etmek için kullanılır.

Query store özelliği açılmış olan bir veritabanında en iyi ön izleme nasıl yapılır. Öncelikle herhangi bir sorgumuzun perfomansı zamanla bozuluyorsa bu sorgu için gerekli olan istatistik ve index yapısına bakılıp öyle karar verilmesi gerekmektedir. Herhangi bir plana sorgumuzu force ettiğimizde sorgu bu plan dahilinde çalışır ama manuel müdahale ettiğimiz için sql server zamanla önceki planımızın daha iyi olduğuna karar verebilir. Force etmede bir sakınca yoktur aslında sql server bize en iyi planları önümüze getirmektedir. Sorgumuzun plan handle değerine baktığımızda parameter sniffing olabilir. Bu sefer ilgili planın silinip tekrardan plan oluşturulması gerekmektedir.

Bu makalede Query Store Yapısını ele almış olduk. Başka bir makalede görüşmek dileğiyle.

“Allah (inkarcılara) “Yeryüzünde kaç sene kaldınız?” diye sorar. Onlar, “Bir gün, ya da bir günden daha az bir süre kaldık. Hesap tutanlara sor” derler. Allah şöyle der: “Çok az bir zaman kaldınız. Keşke bunu (daha önce) bilmiş olsaydınız.””  Mü’minûn 112-114