Yapılan bir sorguda istediğimiz koşullardaki verileri en kısa zamanda elde etmek isteriz.Bunu sağlamanın yollarına “Access path” adı veriliyor.Bunların başında da belki de en çok bilineni ve genellikle de en etkili olanı indekslerdir.Oracle’ın her yeni sürümünde farklı indeks yapıları ile karşılaşmak mümkün.Mesela bitmap indeksler ile fonksiyon bazlı(function-based index) indeksler örnek olarak söylenebilir.Burada bu konulara girilmeyecek sık kullanılan indekslerin “genel” özelliklerinden kısaca bahsedilecektir.
NOT : Indeksler sorgularda genellikle kurtarıcı ya da en etklili yol olarak bilinse de uygun kullanılmadıklarında hepimizin gözünü korkutan –ki her zaman böyle değildir- tüm tablonun taranması(Full Table Scan) işleminden daha çok zaman aldığı durumlar olabilmektedir.
Şimdi kısaca indekslere bir göz atalım : Indeks kullanımını anlamak için önce B*Tree yapısı hakkında bilgi sahibi olmakta fayda var.
B*Tree yapısında 3 farklı seviyeden bahsedilir.Bunların ilki en tepede duran “Root”’tur.En altta da “leaf” denilen seviye ve bu ikisi arasında da “branch” (lar) bulunur.Örneğin “root” değerimiz 50 olsun.Bundan küçükleri sola , büyükleri sağa , branch tada boyle bir ayrım yaptıgımzı düşünerek yeniden bir dallanma gerçekleştirdiğimizde (leaf) , kabaca bir B Tree oluşturmuş oluruz.(Bu yapının etkili kullanımı için dengeli bir yapıda tutulması gerekmektedir.Yani veriler bir tarafa dogru yığılma yapmamalıdır.)
En etkili avantajı ağaç üzerinde milyonlarca kayıt olsa bile en fazla 2 ya da 3 I/O ile bir kayda ulaşmanın mümkün olmasıdır.(Dezavantaj ise bir düğümün silinmesi ya da değiştirilmesi durumunda ağacın yeniden organize edilmesi ihtiyacının olmasıdır.)Örneğin T tablomuzda “id” kolonu üzerinde “index” oldugunu varsayarsak indeks oluşturmak için aşağıdaki gibi yazabiliriz :
Oracle acısından bu ağacın önemine gelecek olursak , Oracle indeks yapısını bu ağaç yapısı üzerine oturtmuştur.Yani bir kolon üzerinde bir indeks oluşturduğunuzda bu indeks (kolon değeri) ve o verinin bulundugu satır bilgisi(rowid) bu ağaçta uygun yere yerleştirilir.(ROWID,verinin fiziksel adresidir).Leaf seviyesinde ya tek bir değer olur ya da bir değer aralığı bilgisi bulunur.Ama hepsi sıralıdır.Leaf seviyeler birbirine linkli liste mantığına göre bağlıdır.
CREATE INDEX t_id_idx ON t(id);
Peki bu aşamada neler yaşanır? “id” kolonunun değerleri artan sırada dizilir.Degeri ve tablodaki satır adresi(rowid) bilgisi saklanır, bu şekilde indeksimiz oluşturulmuş olur.Aşağıdaki sorguya bakalım :
select * from T where id = 12345
sorgusunda normal şartlarda indeks tarama (index scan) yapılır, önce “id” değeri indeksten bulunur ve satırının rowid bilgisine ulaşılır ve rowid bilgisi ile tabloya nokta atışı yapılarak veriler getirilir. “….where id between 200 and 300…” gibi bir sorguda “leaf” ler üzerinde gezilerek aralık (range) bilgisine ulaşılır.B Tree indeks yapısında tekil(unique) olmayan bir indeks değeri yoktur.
NOT : indeks tekil (unique) bir indeks ise tekillik sağlamak sorun olmaz ama eğer indeks tekil değilse bu tekillik Oracle tarafından indeks değeri yanına rowid bilgisi eklenerek sağlanır.Tekil durumunda indekse gore bir sıra oluşturulur, tekil değil ise bu sıralama 2 değere göre birden yapılır.
Kısaca indeksler bu şekilde.Ama bunun yanında “index-Unique Scan, Index-Range Scan, Index-Skip Scan, Index-Full ScanIndex-Fast Full Scan , Index Join, Index Rebuild” konularına bakmanızı tavsiye ederim.
1 ) Indeksler view’larda kullanılabilir mi? Bu sorunun cevabı aslında çokta zor değil.View , bir sorgu cümleciğinden ibarettir.Tablonuzda indeks oluşturduysanız ve view oluştururken kullandığınız sorguda indeksi kullanmasını sağladıysanız view indeks kullanır aksi halde kullanamaz.
2) Indeksler ve NULL : Bitmap indeksler ile clustered indexler hariç B*Tree yapısındaki indeksler NULL barındırmazlar.Bunu şöyle ispat etmek mümkün :create table t2 (x int, str varchar2(15));create unique index idx_t2 on t2(x)declare
begin
insert into t2 values(1,’bir’);
insert into t2 values(2,’iki’);
insert into t2 values(3,’uc’);
insert into t2 values(null,’bos’);
commit;
end;
declare
sqlStr varchar2(500);
begin
sqlStr := ‘analyze index idx_t2 validate structure’;
execute immediate sqlStr;
end;
select name, lf_rows from index_stats
NAME LF_ROWS
IDX_T2 3
Görüldüğü üzere T2 tablosunun (x) kolonuna unique indeks uyguladık, 4 satır ekledik ama kontrol ettiğimizde 4 değil 3 satırın indeksli oldugunu gördük.(x) kolonu NULL değeri aldığı için indekslenmemiştir.
Yine T2 tablosundan “x” kolonu için sorgu yapalım :
select * from t2 where x = 1 sorgusunda “index unique scan” ile 1 satir gelirken
select * from t2 where x is null sorgusunda “table Access full” ile 1 satir gelmiştir.Yani indeks oluşturduğumuz “x” kolonu için NULL sorgusu yaptıgımızda indeks kullanılmamıştır.Bunun sebebi yukarıda da değindiğimiz indekslerin NULL değer içermemesidir.
2 ya da daha fazla kolon üzerinde indeks oluşturdugumuz durumlarda da kolonlardan en az birinin NOT NULL olup değer içermesi gerekir ki indeks kullanılabilsin.NOT : Özellikle unique indeks oluşturmak istediğimizde “NOT NULL” kısıtı koymak indeksi verimli kullanmamızı sağlayacaktır.Parent tablonun primary key alanında yapılacak bir update ya da parent tablodan bir satırın silinmesi child tabloda bir “table lock” oluşmasına neden olacaktır.Bu durumda da child tablo üzerinde hiç bir şekilde DML işlemi yapılmasına izin verilmeyecektir.Bu da “deadlock” probleminin oluşmasına davetiye çıkarır.Indekslenmemiş foreign key’ler aşağıdaki durumlarda da probleme yol açar :
3) Indeksler ve Foreign key : Foreign key’in indekslenip indekslenmemesi konusu aslında tamamen tasarımınız ile ilgilidir.Foreign key indekslenmediğinde bizleri bekleyen en büyük problem belkide “deadlock” oluşmasıdır.Peki bu nasıl olur?Bunu anlamak için önce şu bilgileri tekrar edelim :“child table” foreign key barındıran tablodur, “parent table” ise foreign key’in gösterdiği alanın bulundugu tablodur.
i) Child tablo da “ON DELETE CASCADE” özelliği olsun ve foreign key’de indeks bulunmasın.Bu durumda parent tabloda bir verinin silinmesi durumunda child tabloda bir “full table scan” yapılmasına sebeb olunur.
ii) Parent tablodan child tabloya dogru olan sorgularda.EMP / DEPT örneği verilebilir.EMP child table, DEPT ise parent tablodur ve örnegin depname = ‘XXX’ olan çalışanları getir gibi bir sorguda sıkıntı yaşayabilirsiniz :
Select * from emp, dept
where emp.deptno = dept.deptno
and dept.depname = ‘XXX’Peki tersi durumlar, yani foreign key değerinin indekslenmesine gerek olmayan durumlar neler olabilir ? :
a) Parent tablodan bir veri silinmeyeceğinde
b) Parent tablonun primary/unique key değeri update edilmeyeceğinde
c) Parent tablo ile child tablo foreign key değeri üzerinden sorgulanmayacağında.Bu şartlarda foreign key indeklemeye gerek yoktur bu sayede DML işlemlerimizde gereksiz yere indekslenmeden dolayı bir yavaşlamaya sebeb olmayacaktır.
Hakkı Oktay
http://hakkioktay.wordpress.com
Bu makaleyi beğendin mi? Yorumunu Yaz! 
