Optimizer ve Execution Plan :
Optimizer, bir SQL çalıştırıldığında veriye ulaşmak için gerekli en etkili yolu bulmaktan sorumludur.
En etkin yoldan kasıt Oracle’ın çıkaracağı ve “execution plan” olarak bilinen “çalış(tır)ma planı”’dır.Bir DML çalıştırıldığında verinin fiziksel olarak veritabanında nerede nasıl tutuldugundan , bunları kullanıcının kullanımına hazır hale getirmeye kadar olan geniş bir yelpazede işlemler ve adımlar gercekleşmektedir.Bunları sağlarken tek bir yöntem değil birden çok yöntem vardır.Toparlamak gerekirse “execution plan” , kullanıcı isteğinin karşılanması için gerekli adımlar toplamıdır.
Oracle hali hazırda 2 farklı optimizer kullanmaktadır :
1) Rule Based Optimizer(RBO)
2) Cost Based Optimizer(CBO)
Oracle, 10g sürümü ile birlikte RBO desteğini kesmiş ve kullanıcılardan CBO’a yönelik uygulama geliştirmesini beklemektedir.Zaten 10g sürümünde sadece CBO modları secilebilmektedir.Hangisi kullanılırsa kullanılsın bir “execution plan” oluşturulmaktadır.Şimdi bu optimizer çeşitlerine daha yakından bakalım.
1) Rule Based Optimizer(RBO) : Adı üstünde “execition 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
Peki bu kural tablosu ve sırası nasıl kullanılıyor?Örneğin :
select * from theTable where id = 12345
şeklinde bir sorgumuz olsun.Ilgili veriyi getirmek için ilk akla gelen yöntemler ya varsa index üzerinden gidilmesi ya da indeks yoksa tüm tablo taranmasıdır.(Full Table Scan(FTS)).Indeks yukarıdaki kural tablosunda FTS’dan önce geldiği için RBO , execution plan’ı “indeks üzerinden gidilecek” şeklinde oluşturur.
İlk bakışta (örnekten hareketle) bu kural tablosu tüm durumlar için en optimum sırayı barındırıyor gibi görünse de bazı durumlarda en etkili yol daha evvel sırada olmadığı için en etkili “execution plan” çıkarılmış olmaz.Bu aşamada bir başka yaklaşıma ihtiyaç duyulmaktadır.Bu da CBO ile sağlanmaktadır.
2) Cost Based Optimizer(CBO) : Oracle’ın 7.1 sürümü ile birlikte ortaya çıkmış ve her yeni sürümde bir evvekinden daha gelişmiş olarak 10g sürümü ile birlikte son halini almış bir program olarak ifade edilebilir.Program dedim çünkü işlevi aslında analiz olan bir yapı.CBO , RBO dan farklı olarak execution plan çıkartırken belli kurallardan değil istatistiklerden hareket eder.Kendisine baz olarak “maliyet”i (cost) alır.
Peki bu istatistik nedir?İstatistikten kasıt ilgili tablodaki satır sayısı, verilerin tutulduğu block’ların durumu , indeks bilgileri, tablodaki bir satır uzunluğu ve adedi vs.. bilgilerdir.Tüm bu bilgiler ışığında CBO, farklı varyasyonlar oluşturur ve maliyeti (cost) en az olan “execution plan”’ ı seçer.Tüm bu işlemler uzun sürer gibi gözükse de aslında milisaniye mertebesinde oldukça kısa süren işlemlerdir.
Burada en önemli nokta kullanılan bu istatistiklerin “güncel” olmasıdır.Eğer güncel değilse çıkarılan “execution plan” maliyeti en düşük olan sanılır ama aslında böyle olmayabilir.Bu da beklenmedik sorgu , işlem vs. süreleri ile karşılaşmamıza sebep olur.
İstatistik toplamanın klasik yöntemi “analyze table” ve “dbms_utility”
kullanmaktır.Ama 8i sürümü ile ortaya çıkan ve Oracle’ın tercih ettiği “dbms_stats” paketi kullanmak en etkin şekilde istatistik toplanmasını sağlayacaktır.Aşağıda bunların kullanımına uygun örnekler ve açıklamaları bulabilirsiniz :
ANALYZE kulanımı hakkında :
Belli bir tablo, indeks ya da cluster için kullanılabilir.Tüm tablo için istatistik toplatılabileceği gibi bir satır sayısı ya da yüzde vererekte “tahmini” istatistik toplatılabilir.
ANALYZE TABLE employees COMPUTE STATISTICS;
ANALYZE INDEX employees_pk COMPUTE STATISTICS;
ANALYZE TABLE employees ESTIMATE STATISTICS SAMPLE 100 ROWS;
ANALYZE TABLE employees ESTIMATE STATISTICS SAMPLE 15 PERCENT;
DBMS_STATS kullanımı hakkında :
Özellikle pararel çalışma işlemleri(parrarel execution) ve istatistikleri server’lar arası taşıma özelliği DBMS_STAT’ı öne çıkaran özellikleridir.(Toplanan istatistikler bu paket ile silinebilmektedir.)
EXEC DBMS_STATS.gather_database_stats;
EXEC DBMS_STATS.gather_database_stats(estimate_percent => 15);
EXEC DBMS_STATS.gather_schema_stats(’SCOTT’);
EXEC DBMS_STATS.gather_schema_stats(’SCOTT’, estimate_percent => 15);
EXEC DBMS_STATS.gather_table_stats(’SCOTT’, ‘EMPLOYEES’);
EXEC DBMS_STATS.gather_table_stats(’SCOTT’, ‘EMPLOYEES’,
estimate_percent => 15);
EXEC DBMS_STATS.gather_index_stats(’SCOTT’, ‘EMPLOYEES_PK’);
EXEC DBMS_STATS.gather_index_stats(’SCOTT’, ‘EMPLOYEES_PK’,
estimate_percent => 15);
EXEC DBMS_STATS.delete_database_stats;
EXEC DBMS_STATS.delete_schema_stats(’SCOTT’);
EXEC DBMS_STATS.delete_table_stats(’SCOTT’, ‘EMPLOYEES’);
EXEC DBMS_STATS.delete_index_stats(’SCOTT’, ‘EMPLOYEES_PK’);
Istatistikleri sistemler üzerinde taşıyabilme özelliğine dikkat çekmek istiyorum.Test verilerinin gerçek ortamdaki veriler kadar büyük ve gerçekçi olması her zaman mümkün olmamaktadır.Gerçek ortamda 100 Milyon kayıt içeren bir tablonun test ortamında çokdaha az sayıda kayıt içermesi söz konusudur.Ama bu özellikle performans testleri için önemli bir kısıttır.Ancak istatistiklerin taşınabilmesi sayesinde , optimizer için test ortamı gercek ortammış gibi kullandırılabilir.Baska bir deyişle test ortamındaki tablonuzdada 100 Milyon kayıt varmış gibi bir execution plan çıkarttırmak mümkün olmaktadır.
Kaynak: www.gelecekonline.com