Ana içeriğe atla

SQL Sorgu Optimizasyonuna Yardımcı Araçlar

Sorgu optimizasyonu yaparken, her değişiklikten sonra performans bilgisini gözlemleme işlemini tekrarlamak gerekir. Bu gözlem, yapılan değişikliğin performansı iyi mi kötü etkilediğini belirlemeye yardımcı olur.
1. Elapsed Time
Bir sorgunun çalışmak için aldığı zaman uzunluğu ‘Elapsed Time’ olarak adlandırılır. Sorgunun tamamlanma süresini birçok şey etkileyebilir. Tamamlanma süresi en iyi değerlendirme ölçüsüdür, çünkü bu değere kullanıcının sorgu çalışırken bekleyeceği zamandır. Tamamlanma süresini görebileceğimiz ilk yer SQL Server Management Studio’ da sorgu penceresidir. Aşağıdaki gibi görülür.
image
Tamamlanma süresini görebileceğimiz diğer seçenek SET STATISTICS komutunu kullanmaktır. Aşağıda bu komut ile çalıştırılmış sorgu ve sonuç penceresi görünüyor. 

image
Yukarıdaki örnekte SELECT deyiminden önce ‘SET STATISTICS TIME ON’ komutunu kullandık. Sonuç penceresinde ‘Elapsed Time’ bilgisi yanı sıra ‘CPU Time’ bilgisi ve PRINT deyiminin değeri bulunuyor. ‘SET STATISTICS TIME ON’ deyimi, her deyimin parse, compile ve execute işlemlerinin aldığı zamanı görüntüler. Bu deyim az sayıda komut çalıştırılacağı zaman faydalıdır. Eğer çok sayıda satır çalıştırılıyorsa okunması zor bir sonuç elde edilebilir.
2. CPU Time
Bir diğer önemli performans ölçümü CPU miktarıdır. Tamamlanma süresini görüntülemek için de kullandığımız ‘SET STATISTICS TIME ON’ komutu ile her deyimin CPU zamanını da görüntüleyebiliriz. Bu CPU tüketimini ölçmek için ilk yöntemdir.
SQL Server CPU tüketimini ölçmek için kullanılan @@CPU_BUSY sistem değişkenini sunar. @@CPU_BUSY sistem değişkeni SQL Server başlatıldığından itibaren olan çalışmak için harcanan süreyi döndürür. Sonuç CPU zaman artışıdır ve tüm CPU için kümülatiftir, böylece aktif tamamlanma süresini aşabilir. @@TIMETICKS değişkeni ile çarpılarak mikro saniye birimine dönüştürülebilir.
Aşağıdaki örnekte döngülerin çalışma süreleri SQL Server CPU miktarının @CPU_BUSY kullanımı ile ölçen yöntem bulunuyor. @@CPU_BUSY değişkeni SQL Server start edildiğinden itibaren serverda sorgu çalıştıran tüm kullanıcıların ve sistem sorgularının CPU miktarını barındırır. Bu yüzden bu yöntem, sistemde bir komut çalıştırsak ve arka planda başka sorgu çalışmıyorsa doğru sonuç verir.
image
Yukarıdaki örnekte görüldüğü gibi 1 ve 2. döngü CPU miktarını milisaniye biriminden hesapladık. Bu sorguyu farklı zamanlarda her çalıştırdığımda farklı sonuçlar alabilirim. SQL Server’ da çalışan diğer işlemler bu metoda etki eder. Bu metot ile aktif CPU kullanımı hesabı çok doğru bir sonuç vermeyebilir ancak aktivitesi az olan bağımsız sistemlerde işe yarar bir yöntemdir.
SQL Server Profiler kullanarak CPU ölçümü yapmak daha kesin bir yöntemdir. Yukarıda çalıştırdığımız sorgunun Profiler görüntüsü aşağıda görüleceği gibi CPU kolonunda Harcanan CPU miktarı bulunur. CPU değerini görüntülemek için SQL: BatchCompleted eventi kullanarak çalıştırmak gerekir. SQL Profiler sabit olarak süreleri milisaniye olarak görüntüler. ‘Tools/Options’ menüsündeki bir seçenek ile mikro saniye olarak görüntülenecek şekilde değiştirilebilir. Bu metot ile örnek sorgumuzdaki her döngünün miktarını değil sorgunun bütünüyle tamamlandığı miktarı elde ederiz.
image
3. I/O Usage
Diğer performans ölçüleri gibi I/O miktarını da çeşitli TSQL deyimleriyle sorgulamak mümkündür. SQL Server’ da 2 çeşit I/O yolu vardır: Logical ve Physical I/O. Logical I/O hafızadaki tampon alandan işlem gören veriden sorumludur. Physical I/O, SQL Server’ ın depolama için kullandığı fiziksel diskten direk olarak veri erişimi ile ilişkili giriş/çıkışlardır. Fiziksel I/O, işlemler daha uzun zaman aldığı için daha maliyetlidir. I/O genel olarak SQL deyiminin performansına tek başına etki eder yani maliyetlidir. Buna göre sorgu tasarlarken oluşacak result set üreten physical ve logical I/O operasyonlarının sayısını küçültmek gerekir.
TSQL deyimleriyle I/O miktarını görüntülemenin ilk yolu, ‘SET STATISTICS IO ON’ deyimini kullanarak I/O istatistiklerini açmaktır. SQL deyiminin sonucuyla birlikte bu bağlantı süresince SQL deyimine karar vermek için kullanılan I/O sayısını çıktı olarak döndürecektir.
image
Yukarıdaki örnek sorguyu çalıştırdığımızda Logical Read 34 Physical Read 3 olarak gerçekleşti. Şimdi aynı sorguyu ikinci kez çalıştırıp aşağıdaki sonuca bakalım:
image
Yukarıda çıkan sonuca göre sorgu ikinci kez çalıştığında TSQL deyiminin sonucunda Logical Read 34 Physical Read 0 olarak görünüyor. Çünkü bu sorgun verileri tutan database pageleri zaten buffer pooldadır. Performans arttırmak için yapılan testlerde tekrarlayan işlemler yapıyorsak, bu I/O miktarını buffer pooldan okuması işlemini ortadan kaldırmalıyız. Bunun için de “DBCC DROPCLEANBUFFERS” komutunu sorgularımızdan önce çalıştırmalıyız. Bu işlem sorguların SQL Server stop start işlemi yapmadan temiz buffer pool ile çalışmasına imkan sağlar.
Serap PARLAK

Yorumlar

  1. Keşke sorguları metin halinde verseydiniz de deneyebilseydik.

    YanıtlaSil
  2. Yorumunuz için teşekkürler.
    Mail adresinizi gönderirseniz sorguları metin olarak gönderebilirim.

    YanıtlaSil
  3. info[at]ufukart.com deneyimlerimi burada paylaşmayı umut ediyorum. Peki Serap, bu uygulamada baz aldığın bir hız var mı? Yada uygulamayı yapmadan öncesi ve sonrası şeklinde mi kıyaslama yapıyorsun.

    YanıtlaSil
  4. Tabi performans dediğimizde ilk akla gelen kriter hızdır ancak uygulamaya göre baz alınacak hız değişebilir. Uygulamada sorgulanan tabloların kayıt durumu, işlem yoğunluğu ve uygulamanın şekline (Rapor, ekran, işlem, vs) göre yeterli gelebilecek süreler vardır. Hız kriteri dışında I/O kullanımı, yani physical ve logical I/O operasyonlarının sayısını küçültmek te uzun vadede önemli kazanç sağlayacaktır.

    YanıtlaSil

Yorum Gönder

Bu blogdaki popüler yayınlar

UML ve Modelleme – Bölüm 4 (Class (Sınıf) Diyagramları)

Bir önceki makalemizde UML modellemede kullanılan ilk diyagram olan Use Case diyagramını incelemiştik. Bu makalemizde nesne tabanlı programlamada kullanılan sınıflar ve sınıfların arasındaki ilişkileri modelleyebileceğimiz diyagramlar olan Class(Sınıf) diyagramlarını inceleyeceğiz. UML’de sınıflar, nesne tabanlı programlama mantığı ile tasarlanmıştır. Sınıf diyagramının amacı bir model içerisinde sınıfların tasvir edilmesidir. Nesne tabanlı uygulamada, sınıfların kendi özellikleri (üye değişkenler), işlevleri (üye fonksiyonlar) ve diğer sınıflarla ilişkileri bulunmaktadır. UML’de sınıf diyagramlarının genel gösterimi aşağıdaki gibidir. Şekil 1. Class Diyagram Şekil1’de görüldüğü üzere bir dikdörtgeni 3 parçaya bölüyoruz. En üst bölüm sınıf adını, orta kısım özellik listesini (üye değişkenler) ve en son kısım, işlev listesini (üye fonksiyonlar) göstermektedir. Çoğu diyagramlarda alt iki bölüm çıkarılır. Genelde tüm özellik ve işlevler gösterilmemektedir. Ama...

Material Design Nedir?

Material Design nedir, ne işe yarar, işimizi nasıl kolaylaştıracak? Şekil 1 - Material Design UI Örneği Material Design, Google tarafından geliştirilen bir tasarım dilidir. 2014’te I/O konferansında Android 5.0 Lollipop ile beraber duyurulmuştur. Temel olarak, kullanıcılara daha kararlı bir arayüz sağlayabilmeyi amaçlıyor. Yeni gelen bu tasarım standartları ile Android uygulamalarındaki uyuşmazlık, tutarsızlık, dokümantasyon eksikliği gibi konulara bir çözüm getirilmiş oldu. Böylece kullanıcılar, daha tahmin edilebilir bir ortamda oldukları için uygulamalar arası geçişlerde zorlanmayacak,  bir uygulamanın nasıl çalıştığını daha çabuk kavrayabilecek ve daha kolay alışabilecekler. Özellikle farklı ekran boyutlarında uygulama geliştirenlerin yaşadıkları problemleri ortadan kaldıracak ve farklı ekran boyutlarını uyumlu hale getiren akıllı arayüz geliştiricilerinin işini bir hayli kolaylaştıracak. Şekil 2 - Işık ve Gölgelendirme Çalışmaları Materi...

UML ve Modelleme – Bölüm 3 (Use Case Diyagramlar)

Önceki iki makalemizde ( 1 , 2 ) UML’e genel olarak değinip ve modellemede kullanacağımız dokuz diyagram hakkında bilgiler vermiştik. Bu makalemizde Use Case diyagramından detaylı bahsedeceğiz. Öncelikle, genel Use case diyagramının tanımını hatırlayalım. “Bir kullanıcı ve bir sistem arasındaki etkileşimi anlatan senaryo topluluğudur.” Ivar Jacobson Senaryo tanımı için der ki: “Aktörle sistem arasında gerçekleştirilen, sonucunda aktöre farkedilir getirisi/ faydası oluşan etkileşimli diyalogdur. ” UML Use Case Diyagramları  sistemin işlevselliğini açıklamak amacıyla kullanılır. Sistemin birbirinden ayrı özelliklerinin detaylarını göstermekten ziyade, Use Case Diyagramlar, tüm mevcut işlevselliği göstermek için kullanılabilir. Buradaki en önemli noktalardan biri,   Use Case Diyagramlar temelde sequence diyagram ve akış diyagramlarından farklıdır. Use Case diyagramlar dört ana elemandan oluşmaktadır. Aktörler , Sistem (Proje kapsamını belirtir) , Use Caseler ...