1.
Turgay Sahtiyan
Eurobank Tekfen – Veritabanı Yöneticisi
Microsoft MVP – SQL Server

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.
 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.
 + 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.
 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.
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.
 + 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.
 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.
 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.
 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.
 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.
 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.
 İ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.
 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.
 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.
 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.
www.sqlserveronculeri.com
www.turgaysahtiyan.com
turgay@turgaysahtiyan.com