Parametreli Sorgularda Performans Çalışması

Reading Time: 3 minutes

Bu atölye çalışmamızda parametreli sorgularımızda performans arttırma işlemlerini nasıl gerçekleştirebiliriz bunu öğreneceğiz.

Çoğu zaman parametreli sorgularımız da opsiyonel yani NULL değer alan değişkenlerimizi WHERE bloğunda OR layarak süreci tamamlamak istiyoruz fakat bu tarz sorguların arka tarafa verdiği yükten bi haberiz tabi.

Bu çalışmamızda da esas değinmek istediğimiz nokta tam da burası. Bu tarz sorgular yoğun sistemlerimiz de bize çok büyük maliyet oluşturmakta ve sistemizi aşağı indiriyr bile olabilir.

Klasik sistemlerimizde özellikle müşteirlerimin sistemlerinde genellikle rastladığım kod bloklarından örnek vereceğim ve örneklerimizi AdwantureWorks Db si üzeirnde gerçekleştireceğim.

Bizim 3 parametre alan bir saklı yordamımız yani Stored Procedure ‘ümüz olsun ve NULL bırakılan parametreler dışında geriye kalan parametreler WHERE bloğunda kullanılıyor olsun.Yani sadece değer alan parametrenin Where bloğunda kullanıldığını düşünelim.

Bunun için aşağıda ki Stored Procedure ‘ümüzü hazırlıyoruz.

Hazırladığımız Stored Procedure ‘imizin adı ssp_Personel_Search ‘dir. Stored Procedure lerin bir kez EXEC edildiğinde yani çalıştırıldığında Query planını oluşturup Cache lendiğini biliyoruz. Yani ilk çalıştırmadan sonra oluşturduğu Execution Planı diğer tüm çalıştırmalarda kullanır. Her defasında yeni bir Execution Plan üretmez.

NOT : Query Optimizer Procedure ilk çalıştırıldığında tüm parametreleri baz alarak bir plan oluşturuyor ki daha sonra ki sorgularda kötü bir plan olmamasını önlemk açısından.

Stored procedure ‘ümüzü incelediğimizde 3 parametre almakta ve aldıkları parametreye göre Where bloğunu oluşturmakta.

Örneğimizi daha da detaylandıralım ;

Tablo üzerinde yer alan BusinessEntityID ve EmailPromotion kolonlarına index atalım.

Daha sonra  BusinessEntityID ve EmailPromotion ‘a göre sp_ mizi EXEC ediyoruz ve normal de Execution Planı incelediğimizde Seek yapması gerekirken diğer parametrelerden dolayı Scan işlemi yapmakta.

Stats:

Table ‘Person’. Scan count 1, logical reads 40, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Aynı Query Ad-Hoc olarak yazdığımızda Execution planı incelediğiniz de Seek işlemi yaptığını göreceksiniz.

Stats:

Table ‘Person’. Scan count 0, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Genelde sistemlerimizde yaşadığımız en büyük problem burası. Biz bu problemi nasıl aşarızın cevabı ise Dynamic SQL dir.

Yani ne demek oluyor bu , gönderidiğimiz parametrelere göre sql scriptinin oluşturulması. Aynı sorgumuzun Dynamic halini yazacak olur isek ;

Aynı değerler ile yeni sp_ mizi EXEC edecek olur isek ;

 

Aşağıda da Execution  Planında görüldüğü üzere seek işlemini gerçekleştirmekte.

 

Stats:

Table ‘Person’. Scan count 0, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 

Gördüğünüz üzere sistemlerinizde bu tarz süreçleri inceleyip düzelttiğinizde maaliyetinizi ortadan kaldırmış oluyorsunuz.  Şimdi hepinizin şu soruyu sorduğunu duyar gibiyim, her defasında execution plan mı oluşturuyor diye ! Tabi ki HAYIR .

Her gelen parametre grubu için oluşturulan plan cache leniyor ve bir daha ki çalışmalarında cache den okunuyor. Bunu aşağıda cache lenen query planları bulan scriptimizi çalıştırıp sonucunu incelediğinizde daha net görmüş olacaksınız.

Leave a Reply

Your email address will not be published. Required fields are marked *