SQL Server Indeks Kullanımı
İndeks kullanım denetimi kolay bir iş değildir ancak SQL Server performansı için çok kritiktir. Bir indeksle uğraşmak kolaydır ama birçok veritabanındaki yüzlerce indeksle uğraşmak zordur ve uzmanlık ister. Indeks denetimlerinin düzgün yapılması performans artırımı için çok önemlidir. İndeks denetimine başlamak için iki yaklaşım vardır.
Birinci yaklaşım; SQL Server performansına genel olarak etki edebilecek indekslere odaklanarak yani işi küçülterek daha yönetilebilir hale getirmektir. Örneğin çok tablo içeren yoğun bir veritabanında en fazla veri içeren tablolardan başlanıp daha az veri içerenlere doğru devam edilebilir. Bu yolla en çok güç sarf edilen alanlara odaklanılır ve bu da performansa pozitif etki eder.
İkinci Yaklaşım;hatalardan yola çıkma yaklaşımıdır. Bu yöntemle, veritabanındaki tüm indekslerle değil, performans problemi görülen yerlere odaklanılabilir. Eğer veritabanındaki performans problemleri kesin olarak belirlenirse, iyileştirilebilecek indeksler belirlenir ve bunlarla daha fazla ilgilenilebilir. Eğer ilgilenilmesi gerekilen çok sayıda indeks varsa en büyüğünden başlanılabilir. Veritabanı indekslerini denetlemeye karar verildiğinde, bir plan çıkartılmalı ve sistemli bir şekilde uygulanmalıdır.
Veritabanındaki Tüm Tablolar Clustered Indeks İçeriyor mu?
Veritabanındaki tüm tabloların clustered indeks içermesi gerektiği genel bir kuraldır. Clustered indeks her zaman değil ancak genellikle, monoton artan (identity kolon veya arttırılan bir değerle oluşmuş kolon) bir kolon üzerinde olmalıdır ve benzersiz (unique) olmalıdır. Çoğunlukla Primary Key clustered indeks için ideal kolondur. Clustered indeksi primary key olan bir tabloya bir satır ekleniyorsa, her INSERT fiziksel olarak disk üzerinde birer birer gerçekleşecektir. Bu nedenle page splitler gerçekleşmez.Eğer bir çok satır bir heap’ e (Clustered Indeks olmayan tablo) INSERT ediliyorsa, veri monoton olarak artsa da artmasa da data pagelerin üzerine belirli bir sırayla eklemez. Buna göre SQL Server, diskten veriye ulaşırken özellikle okuma yaparken daha fazla çalışmak zorunda kalır. Eğer clustered indeks eklenmiş olsaydı veri data pagelere sırayla eklendiği için daha az disk IO gerçekleşecekti.
Tablodaki Kolonlar Birden Fazla Indekste Bulunuyor mu?
Tabloların güncel indekslerini gözden geçirirken kolonlara ait gereksiz eş (duplicate) indeksler olup olmadığına bakılmalıdır. Eş indeksleri silmek sadece diskte fazladan yer tutulmasını engellemez aynı zamanda veri erişimi ve veri düzenleme işlemlerini (INERT, DELETE, UPDATE) de hızlandırır.Örneğin Primary Key olduğuna dikkat edilmemiş kolon otomatik indekslenmiş farklı bir indeks adı altında tekrarlanmış olabilir.
Kullanılmayan Indeksler Var mı?
Kullanılmayan indeksler de eş indeksler gibi gereksiz disk alanı harcayıp, veri erişimi ve veri düzenleme işlemlerinde performansını azaltırlar.
JOIN Kullanan Tablolarda JOIN Kolonlara Uygun Indeks Var mı?
Tablolarda join olunan kolonların yüksek performansa ulaşması için indekslenmesi önerilir. Optimum JOIN performansı için oluşturulmuş indeksleri denetlemek kolay değildir, tam denetim için veritabanında gerçekleşen tüm JOIN’ leri iyi biliyor olmak gerekir.Programcılar genelde JOIN’ lerde kullanılan Primary Key / Foreign Key ilişkilerini yaratırken, Primary Key kolonlara indeks yaratıldığını ancak foreign key kolonlara otomatik yaratılmadığını ve manuel oluşturmak gerektiğini unuturlar.
Kolondaki Verilerin Benzersizliği Indeks Kullanımı için Yeterli mi?
Tablonun bir veya daha fazla indeks içermesi, SQL Server Query Optimizer’ ın indeks kullanacağı anlamına gelmez. Kullanmadan önce Query Optimizer yararlığını göz önünde bulundurur [3]. Eğer kolon en az %95 oranda benzersiz değilse, genellikle Query Optimizer bu kolondaki non-clustered indeksi kullanmaz. Bu nedenle %95 benzersiz olmayan kolonlara non-clustered indeks yaratılmamalıdır. Örneğin “evet” ve “hayır” bilgilerinden oluşan bir kolon %95 benzersiz olamayacağı için bu kolona yaratılmış indeks kullanılmaz ve performans için uğraşlarımız ters etki yapar.
Indeksler Hangi Sıklıkta Rebuild (yeniden derleme) Ediliyor?
Bir zaman sonra indeksler fragmante olur ve SQL Server bunlara erişmeye çalıştığında zorlanır, performans düşer. Bunun tek çözümü veritabanındaki tüm indeksleri düzenli olarak defragmante etmektir. Amaç, indekslerin defragmante edilip edilmeyeceğine bakmaksızın hangi sıklıkta bu işlemi gerçekleştirilmesi gerektiğini belirlemek olmalıdır. Modifikasyonların hangi sıklıkta yapıldığına ve veritabanı boyutuna bağlı olarak günlük, haftalık, aylık yapılması gerekip gerekmediğine karar verilmelidir.Eğer veritabanında günlük olarak çok fazla modifikasyon oluyorsa daha sık gerçekleştirilmelidir. Eğer veritabanı boyutu çok büyükse rebuild işlemi uzun sürecektir. Defragmante işlemi sırasında fazlaca kaynak kullanılacağı ve kullanıcıların etkileneceği de unutulmamalıdır.
Indekste İdeal Fillfactor Değeri Belirlenmiş mi?
Fillfactor değerinin nasıl belirleneceği uygulamanın SQL Server tablolarına yaptığı okuma yazma oranına bağlıdır. Genel kural şöyledir;
Uygulamanın optimum fillfactor' ünü bulmak için deneyler yapılmalıdır. Az fillfactor’ ün çok fillfactor’ den daha iyi olduğu doğru değildir [6]. Az fillfactor ile splitler azalırken, SQL Server sorgularıyla okunacak pagelerin sayısı artar, performans düşer. Çok az fillfactor ile sadece IO artmaz, buffer cache de etkilenir. Data pageler diskten buffera alınırken boş alanlar dahil tüm pageler taşınır. Düşük fillfactor’ lü data pageler SQL Server buffera taşınırken aynı anda alınan diğer önemli data pagelere daha az yer kalır.Eğer fillfactor belirtilmezse varsayılan fillfactor 0 olur %100 ile aynı anlama gelir, indeks leaf page seviyesi %100 dolar.
Yeni indeksler yaratılırken ve var olan indeksler yeniden derlenirken gerekli fillfactor değerleri belirlenmelidir. Tüm koşullar göz önünde bulundurularak varsayılan değeri 0 verilmemelidir. Onun yerine, boş alan ayıran bir fillfactor değeri verilmelidir.
Kaynaklar:
http://www.microsoft.com/ sqlserver/en/us/default.aspx
http://msdn.microsoft.com/en-us/library/ ms189826(v=sql.90).aspx
İndeks kullanım denetimi kolay bir iş değildir ancak SQL Server performansı için çok kritiktir. Bir indeksle uğraşmak kolaydır ama birçok veritabanındaki yüzlerce indeksle uğraşmak zordur ve uzmanlık ister. Indeks denetimlerinin düzgün yapılması performans artırımı için çok önemlidir. İndeks denetimine başlamak için iki yaklaşım vardır.
Birinci yaklaşım; SQL Server performansına genel olarak etki edebilecek indekslere odaklanarak yani işi küçülterek daha yönetilebilir hale getirmektir. Örneğin çok tablo içeren yoğun bir veritabanında en fazla veri içeren tablolardan başlanıp daha az veri içerenlere doğru devam edilebilir. Bu yolla en çok güç sarf edilen alanlara odaklanılır ve bu da performansa pozitif etki eder.
İkinci Yaklaşım;hatalardan yola çıkma yaklaşımıdır. Bu yöntemle, veritabanındaki tüm indekslerle değil, performans problemi görülen yerlere odaklanılabilir. Eğer veritabanındaki performans problemleri kesin olarak belirlenirse, iyileştirilebilecek indeksler belirlenir ve bunlarla daha fazla ilgilenilebilir. Eğer ilgilenilmesi gerekilen çok sayıda indeks varsa en büyüğünden başlanılabilir. Veritabanı indekslerini denetlemeye karar verildiğinde, bir plan çıkartılmalı ve sistemli bir şekilde uygulanmalıdır.
Veritabanındaki Tüm Tablolar Clustered Indeks İçeriyor mu?
Veritabanındaki tüm tabloların clustered indeks içermesi gerektiği genel bir kuraldır. Clustered indeks her zaman değil ancak genellikle, monoton artan (identity kolon veya arttırılan bir değerle oluşmuş kolon) bir kolon üzerinde olmalıdır ve benzersiz (unique) olmalıdır. Çoğunlukla Primary Key clustered indeks için ideal kolondur. Clustered indeksi primary key olan bir tabloya bir satır ekleniyorsa, her INSERT fiziksel olarak disk üzerinde birer birer gerçekleşecektir. Bu nedenle page splitler gerçekleşmez.Eğer bir çok satır bir heap’ e (Clustered Indeks olmayan tablo) INSERT ediliyorsa, veri monoton olarak artsa da artmasa da data pagelerin üzerine belirli bir sırayla eklemez. Buna göre SQL Server, diskten veriye ulaşırken özellikle okuma yaparken daha fazla çalışmak zorunda kalır. Eğer clustered indeks eklenmiş olsaydı veri data pagelere sırayla eklendiği için daha az disk IO gerçekleşecekti.
Tablodaki Kolonlar Birden Fazla Indekste Bulunuyor mu?
Tabloların güncel indekslerini gözden geçirirken kolonlara ait gereksiz eş (duplicate) indeksler olup olmadığına bakılmalıdır. Eş indeksleri silmek sadece diskte fazladan yer tutulmasını engellemez aynı zamanda veri erişimi ve veri düzenleme işlemlerini (INERT, DELETE, UPDATE) de hızlandırır.Örneğin Primary Key olduğuna dikkat edilmemiş kolon otomatik indekslenmiş farklı bir indeks adı altında tekrarlanmış olabilir.
Kullanılmayan Indeksler Var mı?
Kullanılmayan indeksler de eş indeksler gibi gereksiz disk alanı harcayıp, veri erişimi ve veri düzenleme işlemlerinde performansını azaltırlar.
JOIN Kullanan Tablolarda JOIN Kolonlara Uygun Indeks Var mı?
Tablolarda join olunan kolonların yüksek performansa ulaşması için indekslenmesi önerilir. Optimum JOIN performansı için oluşturulmuş indeksleri denetlemek kolay değildir, tam denetim için veritabanında gerçekleşen tüm JOIN’ leri iyi biliyor olmak gerekir.Programcılar genelde JOIN’ lerde kullanılan Primary Key / Foreign Key ilişkilerini yaratırken, Primary Key kolonlara indeks yaratıldığını ancak foreign key kolonlara otomatik yaratılmadığını ve manuel oluşturmak gerektiğini unuturlar.
Kolondaki Verilerin Benzersizliği Indeks Kullanımı için Yeterli mi?
Tablonun bir veya daha fazla indeks içermesi, SQL Server Query Optimizer’ ın indeks kullanacağı anlamına gelmez. Kullanmadan önce Query Optimizer yararlığını göz önünde bulundurur [3]. Eğer kolon en az %95 oranda benzersiz değilse, genellikle Query Optimizer bu kolondaki non-clustered indeksi kullanmaz. Bu nedenle %95 benzersiz olmayan kolonlara non-clustered indeks yaratılmamalıdır. Örneğin “evet” ve “hayır” bilgilerinden oluşan bir kolon %95 benzersiz olamayacağı için bu kolona yaratılmış indeks kullanılmaz ve performans için uğraşlarımız ters etki yapar.
Indeksler Hangi Sıklıkta Rebuild (yeniden derleme) Ediliyor?
Bir zaman sonra indeksler fragmante olur ve SQL Server bunlara erişmeye çalıştığında zorlanır, performans düşer. Bunun tek çözümü veritabanındaki tüm indeksleri düzenli olarak defragmante etmektir. Amaç, indekslerin defragmante edilip edilmeyeceğine bakmaksızın hangi sıklıkta bu işlemi gerçekleştirilmesi gerektiğini belirlemek olmalıdır. Modifikasyonların hangi sıklıkta yapıldığına ve veritabanı boyutuna bağlı olarak günlük, haftalık, aylık yapılması gerekip gerekmediğine karar verilmelidir.Eğer veritabanında günlük olarak çok fazla modifikasyon oluyorsa daha sık gerçekleştirilmelidir. Eğer veritabanı boyutu çok büyükse rebuild işlemi uzun sürecektir. Defragmante işlemi sırasında fazlaca kaynak kullanılacağı ve kullanıcıların etkileneceği de unutulmamalıdır.
Indekste İdeal Fillfactor Değeri Belirlenmiş mi?
Fillfactor değerinin nasıl belirleneceği uygulamanın SQL Server tablolarına yaptığı okuma yazma oranına bağlıdır. Genel kural şöyledir;
- Az güncellenen tablolar (100-1 okuma yazma oranı): %100 fillfactor
- Çok güncellenen tablolar (Yazma okumadan fazla) : %50- %70
- İkisinin arası : %80- %90
Uygulamanın optimum fillfactor' ünü bulmak için deneyler yapılmalıdır. Az fillfactor’ ün çok fillfactor’ den daha iyi olduğu doğru değildir [6]. Az fillfactor ile splitler azalırken, SQL Server sorgularıyla okunacak pagelerin sayısı artar, performans düşer. Çok az fillfactor ile sadece IO artmaz, buffer cache de etkilenir. Data pageler diskten buffera alınırken boş alanlar dahil tüm pageler taşınır. Düşük fillfactor’ lü data pageler SQL Server buffera taşınırken aynı anda alınan diğer önemli data pagelere daha az yer kalır.Eğer fillfactor belirtilmezse varsayılan fillfactor 0 olur %100 ile aynı anlama gelir, indeks leaf page seviyesi %100 dolar.
Yeni indeksler yaratılırken ve var olan indeksler yeniden derlenirken gerekli fillfactor değerleri belirlenmelidir. Tüm koşullar göz önünde bulundurularak varsayılan değeri 0 verilmemelidir. Onun yerine, boş alan ayıran bir fillfactor değeri verilmelidir.
Kaynaklar:
http://www.microsoft.com/ sqlserver/en/us/default.aspx
http://msdn.microsoft.com/en-us/library/ ms189826(v=sql.90).aspx
Yorumlar
Yorum Gönder