Query Store Nedir – 1
Bir sorgunun beklenmedik bir şekilde farklı bir Execution Plan çalışması durumu ile karşılaştınız mı? Yada SQL Server sürüm yükseltme sonrasında performans sorunu yaşadınızmı? SQL Server 2016 ile birlikte yeni bir Feature olarak duyurulan “Query Store“, Execution Plan’lardaki değişikliklerle ilgili ve performans sorunlarını gidermenize ve çözmenize yardımcı olabilir.
Query Store çalışan sorguların geçmişini, Execution planlarını ve çalışma zamanı istatistiklerini otomatik olarak yakalar ve Execution Plan’larındaki aksaklıkları bulmanıza, maliyet oluşturan sorguları belirlemenize ve önceden yakalanmış bir Execution Planını kullanmaya zorlamanıza olanak tanır. Ayrıca Query Store’un tüm nimetlerini Azure üzerinde çalışan Azure SQL, Azure SQL Database, Managed Instance ve SQL Server On Managed Instance gibi ortamlarınızda kullanabilirsiniz.
Veritabanlarınızda gerçekleşen Transaction’larınızda yavaş yada gecikmeli olarak tamamlanıyorsa, bu durumun hangi sorgu & sorgulardan kaynaklandığını belirlemek adına Query Store’dan yardım alabilirsiniz. Performans sorununun yavaş bir sorgudan kaynaklandığını tespit ettiğinizde, sonraki adım sebebini bulmaktır. Bu durumu şöyle açıklamak daha yerinde olacaktır. Her performans sorunu Execution Plan’ın değişmesi ile kaynaklanan bir durum değildir. Performanslı çalışan sorgularda bir anda yavaşlama durumu gözlemleniyorsa bunun birçok sebebi olabilir. Kabaca Wait Type başlıklarındandan herhangi bir türde bekleme yada kilitleme durumlarından kaynaklanabilir. Asıl zorluk performans sorununun neden kaynaklandığını bulabilmektir. Genellikle SQL Server’ın kullandığı işletim sistemi kaynakları kullanımında, Execution istatistikleri veya performans geçmişi hakkında bir çıkarımımız yoktur. Aslında Execution Plan’da eski Plan’ın ne olduğu hakkında hiçbir çıkarımımız yoktur. Sorgulamalarımızda yer alan Syntax’da küçük bir değişiklik, veri içeriğinde veya kapsamında bir değişiklik sorgu çalıştırma sürecimizde yeni bir planın oluşmasına sebebiyet verebilir.
Query Store sorgunun kendisini ve Execution Plan bilgilerini, ayrıca kodun çalışma zamanında oluşan Statistics’leri almanıza ve mevcut bir Execution Plan’ı Force etmenize izin vererek sorgularınızın daha optimize çalışmasını sağlar. Query Store sorgu planlarının geçmişini sistemde saklayarak ve her birinin zaman içindeki performansını ve son zamanlarda yavaşlayan sorguları tanımlamanıza olanak tanımaktadır. Query Store kullanımı ile birlikte kazanç sağlayacağımız başlıklara göz atalım;
Regressed Queries
SQL Server’ın 2016’dan önceki sürümlerinde belirli bir planın sadece mevcut sürümünü görebilme durumu olduğundan dolayı Plan’da herhangi bir değişim ve gerileme durumunu görmenin herhangi bir yolu yoktu. “Regressed Queries” raporu ile yakın zamanda gerilediği ve veritabanınızda performans sorunları yaratabilecek sorguları belirlemek için kullanabilirsiniz.
SQL Server Versiyon Yükseltilmesi
SQL Server’da sürüm yükseltme işlemlerinde riski en aza indirmek için COMPATIBILITY_LEVEL ayarını değiştirmeden aynı bırakmaktır. Bu durum sürüm geçişlerinde kendi içinde avantaj ya da dezavantajlara sahip olabilir. Konu Query Store için belirtilmiştir.
Uygulama ve Donanım Değişiklikleri
SQL Server’da sürüm yükseltmenin yanında uygulama ve donanım değişikliklerini test etmek için Query Store kullanabilirsiniz. Süreci anlamak için sorgu toplayabilir ve verileri planlayabilir, gerekli değişiklikleri uygulayabilir ve iş yükünü analiz etmek ve herhangi bir performans gerilemesini belirlemek için Query Store kullanabilirsiniz.
Maliyet Oluşturan Sorguları Bulma
SQL Server’da DMV’leri veya mevcut performans verilerini kullanarak maliyetli sorguları bulabilmemize rağmen, bu yöntemlerin genellikle sınırlaması vardır. Query Store ile eşdeğer bilgileri etmek için sürece karmaşık bir şekilde yaklaşmak gerekiyordu. Query Store bu karmaşayı düzeltir ve belirli bir Execution Plan metriğini temel alarak veritabanınızdaki en pahalı sorguları hızla belirlemenize olanak tanır. Bu bilgilere erişmek için SQL Server Management Studio’da Query Store klasöründe bulunan “Top Resource Consuming Queries” raporunu kullanabilirsiniz.
Ad Hoc Query’lerin Tespit Edilmesi
Query Store’u, çok nadiren bir kez yürütülen çok sayıda farklı sorguyla edilen geçici iş yüklerini belirlemek için kullanabilirsiniz. Ad Hoc Query’lerde sistem kaynaklarının önemli bir bölümünü sorgu optimizasyonuna harcar ve plan önbelleğinde büyük miktarda kaynak kullanır.
Query Store’un Yapısı
Query Store, Query Processor (Sorgu işlemcisi) ile doğrudan etkileşime girer. Resim 1’de gösterildiği gibi, SQL Server bir sorguyu her derlediğinde veya yürüttüğünde, Query Store’a bir mesaj gönderilir.
Daha fazla detay için Resim 2’ye göz atabilirsiniz.
Sorgunun derlenmesi ve çalıştırılması ile alakalı adımlar şu şekildedir:
- Amacını gerçekleştirmesi için SQL Server’a bir sorgu gönderildiğinde, SQL Server plan önbelleğinde mevcut bir yürütme planını bulmaya çalışacaktır.
- Herhangi bir plan bulunamazsa, sorgu derleme ve optimizasyon sürecini çalıştırmaya devam edecektir. Bir yürütme planı oluşturulduktan sonra, sorgu metnini ve sorgu planını Query Store’a gönderir.
- Sorgu, Query Store’da mevcut bir planı kullanacak şekilde yapılandırılmışsa, sorgu için Force Plan’da sağlanan bilgileri kullanarak bir plan oluşturmaya çalışır.
- Önceki üç maddede herhangi birinin ardından (önbellekte bulunan plan, yeni optimizasyon veya Force plan), sorgu işlemcisi yeniden derlemenin gerekip gerekmediğini kontrol eder.
- Yeniden derleme işlemi sırasında yeni bir plan oluşturulursa, yine sorgu işlemcisi sorgu metnini ve yeni sorgu planlarını Query Store’a gönderir. Aynı sorgu için tüm sorgu planları, MAX_PLANS_PER_QUERY yapılandırma seçeneği tarafından tanımlanan değer eşiğine kadar kadar plan Query Store’da tutulacaktır.
- Bir plan seçildiğinde ve yürütüldüğünde, sorgu işlemcisi çalışma zamanı yürütme istatistiklerini Query Store’a gönderir.
Optimizasyon ve yürütme bilgileri, Query Store’un yapılandırmasına bağlı olarak önce bellekte tutulur ve ancak daha sonra diskte kalıcı olur. Veriler, varsayılan olarak bir saat olan INTERVAL_LENGTH_MINUTES parametresine göre toplanır ve DATA_FLUSH_INTERVAL_SECONDS parametresine göre diske boşaltılır. Sistemde RAM için darboğaz varsa, veriler daha önce diske aktarılabilir. Her durumda, verileri her iki kaynaktan almak için tasarlandığından, sys.query_store_runtime_stats System View’i çalıştırdığınızda, hem bellekteki hem de diskteki tüm verilere erişebileceksiniz.
Kaynakça