28 Mayıs 2015 Perşembe

MS SQL' DE Estimated Execution Plans İncelemesi

    Merhabalar, Execution plan hakkında internette bazı araştırmalar yaptım ve yeteri kadar türkçe kaynak olmadığını fark ettim. Bundan dolayı bazı yabancı makaleleri inceleyerek dilimin döndüğünce türkçeye çevirdim ve bu konuyu merak edenlere kısa bir özet yazmak istedim.Umarım faydalı olur.

     Estimated Execution Plans'ın kullanım amacı, aslında sorgular çalıştırılmadan önce perfromans kaybını önlemek ve sorgunun nerelerinde sıkıntı olduğunu tespit etmek ve nokta atışı yaparak sorguda iyileştirmeler yapamaya çalışmak diyebiliriz.
    Sorgu çalıştırıldığında aslında 2 ana step yürütülür. Birinci adım da query compile edilir(yani sorgu derlenir.) 2. adım ise planın execute edilmesidir(yani çalıştırılır). SQL SERVER 2005 de query execution plan bize 3 farklı sunum göstermektedir. text, xml ve grafik olarak, ki bunlardan da en çok tercih edilen grafik olarak sunulanıdır. Örneğin yeni bir sorgu penceresi açtığınız zaman SSMS da query seçer Actual Execution Plan çalışıtırıldığında neler olacaktır görelim. Örnek olarak AdventureWorks kullanılmıştır.


   
    Bunun sonucunda aşağıdakileri sırasıyla görebiliriz. ilk olarak execution plan sorgu yığını içinde bulunan her bir sorgu için bize değer döndürür.(Fakat örnekte sadece bir tane sorgu kullanılmıştır.) Execution plan sorguyu üstten alta, sağdan sola doğru incelemeye başlar. Mesela bu execution plan da ilk adım bölge adını ve kimlik sütunlarını dönmek için AK_SalesTerritory_Name indexinde tarama yapmaktadır. Bu adımın sonunda diğer step ile birleşecektir. Sağdan sola çalışmaya devam edecek ve nasted loop iki tabloyu birlikte joinlemek için kullanılır. Sonunda da nested loop'un sonucu SELECT işlemini besler.




    Yukarıdaki resimde de gördüğünüz gibi sorgunun her bir adımdaki maliyeti bize gösterilir. Bu bize dönen sonuç bütün query ile alakalıdır. Bu örnekte AK_SalesTerritory_Name Index de taranan toplam query maliyeti %44'tür. Benzer bir şekilde eğer sorgu yığını çalıştırılırsa, sorgu çalışma maliyeti bütün sorgu yığını ile alakalı olarak gösterilir. Yukarıda görülen her bir ok bağlantıyı temsil eder ayrıca okların kalın olarak gösterilmesi ise her bir satırın sayı miktarı ile alakaladır. Yukarıdaki planda her bir adım incelenip sorguyu optimize etme ve sorun giderme konusunda bize çok yarıdımcı olacaktır. 2. resimde adımların AK_SalesTerritory_Name index taramasının detaylarını açıkça görebilirsiniz. Farklı kolonların bilgileri burada gözükmektedir. Eğer her bir kolonun açıklamasını görmek istersek step'e tıkladıktan sonra SSMS'da özellik menüsünü açmalıyız. Buradan view ve özellik pernceresini SSMS' de seçmeliyiz. Bu kısımda bir çok hesaplanmış değer bize sunulmaktadır.(Örneğin CPU Cost)Buradaki değeleri referans olarak querymizi yapılandırmada kullanabiliriz.


                          Estimated Execution Plans:
    Estimated Execution Plan sorgulardan seçilmiş olanları görüntüler. Aslında gerçekte olan bu sorguların çalıştırılması değildir. Bunun yerine sadece muhtemel olan çalışma maliyeti hesaplanır ve sunulur. Çok daha büyük ve karmaşık sorgular söz konusu olduğu zaman Estimated Execution çok hızlı sonuç döndürecektir. Ayrıca her bir adımın detaylarına baktığınız zaman dönen sonuçların sadece tahmini olduğunu da görebilirsiniz.


    Tahmini değerlerin gösterdiği sonuçlar daima gerçekte gerçekleşenlerle birebir örtüşmez. Çünkü sorgular çalıştırılırken bir çok durum söz konusudur. Örneğin filtrelemeler uygulanırken oluşan maliyet yada satır numaralarının döndürülmesi . Tüm bunlar sorgu çalıştırımadan bilinmeyecektir. Query Engine(Sorgu Motoru) tüm bu muhtemel değerleri istatistiklere dayalı olarak hesaplar.(SQL Server veritabanında saklanan indeks ve sütun verileri hakkında istatistiki bilgiler sağlar.) Eğerki Sql server da istatistiksel hesaplamalar güncel değilse tahminlerin doğruluğu etkilenebilir.Konuda detaylı bilgi edinmek isteyenler linki inceleyebilirler. (http://sqlmag.com/t-sql/making-most-automatic-statistics-updating buradaki yazıdan istatiksel güncelleme hakkında bilgi alabilrisniz.)


    Karmaşık sorgularda geriye dönen çok fazla sayıda satırdan dolayı iki farklı şeye odaklanmak gerekir bunlardan bir tanesi Estimated number of Rows (Tahmini satır sayısı) ve Estimated Subtree Cost . Aslında tahmini satır sayısı zaten kendini isminden dahi açıklıyor.  Estimated Subtree Cost bir işlemin ve onun alt işlemlerinin işlemciye olan kümülatif maliyetleri olarak tanımlanmıştır.


    Sql Server 2005 Book online da yazılanlara göre maliyet ölçümü, "hesaplanan tahimini süre; aslında donanımsal konfigürasyonun  sorguyu tamamlaması gerektiği süredir." Bu tahminler SQL Server developer'lar tarafından test makinelerinde gerçekleşmektedir. Bundan dolayı işlemci maliyetleri hesaplanmasında tahminlerde %100 doğruluk söz konusu değildir. Şunu söylemekte fayda var sorguların  çalıştırımasında geçen süre  ve burada oluşan  performans düşüklüğü yada artışı  donanımsal özellikleriyle oldukça yakından ilgilidir.


    Bir çok farklı sorgu yazıp bunları kendi makinelerinizde tahmini değerleri ve çalıştırıp gerçek değerlerini inceleyin. Bu incelemerden sonra sizde, donanımıza uygun ne tür işlemlerin işlemci maliyetleri açısından kafanızda  bir alt eşik oluşturacaktır.
   

   






4 yorum :

  1. Emeğinize sağlık çok faydalı oldu.

    YanıtlayınSil
  2. Süper bir çalışma olmuş yasin bey

    YanıtlayınSil
  3. Paylaşım için çok teşekkürler.

    YanıtlayınSil
  4. I feel satisfied to read your blog, you have been delivering a useful & unique information to our vision even you have explained the concept as deep clean without having any uncertainty, keep blogging. SQL server dba Online Training

    YanıtlayınSil