Mustafa Bektaş Tepe

Oracle veritabanı ilk piyasaya sürüldüğü yıllarda, bir SQL cümlesinin nasıl çalıştırılacağına RBO (Rule Based Optimizer) isimli bir optimizer karar veriyordu. Bu kurallara sıra atanıyor ve sıra değeri en yüksek olan kural işletiliyordu.

Rule Based Optimizer(RBO) : Adı üstünde “execution plan” çıkarırken belli bir sırada tanımlı kural tablosundan faydalanır.Bu kural tablosu aşağıdaki şekildedir :

1. Single Row by Rowid
2. Single Row by Cluster Join
3. Single Row by Hash Cluster Key with Unique or Primary Key
4. Single Row by Unique or Primary Key
5. Clustered Join
6. Hash Cluster Key
7. Indexed Cluster Key
8. Composite Index
9. Single-Column Indexes
10. Bounded Range Search on Indexed Columns
11. Unbounded Range Search on Indexed Columns
12. Sort Merge Join
13. MAX or MIN of Indexed Column
14. ORDER BY on Indexed Column
15. Full Table Scan

Daha sonra Oracle 7 ile birlikte CBO (Cost Based Optimizer) isimli daha kompleks bir optimizer oluşturuldu. Bu optimizer partitioning, paralel çalışma ve en önemlisi de verinin segmentler üzerinde nasıl dağıldığını da hesaba katacak şekilde geliştirildi.

CBO, mümkün olan tüm planları inceleyerek, COST değeri en düşük olan execution planı seçer. Buradaki COST’dan kastımız ise, verilen planın ne kadar kaynak kullanılacağının bir tahminidir. Bu tahminin gerçeğe yakın olabilmesi ve dolayısı ile COST’un yaklaşık olarak hesaplanabilmesi için CBO’nun tablo, index vb. segmentler hakkında ve bu segmentler üzerindeki veri dağılımlarının, density(yoğunluk), selectivity vb. bilgilerinden haberdar olması gerekmektedir. İşte bu bilgilere “OPTIMIZER STATISTICS”, veritabanı istatistiği denir.

NOT : Density değeri 0 ve 1 arasında bir decimal değerdir. 1’e yakın değerler kolonun unselective, 0’a yakın değerler ise selective (seçici) olduğunu gösterir. Density değerinin oluşabilmesi için tablo üzerinde gather statistics işlemi çalıştırılmalıdır. Density hesaplamak için “DENSITY = 1 / (NULL olmayan distinct değer sayısı)” örneğin “DENSITY = 1 / 2000 = 0,0005 ” dir.

İstatistik bilgileri USER_TAB_STATISTICS, USER_TAB_COL_STATISTICS… gibi data dictionary tabloları içerisinde saklanır.

Aşağıdaki sorguyu inceleyelim;
(continue reading…)

Oracle veritabanında çalıştırılan her SQL sorgusu, bir çalıştırma planı (execution plan) doğrultusunda işletilir. Bu plan ile, hangi indekslere (varsa ve uygunsa) erişileceği, hangi tip “join” işlemlerinin gerçekleştirileceğine karar verilir. Çalışma planı, bir yerden bir yere giderken izlenecek birçok yol arasında en hızlı ulaşımı sağlayacak güzergahın seçilmesi olarak da düşünülebilir.
İyi çalışan bir sorgu öncelikle kullanıcıya en uygun sürede hizmetin verilmesi için gereklidir Öte yandan, mevcut donanım kaynaklarının verimli şekilde kullanımı için de sorguların iyi çalışması gerekmektedir. Kötü çalışan bir sorgu; disk, bellek ve CPU açısından da darboğazlara yol açabilmektedir. Sorgular üzerinde bazı hallerde yapılacak ufak rötuşlar bile çok önemli performans kazançları sağlayabilmektedir.

Bir SQL sorgusunun iyileştirilmesini çeşitli koşullar tetikleyebilir. Bunlar arasında kullanıcı tarafından işlemin uzun sürdüğü şeklinde yapılan geri bildirimler olabileceği gibi, yapılan izleme, istatistik toplama çalışmaları kapsamında sorgunun fazla kaynak kullandığının tespit edilmesi de yer alabilir. Üzerinde çalışılması gereken sorguya karar verildiğinde, inceleme ve test çalışmalarının, olabildiği ölçüde uygulamadan ve diğer ara katmanlardan bağımsız olarak gerçekleştirilmesi yararlı olacaktır. Buradaki amaç uygulamanın kendi yapısından kaynaklanan farklı işlemleri devre dışı bırakarak, sadece SQL’in optimizasyonuna yoğunlaşılmasıdır. Bu nedenle, kullanılan izleme araçları ile, sorunlu olduğu düşünülen SQL sorgusu tespit edildikten sonra doğrudan sorgu üzerinde çalışılmalıdır.

Sorgularda dikkat edilmesi gereken bir diğer husus da, “literal” veya “bind” kullanımıdır. “Literal”de, aşağıdaki örnekte olduğu gibi, where koşulu içinde bir değer (value) belirtilmiştir. (continue reading…)