Ana içeriğe atla

SQL Server Performans İpuçları - 2

Geçici (Temp) Tablolar Gerek Olmadığı Halde Kullanılıyor mu?
Geçici tablolar pratik bir kullanım sağlarken duruma göre fazla yük de getirebilirler. Yükten kurtarmak ve performansı iyileştirmek için geçici tablo kullanımını kaldıran farklı yöntemler kullanılabilir:

  • İhtiyacı giderecek sorguyu standart sorgular veya stored procedure kullanarak yeniden yazmak
  • Tablo veri tiplerini kullanmak 
  • İlişkili alt sorgular kullanmak 
  • Reel tablolar kullanmak. 
  • Geçici tabloya benzeyen UNION deyimleri kullanmak.

Stored Procedure Kullanılmış mı?
Stored procedure (SP)’ ler yazılımcılara ve sisteme birçok fayda sağlarlar. Network trafiğini ve bekleme süresini azaltıp uygulama performansını arttırırlar. Örneğin network üzerinde 500 satır TSQL göndermek yerine, daha hızlı çalışacak ve daha az kaynak kullanacak bir SP çalıştırma isteği göndermek yeterlidir. Ayrıca, SQL Server ara bellekte tutulan SP çalışma planları yeniden kullanılabilir.

İstemci uygulama taleplerinde SP kullanımı daha verimlidir. Örneğin, uygulamanın image tipinde veri kolonuna, SP kullanmadan büyük bir binary değer INSERT edilmesi gerekiyorsa, bu binary değeri karakter stringe dönüştürüp SQL Server’ a göndermesi gerekir. SQL Server bu değeri aldığında yeniden binary değere dönüştürerek sistem kaynaklarını verimsiz kullanmış olur. SP kullanımı bu sorunu elimine eder ve uygulamalardan parametre olarak binary değer göndermek mümkündür.SP’ ler T-SQL kodunun yeniden kullanımına yardımcı olurlar. Bu durum direk uygulama performansını arttırmaz, kod miktarını ve debug süresini azaltarak yazılımcıların verimliliğini arttırır.


T-SQL Dinamik Sorgu Çalıştırma Komutu Kullanılıyor mu? 
Eğer dinamik bir T-SQL sorgu çalıştırılması gerekiyorsa, EXECUTE komutu yerine sp_executesql prosedürü kullanılmalıdır. Sp_executesql komutu iki temel avantaja sahiptir. Birincisi, kod yazarken daha fazla seçenek yaratan parametre kullanım desteği olmasıdır. İkincisi, SQL Server tarafından yeniden kullanılmak üzere çalışma planı (execution plan) yaratıyor olmasıdır. Bu da performans arttırmaya yardımcı olur.


Referential Integrity Kullanımları
Veritabanında gereksiz referential integrity olmamalıdır. Örneğin, referential integrity uygulamak için primary key ve foreign key kullanılıyorsa, aynı amacı gerçekleştirecek gereksiz trigger eklenmemelidir. Yine aynı işi yapacak constraints,/defaults veya constraints /rules kullanımları gereksiz yük getirecektir.

WHERE Deyimi Sargable mı veya İyileştirilebilir mi? 
Sargable Deyimi, WHERE deyiminde sabit bir değerin bir kolonla karşılaştırılmasını işaret eden, "Search ARGument" kelimelerinden oluşan SARG kısaltmasından gelir. Eğer bir WHERE deyimi sargable ise sorgunun hızlı tamamlanmasını sağlayacak indeks avantajı var demektir [3]. Eğer WHERE (veya bir parçası) non-sargable bir deyim ise indeks avantajından yararlanılmaz ve table scan (tüm tabloyu tarama) işlemi gerçekleşir, bu da sorgu performansının düşmesine neden olur.

WHERE deyimlerindeki "IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", ve "LIKE '%500'" gibi non-sargable arama argümanları genellikle (her zaman değil), arama gerçekleştirecek indeks kullanımına engel olurlar. Ek olarak, üzerinde bir fonksiyon bulunduran kolonların kullanıldığı deyimler, operatörün iki tarafında da aynı deyimi bulunduran deyimler, kolona dayalı karşılaştırmalar içeren deyimler non-sargable deyimlerdir.Non-sargable deyimler içeren WHERE cümleleri her zaman tablo tarama yapmayabilirler. Eğer WHERE cümlesi hem sargable hem non-sargable deyimler içeriyorsa, en azından sargable deyim için indeks kullanılır ve verinin hızlıca alınmasına yardımcı olur. Çoğu koşulda, tablo üzerinde sorgunun SELECT, JOIN, WHERE deyimlerindeki tüm kolonları içeren covering indeks varsa, WHERE deyimi non-sargable olsa bile tablo tarama yerine covering indeks taraması kullanabilir. Unutulmamalıdır ki covering indeksin de, okuma yaparken disk IO arttırma gibi indeks üretim tarafında dezavantajları vardır. Eğer WHERE deyiminin sargable olup olmadığı bilinmiyorsa, sorgu çalışma planı ile indeks kullanıp kullanmadığı kontrol edilebilir.

Sargable Operatörler:
  • =
  • <
  • >
  • <=
  • >=
  • EXISTS
  • IS
  • IN
  • BETWEEN
  • LIKE 'abc%'

Non-Sargable Operatörler:
  • IS NULL
  • <>
  • !=
  • !>
  • !<
  • NOT
  • NOT EXISTS
  • NOT LIKE
  • LIKE '%abc'
  • LIKE '%abc%'
  • kolon1=kolon1

Eğer NOT IN içeren bir sorgu varsa performans düşüşüne neden olur çünkü Query Optimizer bu aktiviteyi yerine getirmek için tüm tabloyu tarar. NOT IN yerine şu seçeneklerden biri kullanılabilir:
  • EXISTS veya NOT EXISTS kullanmak 
  •  IN kullanmak 
  •  LEFT OUTER JOIN gerçekleştirmek ve NULL durumunu kontrol etmek



 Eğer T-SQL deyiminde IN ve EXISTS arasında seçim yapma şansı varsa EXISTS kullanılmalıdır. Çünkü EXISTS daha randımanlı ve hızlı gerçekleşir.Eğer WHERE deyiminde IN veya OR kullandığımız zaman SQL Server indeks taraması yerine tablo tarama kullanıyorsa, indeks hint kullanarak Query Optimizer indeks kullanılacak duruma getirilebilir.

SELECT * FROM tblTaskProcesses WHERE nextprocess = 1 AND processid IN(8, 32, 45) 
Yerine  
SELECT * FROM tblTaskProcesses (INDEX =IX_ProcessID)WHERE nextprocess = 1 AND processid IN(8, 32, 45)  gibi.


WHERE deyiminde IN veya BETWEEN kullanımı arasında seçme şansı varsa, BETWEEN kullanılması performans artışı sağlayacaktır.Mümkünse T-SQL kodunda string concat (birleştirme) işlemlerinden kaçınılmalıdır çünkü çok hızlı işlemler değillerdir ve uygulama performansının genelini düşürürler.Sorgunun WHERE deyimi OR operatörü içeriyorsa ve OR operatörünün referans aldığı kolonlardan biri indeksli değilse (veya kullanışlı bir indeksi yoksa) Query Optimizer bir tabloyu tamamen tarayabilir veya clustered indeks üzerinden tarama gerçekleştirebilir. Bu yüzden eğer birçok sorguda OR ifadesi kullanılıyorsa, referans gösterilen kolonların yararlı indeksleri olup olmadığından emin olunmalıdır.


Bir sorgu bir veya daha fazla OR deyimi içeriyorsa, performansı arttırmak için bazı koşullarda UNION ALL deyimleri birleşiminden oluşan seri ile yeniden yazılabilir.

Örneğin
 SELECT employeeID, firstname, lastname FROM names WHERE dept = 'prod' OR city = 'Orlando' OR division = 'food' 

Üç koşul ile ayrılan bu sorgunun indeks kullanabilmesi için OR yerine UNION ALL ile yeniden yazılması gereklidir: 


SELECT employeeID, firstname, lastname FROM names WHERE dept = 'prod'  
UNION ALL 
SELECT employeeID, firstname, lastname FROM names WHERE city = 'Orlando'  
UNION ALL  
SELECT employeeID, firstname, lastname FROM names WHERE division = 'food' 

Eğer uygulamada çok sayıda, CHAR ve VARCHAR kolon üzerinde genel arama karakterli (LIKE %) tekst arama yapılıyorsa, SQL Server Full Text Search seçeneğini kullanılması önerilir. Search Service, veritabanındaki aramayı önemli derecede hızlandırabilir.


 Kaynaklar:
SQL Server: http://www.microsoft.com/ sqlserver/en/us/default.aspx 
 http://msdn.microsoft.com/en-us/library/ ms189826(v=sql.90).aspx 

Yorumlar

Bu blogdaki popüler yayınlar

PAYTR SANAL POS ASP.NET C# Entegrasyonu

merhaba, bu makalede sizlere PAYTR Sanal pos yapısını .NET üzerinde nasıl çalıştıracağımız ile ilgili bilgi aktarmaya çalışacağım. Ücretsiz başlangıç sağlaması ve sabit ödeme almaması sebebiyle düşük bütçeli e-ticaret yapmak isteyen kişilerin tercih ettiği PAYTR Sanal pos entegrasyonu temelde PHP üzerine kurulmuş. Dolayısıyla .net ile e-ticaret yazmaktaysanız bu sizi bir hayli zorluyor zira firma ile birçok görüşme yapmama rağmen sağlıklı bir .net örneklemesi bulamadım. Baktım olacak gibi değil, sonunda oturdum kendi entegrasyonumu kendim yazdım :). aşağıda detaylı olarak bulabilirsiniz. //using satırlarımızı ekleyelim; using Newtonsoft.Json.Linq; using System; using System.Collections.Generic; using System.Collections.Specialized; using System.Data; using System.Linq; using System.Net; using System.Security.Cryptography; using System.Text; using System.Web; using System.Web.Script.Serialization; using System.Web.UI; using System.Web.UI.WebControls; //aşağıdaki sabit PAYTR Fonksiyon

ASP.NET Sayfalar arası veri taşıma işlemleri

merhaba; bu yazımda sizlere asp.net üzerinde sayfalar arasında veri taşıma işlemlerinden bahsetmek istiyorum.hepimizin bildiği gibi uygulamarımızda sayfalarımız arası haberleşmeler büyük önem arzetmektedir.bazı sayfalarda bazı işlemlerin yerine getirilebilmesi için diğer sayfalardan gelecek verilere ihtiyaç duyulabilir(GET).ASP.NET üzerinde veri taşıma işlemleri aşağıdaki şekillerde yapılabilir. 1-)QueryString : en yaygın ve basit kullanıma sahip olanıdır.istenilen verileri sayfayı post ettiğiniz zaman yönlendirildiğiniz sayfaya URL üzerinden taşır. Kullanımı : a sayfasından b sayfasına isim taşıyalım. a sayfasında linkinizi şu şekilde değiştirirseniz: Response.Redirect("gidileceksayfa.aspx?isim=can"); Tarayıcınızın URL kısmına baktığınızda: www.siteadi.com/b.aspx?isim=can olarak görürsünüz.a sayfasından veri aktarımı tamamlanmıştır.bundan sonraki adım b sayfasından gelen veriyi almaktan ibarettir.o da şu şekilde yapılır: b sayfasında "isim" adında b

ASP.NET - Aynı anahtara sahip bir girdi zaten var.

Eğer ASP.NET ile uğraşırken böyle bir hata aldıysanız aşağıdaki paragraf tam size göre; " Aynı anahtara sahip bir girdi zaten var."  hatasının sebebi sayfanızdaki birden çok nesne için  ClientIDMode Özelliğini " Static " olarak ayarlamanızdan kaynaklanmaktadır.Normal şartlarda sayfa içerisindeki her kontrolün ID si birbirinden farklı olmalıdır.bu tanımı düzelttiğinizde sorununda çözüldüğünü göreceksiniz.Burdaki problem şu ki visual studio hatayı farklı satırlarda veriyor.buda özellikle ilk defa böyle bir hata ile karşılaşıyorsanız çözümü inanılmaz zorlaştırıyor.