Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

SQL Server Performans İpuçları

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Chargement dans…3
×

Consultez-les par la suite

1 sur 17 Publicité

SQL Server Performans İpuçları

Télécharger pour lire hors ligne

FILLFACTOR – PAD_INDEX
Filtered Index
Indexed View
Filtered Index vs Indexed View
NC Index’lerde Included Kolon Kullanımı
Index Seek : PT Bitti mi?
Where Bloğunda Case Kullanımı
Where Bloğunda Collate Kullanımı
Eksik Index (Missing Index) Analizi
Index Maintenance
İstatistiğin Güncel Olmasının Önemi
Optimize For Ad Hoc Workloads
Instant File Initialization
Veritabanı Dosya Büyümeleri

FILLFACTOR – PAD_INDEX
Filtered Index
Indexed View
Filtered Index vs Indexed View
NC Index’lerde Included Kolon Kullanımı
Index Seek : PT Bitti mi?
Where Bloğunda Case Kullanımı
Where Bloğunda Collate Kullanımı
Eksik Index (Missing Index) Analizi
Index Maintenance
İstatistiğin Güncel Olmasının Önemi
Optimize For Ad Hoc Workloads
Instant File Initialization
Veritabanı Dosya Büyümeleri

Publicité
Publicité

Plus De Contenu Connexe

Les utilisateurs ont également aimé (20)

Publicité

Plus récents (18)

SQL Server Performans İpuçları

  1. 1. Turgay Sahtiyan Eurobank Tekfen – Veritabanı Yöneticisi Microsoft MVP – SQL Server
  2. 2. SQL Server DBA – Eurobank Tekfen Konuşmacı/Yazar/Lider - SQL Server Öncüleri E-mail : turgay@turgaysahtiyan.com Blog : www.turgaysahtiyan.com 10+ Webcast MS Technet Türkiye - Whitepaper SQLPass Turkey Chapter Leader Microsoft MVP – SQL Server
  3. 3.  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
  4. 4.  + 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
  5. 5.  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
  6. 6. Filtered Index Indexed View Bir ya da birden fazla kolon için oluşturulabilir. Bir ya da birden fazla kolon için oluşturulabilir. Birden fazla tabloyu içerecek şekilde Bir tablo üzerine oluşturulabilir. 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 = <> Filtre olarak herhangi bir sınırlama yoktur. != > >= !> < <= !<)) operatörler kullanılabilir. 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
  7. 7.  + 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. %1 Composite Index Included Column Index 25.21 MB 25.02 MB http://www.turgaysahtiyan.com/post/SQL-Servere28099da-Index-Kavramc4b1.aspx
  8. 8.  Index Seek – Index Scan  Index Seek Performance Tuning’de son adım mı? http://www.turgaysahtiyan.com/post/Index-Seek-Performance-Tuning-Bitti-mi.aspx
  9. 9.  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
  10. 10.  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
  11. 11.  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
  12. 12.  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
  13. 13.  İ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
  14. 14.  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
  15. 15.  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. İş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 http://www.turgaysahtiyan.com/post/Restore-Islemleriniz-Cok-mu-Uzun-Suruyor-%28Instant-File- Initialization%29.aspx
  16. 16.  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’dir http://www.turgaysahtiyan.com/post/Veritabanc4b1-Otomatik-Buyumeleri-Kontrolunuz-Altc4b1nda- Olsun-%28Database-Auto-Growth%29.aspx
  17. 17. www.sqlserveronculeri.com www.turgaysahtiyan.com turgay@turgaysahtiyan.com

×