SQL Server Performans İpuçları

Turgay SahtiyanEurobank Tekfen – Veritabanı YöneticisiMicrosoft MVP – SQL Server

Konuşmacı : Turgay Sahtiyan

SQL Server DBA – Eurobank TekfenKonuşmacı/Yazar/Lider - SQL Server

ÖncüleriE-mail : turgay@turgaysahtiyan.comBlog : www.turgaysahtiyan.com

10+ WebcastMS Technet Türkiye - WhitepaperSQLPass Turkey Chapter LeaderMicrosoft MVP – SQL Server

1 - FILLFACTOR – PAD_INDEX

Index sayfalarında bırakılacak boş yeri belirlemek için kullanılır

Amaç fragmantasyonu engellemek&geciktirmektir

FILLFACTOR : Leaf Level PAD_INDEX : NonLeaf Level Sayfa sayısının artmasına neden olur

www.turgaysahtiyan.com/post/Indexe28099lerde-FILLFACTOR-ve-PAD_INDEX-Secenekleri.aspx

2 - Filtered Index + SQL Server 2008 Where komutu ile Index’in alt kümesi Avantajları

Sorgu performansını arttırır Filtered Stats

Bakım maliyetlerini düşürür Disk maliyetini düşürür

Filtered Index’te desteklenen özellikler Filtered Index’in kriteri değiştirilebilir. Missing Index DMV’leri Filtered Index önerisi

toplamaz. Database Engine Tuning Advisor “not null” Filtered

Index önerisi sunabilir. Filtered Index, online Index operasyonunu destekler. Table Hint’ler Filtered Index tarafından desteklenir.

http://www.turgaysahtiyan.com/post/Filtered-Index.aspx

3 – Indexed View

Indexed View’ler dönecek kayıt seti veritabanında tutulur.

Indexed View’ler bütün SQL Server sürümlerinde bulunur.

Otomatik olarak kullanılabilmeleri için Enterprise sürümü gerekir.

OLAP sistemleri için idealdir. Bazı ön şartları bulunmaktadır.http://www.turgaysahtiyan.com/post/OLAP-Sistemlerde-Indexed-View-ile-Sorgu-Performansc4b1nc4b1-Arttc4b1rc4b1n.aspx

4 - Filtered Index vs Indexed ViewFiltered Index Indexed View

Bir ya da birden fazla kolon için oluşturulabilir.

Bir ya da birden fazla kolon için oluşturulabilir.

Bir tablo üzerine oluşturulabilir.Birden fazla tabloyu içerecek şekilde oluşturulabilir.

SQL Server’ın bütün sürümlerinde kullanılabilir.

SQL Server’ın bütün sürümlerinde oluşturulabilir ve sorgularda view kullanılarak index kullanılabilir. Sorguda view kullanılmadan index’in kullanılabilmesi için Enterprise sürümü gerekir.

Unique olmayan Filtered Index oluşturulabilir.

Indexed View’ler Unique olmak zorundadır.

Tüm sistemler için idealdir. Genelde OLTP sistemlerinde kullanılması tavsiye edilmez. OLAP sistemler için daha uygundur.

Filtre olarak sadece çok basit (IS IS NOT = <> != > >= !> < <= !<)) operatörler kullanılabilir.

Filtre olarak herhangi bir sınırlama yoktur. Kompleks filtreleme yapılabilir.

Online olarak Rebuild yapılabilir Online olarak Rebuild yapılamaz.

http://www.turgaysahtiyan.com/post/Filtered-Index-ile-Indexed-View-Arasc4b1ndaki-Farklar-(Filtered-Index-vs-Indexed-Views).aspx

5 - NC Index’lerde Included Kolon Kullanımı

+ SQL Server 2005 Amaç sorguyu cover edip lookup yapmamaktır. Covering Index : Lookup yapma ihtiyacı olmadan

istenen tüm bilgileri leaf level page’lerinde bulunduran NonClustered Index’lerdir.

Included kolonlar sadece Leaf Level Page’lerde bulunur.

Composite Index25.21 MB

% 1Included Column Index

25.02 MB

http://www.turgaysahtiyan.com/post/SQL-Servere28099da-Index-Kavramc4b1.aspx

6 – Index Seek : PT Bitti mi?

http://www.turgaysahtiyan.com/post/Index-Seek-Performance-Tuning-Bitti-mi.aspx

Index Seek – Index Scan Index Seek Performance Tuning’de son

adım mı?

7 – Where Bloğunda Case Kullanımı

Case kullanımı yanlış Estimated Rows hesabına neden olur.

Dolayısıyla optimal olmayan Query Plan oluşturulur.

Bu durum da gereksiz IO kullanımından dolayı performans sıkıntısı doğurur.

http://www.turgaysahtiyan.com/post/Where-Blogunda-Case-Kullanmayc4b1n.aspx

8 – Where Bloğunda Collate Kullanımı

Collate kullanımı veriyi manupule eder. Veri manupule olduğu için index key’in

sıralaması değişebilir. Bu yüzden Index Seek yerine Index Scan

yapılması zorunluluğu doğar.

http://www.turgaysahtiyan.com/post/Collate-Kullanc4b1mc4b1-Index-Scan-Yapc4b1lmasc4b1na-Neden-Olur.aspx

9 – Eksik Index (Missing Index) Analizi Missing Index’lerin sorgulanması ve create edilecek

index’e karar verilmesi. Create edilmesi düşünülen index’in ve bulunduğu

tablonun analizi (Kayıt sayısı, diğer indexler-kolonlar vs.)

Tablonun query stats’larına bakılıp ilgili missing index’e sebep olan script’in bulunması.

Bulunan script’in şu anki IO değerlerinin sorgulanması. Index’in create edilmesi Sorgunun IO değerine tekrar bakılması ve ne kadar

düştüğünün incelenmesi. Create edilen index’in kullanım istatistiklerinin

monitor edilmesi

http://www.turgaysahtiyan.com/post/SQL-Server-e28093-Eksik-Indexe28099lerin-%28Missing-Index%29-Belirlenip-Olusturulmasc4b1-Operasyonu.aspx

10 – Index Maintenance

DML işlemleri sonucu Index’ler fragmante olurlar.

Belirli periyotlarla Index Fragmantasyonları analiz edilmelidir.

Fragmante olan Index’ler Rebuild ya da ReOrganize edilmelidir. >%5 - <%30 ise ReOrganize >%30 ise Rebuild

Çok hızlı fragmante olan Index’ler de FILLFACTOR değeri düşürülebilir

http://www.turgaysahtiyan.com/post/SQL-Server-e28093-Index-Maintenance-%28Index-Defragmentation%29.aspx

11 – İstatistiğin Güncel Olmasının Önemi

İstatistik, sorgu planı hazırlanırken hangi Index’e hangi yöntem ile erişileceğini belirlemek için kullanılır.

Tablodaki kayıtların dağılımını içerir ve sorgu çalıştırılmadan kaç kaydın döneceğini tahminler.

İstatistik delete-insert-update modifikasyon işlemleri ile güncelliğini yitirir.

Doğru tahminleme yapabilmek için istatistiğin güncel olması çok önemlidir.

http://www.turgaysahtiyan.com/post/SQL-Servere28099da-Istatistik-(Statistic)-Kavramc4b1.aspx

12 – Optimize For Ad Hoc Workloads

Query Planlar daha sonra kullanılmak üzere Plan Cache’de saklanır.

Hem SP gibi parameterize olabilen sorgular için hem de Ad-Hoc sorgular için Query Plan saklanır.

Ad-Hoc sorgularında parametre her değiştiğinde farklı bir plan saklanır.

Çok fazla Ad-Hoc sorgu sahibi ortamlarda memory gereksiz yere işgal edilir.

Optimize For Ad Hoc Workloads parametresi, ilk kez çalışan Ad-Hoc sorguların sadece belirli bir kısmını saklamak için kullanılır.

http://www.turgaysahtiyan.com/post/SQL-Server-e2809coptimize-for-ad-hoc-workloadse2809d-Parametresi-ile-Memorye28099i-Daha-Randc4b1manlc4b1-Kullanmak.aspx

13 – Instant File Initialization Auto Growth ya da Restore gibi dosya allocate

etme işlerinin daha hızlı yapılmasını sağlar. Dosya allocate edilirken 0’lar ile doldurulmaması

içindir. Sadece data dosyalarında işe yarar. SQL Server servis hesabının Perform Volume

Maintenance Tasks’a eklenmesi gerekir. Ekleme yapıldıktan sonra servis restart

edilmelidir.

http://www.turgaysahtiyan.com/post/Restore-Islemleriniz-Cok-mu-Uzun-Suruyor-%28Instant-File-Initialization%29.aspx

İşlem Boyut Süre 1 Süre 2

Veritabanı Oluşturma 20 GB 6 dakika 3 saniye

Restore 240 GB 1.5 saat 37 dakika

14 – Veritabanı Dosya Büyümeleri Auto Growth özelliği ile veritabanı dosyaları

otomatik olarak büyütülür. Default büyüme değeri data dosyaları için 1 MB’dır Bu şekilde çok fazla sayıda büyüme ihtiyacı

olabilir. Bazı durumlarda büyümeler 1-5 sn arası sürebilir. Büyüme süresince ilgili dosyadan okuma ve yazma

yapılamaz. Bu yüzden büyümelerin daha büyük miktarlarda

(512 MB,1024 MB vs.) yapılması daha iyidir. Büyümelerin DBA kontrolünde sistemin en boş

anında yapılması best practice’dirhttp://www.turgaysahtiyan.com/post/Veritabanc4b1-Otomatik-Buyumeleri-Kontrolunuz-Altc4b1nda-Olsun-%28Database-Auto-Growth%29.aspx

Daha Fazlası İçin :

www.sqlserveronculeri.comwww.turgaysahtiyan.com

turgay@turgaysahtiyan.com