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

Yazılım Maliyet Tahmineleme Tecrübeleri

Yazılım mühendisliğinde maliyet hesabı her zaman problem olmuştur. "Bu iş kaç Adam/Gün tutar?" sorusuyla sıkça karşılaşıyoruz. Adam/gün veya Adam/ay ölçütleri bir kaynağın/kişinin belirtilen zaman dilimindeki iş gücü anlamına gelir. Tabi bu noktada yine kafa karışıklıkları başlar. 6 A/G'lik bir işi hızlandıralım diye 2 kişi ile yapmaya çalışsak ve kaynak/kod, modül, altyapı, insan vb. her bir şeyi bir kenara bıraksak, matematiksel basit formülle 6/2=3 A/G'de biter? Gerçek hayat böyle değil, öncelikle bunu anlamamız lazım. Hep şu örnek verilir; "Aynı bebeği 2 kadın birlikte daha kısa sürede doğurur mu?" Eğer bunun cevabı "Evet" ise (veya bir gün böyle bir durum ortaya çıkarsa), yazımı değiştirmem gerekecek:) Mevzu gerçekten derin...Maliyet hesabı; bulunduğunuz firmanın yazılım süreçlerini hangi methodlarla uyguladığına, ilgili işin o dönemdeki aciliyetine, (şirket yönetiminin baskısına:)) vb. bir çok duruma bağlı olabilir. Örneğin; bizim firmada e

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 ve bunlar ara