sql server performans İpuçları
Post on 14-Jun-2015
5.331 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related