Execution Plan

Merrrhabaaa.

Execution Plan nedir?

Query çalıştırıldığında, sonuç getirilene kadar hangi yollar izlenmiş, ne kadar sürede sonuca ulaşmış, nerede ne kadar oyalanmış gibi cevaplara ulaşabileceğimiz, sorgu yürütme aracıdır.

Örneğin; A şehrinden B şehrine gideceksin. Bir sürü farklı yol var. En kısasını, en az trafik olanı ve en az trafik ışığı olan yolu tercih edersin değil mi? Execution Plan’da bize bu yolu gösteriyor.

Tahmini yol ve kullanılan yol olarak 2’ye ayrılıyor. Anlaşılacağı gibi tahmini olan query çalıştırılmadan nasıl bir yol izleneceğini gösterir, diğer ise çalıştırıldığında hangi yolu izlediğini gösterir. Çok nadir olarak birbirinden farklı yollar gösterirler. SQL, Actual Plan’ları Cache’de saklar ve query tekrar tetiklendiğinde buradaki plana göre işlem yapar(aksi belirtilmedikçe – WITH RECOMPILE). Bu sayede SQL Server her defasında yol arayışına çıkmadan eskiden oluşturduğu yolu kullanacaktır.

Hangi durumlarda plan tekrar oluşturulur?
1-Sorguda referans edilen bir tablo üzerinde yapılan Schema değişliği(kolon eklenmesi çıkarılması gibi)
2-Sorgunun kullandığı indekslerden birinin silinmesi
3-Manuel olarak sp_recompile sistem Stored Procedure ’unun çağrılması
4-Aynı sorgu içinde DDL ve DML işlemlerinin beraber kullanılması gibi işlemler her defasında tekrar Execution planın hesaplanmasına yol açar.
5-Sorgunun kullandığı istatistiklerin değişmesi

6- Sorgunun parametrelerinin değişmesi.
*alıntı.

Actual Execution Plan – (CTRL + M) : (Gerçek kullanılan plan.) Aşağıdaki gibi aktif hale getirdikten sonra query’i çalıştırıp, Execution Plan sekmesinden nerelerde neler yapmış görebilirsin.

actualexecutionplan

actualexecutionplan-2

Estimated Execution Plan – (CTRL + L) : (Tahmini plan) Burada da seçilen alanda CTRL+L kombinasyonu kullanılarak tahmini yollar gözlemlenir.

estimatedexecutedplan
Bir tablo oluştururken Estimated Execution Plan kullanamazsın.

Index konusunda da değindiğim bir alan burada da karşımıza çıkıyor. Execution Plans da aşağıdaki verilere ulaşabileceğini belirtmiştik. Burada Database’in bulunduğu server üzerinde yüklerini azaltmak, daha hızlı yanıt vermesini sağlamak için I/O ve CPU kullanımlarını en aza indirgenecek şekilde query’lerine hayat vermen gereken önemli bir nokta. Tabii bunu her query’inde yap demiyorum ama günde 1 kere yada 100 kere çalışacak yani belli aralıklarla çalıştırılacak query’lerin için bu özelliği kullanman faydalı olacaktır.
indexseek

Peki nasıl düşüreceğim bu I/O ve CPU kullanımlarını?
Bunun için ayrı bir yazı yazarım her halde, yazarsam burayı güncellerim.
Kısaca : Index yapmak, join kullanmak, koşulları index yapılmış alanlardan seçmek ve gerekli değil ise like kullanmamak, faydalı olacaktır.

Planları 3 şekilde çıktı alabilirsin.

    1. Text Plans : Okuması grafik plana göre daha zordur ama daha fazla bilgi içerir.

Kullanım için;
SHOWPLAN_ALL : a reasonably complete set of data showing the Estimated execution plan for the query
SHOWPLAN_TEXT : provides a very limited set of data for use with tools like osql.exe. It too only shows the Estimated execution plan
STATISTICS PROFILE: similar to SHOWPLAN_ALLexcept it represents the data for the Actual execution plan

    1. Graphical Plans : Rahat okunabilir ve algılanabilir biçimdedir, yukarıdaki çıktılar bu tiptedir.
    2. XML Plans : XML şeklinde çıktı verir, bu da farklı alanlarda kullanılabilinecek bir seçenek.

Kullanım için;
SHOWPLAN_XML : The plan generated by the optimizer prior to execution.
STATISTICS_XML : The XML format of the Actual execution plan.

--Oluşturulan planlar
SELECT [cp].[refcounts]
, [cp].[usecounts]
, [cp].[objtype]
, [st].[dbid]
, [st].[objectid]
, [st].[text]
, [qp].[query_plan]
FROM sys.dm_exec_cached_plans cp
CROSS APPLY sys.dm_exec_sql_text ( cp.plan_handle ) st
CROSS APPLY sys.dm_exec_query_plan ( cp.plan_handle ) qp

 

*Detaylı ve esinlenilen bilgi

Leave a Comment.