Oracle Veritabanı Yapısı

   Oracle Veritabanı, birim olarak kabul edilen verilerin bir araya toplanmasından oluşur. Veritabanının amacı birbiriyle ilişkili bilgilerin depolanması ve sorgulanmasıdır. Bir veritabanı sunucusu bilgi yönetimiyle ilgili problemleri çözmede anahtar roldedir. Genel olarak bir sunucu, büyük miktardaki veriye çok kullanıcılı bir ortamda, bir çok kullanıcının aynı anda aynı veriye ulaşabilmelerini güvenilir bir şekilde saglar ve bunu aynı zamanda yüksek bir performansla gerçekleştirir. Bir veritabanı sunucusu aynı zamanda izinsiz erişimi engeller ve hata durumundan kurtulmak için gereken en uygun çözümleri saglar. Veritabanı fiziksel ve mantıksal olmak üzere iki yapıdan oluşur. Fiziksel ve mantıksal yapı biribirinden ayrı oldugu için verinin fiziksel olarak saklanma şekli mantıksal yapıya erişimi etkilemez.

Fiziksel veritabani yapisi:

Fiziksel yapiyi olusturan 5 temel olmazsa olmaz bilesenleri su sekilde siralayabiliriz:

1.Datafiles
2. Control Files
3. Redo Log Files
4. Archive Log Files
5. Parameter Files

Simdi bunlara kisaca goz atalim.

DATA FİLES : Veritabanindaki tablolar, indeksler gibi tum mantiksal yapilarin , fiziksel olarak saklandigi dosyalardir. Her Oracle Veritabani bir ya da daha fazla sayida datafile icerebilir. Tablo, indeks gibi matiksal yapilarin barindirdigi fiziksel bilgileri tutar.Belli basli ozelliklerini soyle siralayabiliriz :

• Bir datafile sadece bir veritabani ile iliskilidir.
• Bir ya da daha fazla datafile mantiksal yapilardan olan tablesace’leri olustururlar.
• Gerektiginde kendilerini otomatik olarak buyutme (extend) ozellikleri vardir.

    Ornegin bir tablodan veri okunmak istediginde bu hafizada(memory) yoksa ilgili datafile’dan okunarak hafizaya cekilir ve okunur.Datalar uzerinde degisiklik yapildiginda ise hemen datafile’a bu degisiksik yansitilmaz. İ/O miktarini dusuk tutmak amaciyla bu islem “Database Writer Process(DBWn)” adi verilen bir arkaplan islemi (background process) tarafindan karar verilen anlarda yapilir.

Bir veri tabaninin performansli calisabilmesi icin fiziksel olarak ayri disklere yerlestirilecek minimum 5 datafile olmalidir. Bunlar:

       1. Oracle’in arka plandaki islemleri icin kullandigi sistem dosyasi,
       2. Sadece tablo kayitlarinin tutuldugu indeks dosyasi,
       3. Tablolarin indekslerinin tutuldugu indeks dosyasi ,
       4. Siralama islemleri icin veri tabaninin gecici olarak kullanildigi “temporary” dosyasi,
       5. Geri alma islemlerinin tutuldugu “rollback” dosyasi

Eger bu dosyalar fiziksel olarak ayri disk uzerinde tutulmaz ise parallel olarak okuma ve veri tabanina yazma yapilamayacagi icin performansi negatif olarak etkiler.

CONTROL FİLES : Controlfile , database kurulumu ile otomatik gelir ve database in fiziksel yapisini tutan ufak bir binary dosyasidir. Database adi , yaratilma zamani , datafile ve redo log gibi dosyalarin isletim sistemi uzerinde nerede oldugu ,guncel log sequence numarasi ve chechkpoint gibi bilgileri tutar.Database acikken controlfile var ve uzerine yazilabilir durumda olmalidir.Bu dosya olmadan database calismaz.Database open moda (acilmadan) gecmeden once mount moda gecer.Mount modda controlfile okunur ve controlfile in icindeki bilgiler ile database iliskilendirilir. Eger controlfile yok ise database mount olamayacaktir dolayisi ile acilmayacaktir.O yuzden bu dosyanin kaybolmamasi cok onemlidir.Dolayisi ile disklerde sorun olma ihtimaline karsi farkli disklerde yedek controlfile larin olmasi yararli olur.

         Dedigimiz gibi her veritabani oturumu acildiginda Oracle bu dosyayi kontrol ederek gerekli bilgileri alir. Eger veritabaninda fiziksel bir degisme olursa (yeni bir log dosyasi ya da veri dosyasi olusturulmasi gibi), yapilan degisiklikler Oracle tarafindan otomatik olarak kontrol dosyalarina yansitilir.

         Controlfile veritabaninin en onemli dosyalarindan biridir hatta en onemlisidir, veri tabaninin kimligi olarak tanimlayabiliriz. Her instance’in en az bir adet controlfile’i vardir. Guncel 11g kurulumlarinda 3 adet controlfile otomatik olusur.Kurulum esnasinda bunlari farkli disklerde olusturmak sizin icin cok avantajli olur.Bir controlfile kayip olsa bile diger yedeklerden kopyalayabilirsiniz. Sqlplus a girdikten sonra show parameter controlfiles komutu ile kendi controlfile larini ve hangi disklerde olduklarini gorebilirsiniz.

REDOLOG FİLES :  Yedekleme, kurtarma, geri getirme, eskiye gidebilme gibi veritabani uzerinde yapilan hangi islem olursa olsun, her zaman onemli olan verilerin ve veri butunlugunun kaybedilmemesidir. Bunun icin tam guvenlik vaad eden her veritabani ACİD (Atomicity Consistency İsolation Durability) denilen standarta uymak zorundadir. Bu standarti kisaca aciklarsak;

         Atomicity : Ya hep ya hic kuralidir. Bir islem ya tam olarak yapilip,

sonuclanir;  ya da hic yapilmaz. Yarida kalan islemler geri alinir. Yapilan islemler ise belirsizlige yer birakmayacak sekilde tamamlanmistir.

         Consistency : Veritabaninda tutarlilik esastir. Bir islemden once veritabani

tutarliysa, islem sonrasi da tutarli kalir. Eger veritabani tutarliligini bozan bir islem gerceklesiyorsa, islem geriye alinir.

         İsolation : Bir operasyon tarafindan yapilan degisikliklerin, diger islemler

tarafindan nasil goruntulenmesi gerektigini belirler. Ornek olarak iki kullanici ayni katalog nesnesini guncelliyorsa, ortamda sadece kendileri varmis gibi (izole) calisabilmeleri gerekir. Bir kullanici digerinin degisikliklerini etkilememelidir,

baskasinin degisikliklerinden de etkilenmemelidir.

         Durability : Commit edilen islemlerin veritabanina yazildiginin ve

kaybolmayacaginin garantisidir.

           Tum bu ozelliklerin saglanmasi oldukca guctur. Bunlari yapabilmek icin Write Ahead Logging (Transactional Log) ve Shadow Paging isimli yontemler kullanilmaktadir. Shadow Paging, veritabanina gercek girisin yapilmasindan once, kopyaya girisin yapilip, ardindan gercek degisiklige gidilmesi olarak dusunulebilir. Write Ahead Logging (WAL) ise yapilacak islemlerin oncelikli olarak bir log dosyasina yazilmasi ardindan, veritabanina ait dosyalara aktarilmasidir. WAL kavrami, Oracle’da online redo log olarak gecmektedir. Veri guvenligi icin yapilan her islem oncelikle online redo log diye isimlendirilen dosyalarin icerisine yazilir. Daha sonra ara ara bu redo log’lar Oracle’a ait veritabani dosyalarina yazilir.

       Oracle redolog dosyalarinin nereden geldigine kisaca degindikten sonra simdi detayli bir sekilde inceleyelim. Redolog dosyalari, veritabanindaki tum “commit” olmus degisikliklerin , kurtarma yapilirken kullanilmak uzere kaydedildigi dosyalardir. En az iki redo log grubu tanimlanir. Bu dosyalarin boyu ve grup sayisi veri tabani yaratilirken sisteme tanimlanir. Sonradan bu tanimlar degistirilebilmektedir. Redo log dosyalarinin cok kucuk olmasi , sistemde beklemelere neden olur. Cok buyuk olmasi da veri tabani acilirken yapilan otomatik kurtarma isleminin cok uzun surmesine yol acar ve aktif redo log dosyalarinin silinmesi yada bozulmasi durumunda da daha fazla veri kaybi olmasina neden olur.        

      Online redolog dosyalari veriye yapilan tum degisiklik islemlerini tutmakla yukumludur. Datafile’lara (bir sekilde) degisen bilgi yazilamadigi durumlarda redo loglardan bu islemler gorulebilir ve yapilan islemin kaybi onlenir. Bu dosyanin amaci ozetle sistem ya da donanim kaynakli (harddisk gocmesi vs.) olasi hatalarda datafile’lara kalici sekilde yazilamayan bilgileri kurtarmaktir. Ornegin bir elektrik kesintisinde henuz datafile’lara yazilmayan ve memory de bulunan bilgiler kaybedilir.Sistem tekrar ayaga kalktiginda Oracle ilk once redo log ‘lara bakar. Kalici olarak datafile’a yazilamayan bilgi oldugunu gorur ve yarim kalan islemi sonlandirir.Bu sayede veritabani elektrik kesintisi olmadan evvelki konuma gelinmis olur.
       Sistemin guvenligi acisindan her gruptaki redo log’u iki kopya olarak veri tabani farkli disklerde olusturmak mantikli olandir. Redo log’lar kesinlikle raid disk uzerine konulmamalidir. Cunku redo log dosyalari uzerine surekli yazma yapilmaktadir ve raid diskler yazma isleminin yavaslatir.
           Redo log dosyalari bir dongu icersindedir. Bir gruptaki redo log doldugunda otomatik olarak diger gruba gecer ve islem bu sekilde devam eder. Eger veri tabani arsiv modda ise bu dolan redo log dosyasinin bir kopyasi arsiv.log olarak kopyalanir ve kurtarma amacli saklanir. 

    

Oracle, Redo Log’lara ve Veritabani Dosyalarina Nasil Yazar?

           Bir veritabani iki veya daha fazla redo log dosyasindan olusur. En az iki olmasinin nedeni, archivelog seklinde calisiyorsaniz, redo log dosyalarindan bir tanesi kullanilirken digeri arsive cikilabilsin diyedir. Boylece her zaman calisabilir olmayi saglar. Gerci asiri yogun bir sistemde sadece iki adet redo log kullaniyorsaniz, "Thread 1 cannot allocate new log, sequence #" seklinde sik sik hata alirsiniz. Cunku redo log’larin arsive cikmasi icin yeterli zaman olmayacaktir. Online redo log’lar arasindaki gecis, sirkuler sekilde asagidaki gibi gerceklesmektedir.

    Yukarida verilen islemler LogWriter tarafindan saglanmaktadir. LGWR, log buffer’daki redo bilgilerini, redo log dosyalarina aktarmaktan sorumludur. Herhangi bir zaman diliminde, Oracle redo log dosyalarindan sadece bir tanesini kullanir. Kullandigi redo log dosyasi doldugunda, bir sonraki redo log dosyasina gecilir. Fakat bu gecis yapilirken, siradaki online redo log iceriginin datafile’lara yazilip yazilmadigi ve bu dosyadan arsiv uretilip uretilmedigi kontrol edilir. Her iki islemde bitene kadar bu redo log dosyasi kullanilmayacaktir. LGWR, bir sonraki redo log dosyasina gectiginde, bir onceki redo log dosyasinin durumunu controlfile icinde CURRENT’ten ACTİVE’e cevirir. Akabinde DBWR (Database Writer) islemini durumdan haberdar ederek, bir onceki redo log dosyasinda checkpoint islemi yapmasini gerektigini belirtir. DBWR tarafindan checkpoint islemi tamamlanip, redo log’daki degisiklikler veritabani dosyalarina yazildiginda CKPT process’i cagrilir. CKPT islemi veritabani dosyalarinin header bilgilerini ve check point bilgisini (sadece) controlfile icerisinde gunceller.

       Burada dikkat edilmesi gereken, CKPT’in redo log bilgisine dair bir guncelleme yapmamasidir, isminden de belli olacagi gibi sadece checkpoint islemiyle ilgilenir.CKPT islemi tamamlandiginda, LGWR islemi cagrilarak controlfile icerisinde redo log bilgisini ACTİVE’den İNACTİVE’e ceker. (Bu guncelleme, v$log.status bilgisini saglar.) Bu degisiklik dusuk onceliklidir, cunku bu konuyla tek ilgilenen process LGWR’in kendisidir. Buradaki status bilgisine gore, LGWR redo log dosyasinin tekrar kullanilip kullanilmayacagina karar verir. Eger yeterli sayida redo log dosyasi varsa, herhangi bir is bloklanmaz. Ancak yogun bir ortamda az sayida redo log dosyasi varsa, daha once belirtildigi gibi "Thread 1 cannot allocate new log, sequence #" seklinde sik sik hata alinacaktir.

Redo Log Dosyalarinin Durumlari

Redo log dosyalarinin bulunabilecegi bazi durumlar su sekildedir :

     - CURRENT : Redo log dosyasinin kullanimda oldugunu gosterir.

     - ACTİVE : Current redo log dosyasi degismistir. Ancak daha once kullanimda olan redo log dosyasinin icerigi henuz veritabanina aktarilmamistir. Yazma islemi devam etmektedir. LGWR tarafindan active’lik durumu bir sure sonra, İNACTİVE’e cekilir. Checkpoint komutuyla, yazma isleminin yapilmasini tetiklemek mumkundur.

     - İNACTİVE : Kullanimda olmayan redo log dosyalarini ifade eder.

     - UNUSED : Đlgili redo log dosyasinin henuz hic kullanmadigini gosterir. Yeni eklenen redo log dosyalarini, unused olarak gorursunuz.

     - İNVALİD : Dosyanin erisilemez (ya da bozuk) oldugunu isaret eder.

     - STALE : Dosya tamamlanmamistir. ABORT ile ya da beklenmeyen ani veritabani kapanmalarindan kaynaklanmaktadir.

ARCHİVELOG FİLES : Adindan da anlisilacagi uzere arsiv dosyalarina verilen isimdir. Oracle veritabani ARCHİVELOG modunda ise redo log dosyalari bu dosyalara otomatik olarak arsivlenir.

PARAMETER FİLES : Hemen hemen her sistem gibi Oracle da calismaya baslayabilmek icin bir takim parametrelere ihtiyac duyar ve bu parametreler belirli dosyalardan okunur. Bu paramtreler bir Oracle İnstance’in hangi ayarlarla calisacagini belirleyen parametrelerdir. Kullanilan tum parametreler SQL*PLUS a baglanilip SHOW PARAMETERS komutuyla goruntulenebilir.

      Oracle ilk basladiginda parametre dosyalarini okur ve sisteme dair bircok ayara buradan ulasir. Ayni anda calisabilecek islem adedi; arsiv dosyalarinin lokasyonunun neresi olacagi; kac dakikada bir arsive cikilacagi ; control file’larin lokasyonlari ; backgroud dump, user dump gibi klasorlerin nerelerde

konumlandirildigi vb. bilgiler parameter dosyalari icinde saklanir. Bu degiskenlere parametre denmektedir ve hep birlikte parametre dosyasini olustururlar. Ancak parametre dosyasi okunup gerekli bilgiler alindiktan sonra, control file’lara erisilip, Oracle datafile’lar (veritabani dosyalari) kullanilmaya baslanir.

     Oracle’da iki cesit parametre dosyasi vardir; bunlardan birisi bizim uzerinde degisiklik yapabilecegimiz metin tabanli olan PFİLE ( Parameter File )’dir. Digeri ise binary bicimde oldugu icin uzerinde degisiklik yapamayacagimiz SPFİLE ( Server Parameter File )’dir. SPFİLE, Oracle 9i ile beraber gelmistir. PFİLE  ise ilk surumden beri kullanilmaktadir.

     
Simdi bu dosyalari biraz daha yakindan taniyalim :

   1-    Oracle PFİLE (Parameter File):

      Kullanicilarin uzerinde degisiklik yapabildigi, metin tabanli dosyalardir. Genellikle isimleri init.ora dir. Pfile dosyasi, icerisinde parametre olarak nitelendirilen veritabani ayarlarinin bulundugu dosyadir. Bu parametreler, veritabaninin hangi ayarlarla baslatilacagini belirler. Ornegin, “control_files” parametresi, kontrol dosyalarinin dizinlerini tutarken;  “audit_file_dest” parametresi audit dosyalarinin dizinlerini tutmaktadir; “open_cursors” parametresi ayni anda acik olabilecek maksimum cursor sayisini tutarken “processes”  parametresi ise ayni anda calisabilecek islem sayisini tutmaktadir.

     2-    Oracle SPFİLE (Server Parameter File):                                                                         Oracle 9i ile gelen parametre dosyasi tipidir. PFİLE, text-based yapidayken ve uzerinde herhangi bir metin editoru ile degisiklik yapabilirken; SPFİLE, binary yapiya sahiptir ve degisiklikler sadece ALTER SYSTEM SET komutlariyla gerceklestirilebilir. SPFİLE kullanimi , automatic performance tuning tarafindan tavsiye edilmektedir cunku getirdigi pek cok avantaj vardir.

• SPFİLE, dosyadaki veya veritabanindaki herhangi  bir yapisal degisiklik durumunda RMAN tarafindan otomatik olarak yedegi alinabilir duruma getirilmistir. Boylece her degisiklikte tekrar tekrar yedek almak durumunda kalmayiz.
• Veritabanini kapatip acmaya gerek duymadan kalici parametrelerin degerlerini degistirebiliriz. Boylece veritabani gercek zamanli olarak yeni parametrelere gore davranabilir. Ayrica veritabani kapatilip acildiktan sonra da ayni sekilde korunmaya devam eder. PFİLE dosyalarindaki degisiklikler, sistem yeninden baslatilinca siliniyordu.
• SPFİLE sayesinde automatic tuning rahat ve hizli bir sekilde icsel olarak yapilabiliyor. SPFİLE kullanmiyorsaniz automatic tuning yapilamaz.    SPFİLE Degerlerini Degistirmek

       SPFİLE’da parametre degisikligini, PFİLE’da yaptigimiz gibi yapamayacagimizdan bahsetmistik. Cunku SPFİLE binary –ikilik– formatta bir dosya turudur ve bir metin editorunde acip degistirilmesi olanakli degildir. Giris kisminda parametre degistirme konusuna da deginmistik. Simdi biraz daha detaylandiralim.

Oracle veritabani bircok parametrenin online olarak degismesine olanak vermektedir. Bunun anlami,parametre degisikliklerinin gecerli olmasi icin isletim sisteminin yeniden baslatilmasina gerek olmamasidir. Bu oldukca yararli ve gerekli bir ozellik! Yabanci bir siteden aldigim ornek uzerinden gidelim;

        SQL> ALTER SYSTEM SET timed_statistics=TRUE

        COMMENT='Changed by Frank on 1 June 2003' SCOPE=BOTH SİD='*';

     
         Bizi burada en cok ilgilendiren kisimlari koyu harflerle gormek mumkun. ALTER SYSTEM SET dedikten sonra parametre adi belirtip, yeni deger veriyoruz. SCOPE kisminda uc deger verilebilir;

         ‐ MEMORY: Ayarlanan deger sadece gecerli olan Oracle 'instance' icin ayarlanacaktir. Bunun anlami, veritabanini yeniden baslattiginizda girmis oldugunuz degerin kaybolayacagidir. Ancak Oracle kapanana kadar girilen deger kalir.

         ‐ SPFİLE: Girdiginiz deger veritabaninin bir sonraki baslamasinda gecerli olacaktir.

       SPFİLE’i, PFİLE’dan Yararlanarak Yeniden Olusturmak

       Veritabaninda bir karar alindi ve bir takim degisiklikler yapmaniz gerekiyor diye dusunelim. Ornegin arsive cikilacak dosyalari /data2/archive yerine artik, /data5/archive altina kopyalamamiz gereksin.Bu gibi bir durumda spfile’i bir pfile’a donusturmek; ardindan pfile icinde degisiklik yapmak ve son olarak pfile’dan tekrar spfile yaratmak gerekir. Adim adim asagidaki islemleri uygulayalim.

    1-  SPFİLE dosyasindan, metin formatinda bir PFİLE olusturuyoruz:

                SQL> create pfile='/tmp/deneme.text' from spfile;

    2-     PFİLE dosyasini acip, log_archive_dest parametresinde ilgili degisiklikleri yapiyoruz.

      SQL> ! vi /tmp/deneme.text

      ...

    3-     Calismakta olan bir veritabaninin spfile'ini ezemeyecegimiz icin veritabanini kapatiyoruz.

      SQL> shutdown immediate;

    4-     Degisiklik yaptigimiz pfile'i kullanarak yeni bir spfile olusturuyoruz.

      SQL> create spfile from pfile='/tmp/deneme.text';

    5-     Veritabanini aciyoruz.:

      SQL> alter database open;

       SPFİLE’i direkt degistiremedigimiz icin, onu once bir PFİLE’a donusturup, ilgili degisikligi yaptik ve sonrasinda yeni bir SPFİLE yarattik. Biraz zahmetli bir is; ancak her parametre degisiminde boyle bir sey yapilmasi gerekmiyor. Cogu durumda, veritabanini yeniden baslatmadan bircok parametreyi degistirebiliyorsunuz. Ancak veritabanini kapatip, alter system olmaksizin parametre degistirmek isterseniz yukaridaki adimlari izlemeniz gerekiyor. Cok fazla kullanilmayacak, ancak bilmenizin yararli olacagi bir diger konuda, gerek SPFİLE’in gerekse PFİLE’in default olmayan bir lokasyonda bulunmasinda isinize yarayabilir. Asagidaki komutla, /tmp/ altindaki pfile’i kullanarak, /data2/ altinda spfile yedegi olusturabilirsiniz:

SQL> create spfile='/data2/spfile_yedek.ora' from pfile='/tmp/deneme.text';

Mantiksal Veritabani Yapilari:

     Oracle veritabanindaki mantiksal yapilar sema nesneleri, veri bloklari, extentler, segmentler ve tablespacelerdir. Simdi bunlari tek tek inceleyelim :

Semalar ve Sema Nesneleri (users and users’s objects)

     Sema temel olarak veritabani nesnelerinin olusturduğu topluluğa verilen isimdir. Bir semanin sahibi bir veritabani kullanicisidir ve sema da onun ismiyle anilir. Bir baska ifade sekli ile veritabani uzerinde kullanicinin belirli isleri yapabilmesi icin tanimlanan nesneler; tablolar, goruntuler, siralar, esanlamlar, indeksler, kumeler, veritabani bağlantilari, prosedurler, fonksiyonlar ve paketlerden olusur. Bir sema ise bu nesnelerin olusturduğu gruptur.

     Sema nesneleri mantiksal veri depolama yapilari olarak bilinir ve sema nesneleri direk olarak veriyle baglantili olan mantiksal yapilardir. Fakat sema ve tablespace arasinda bir bağlanti yoktur. Ayni semadaki nesneler farkli tablespace’lerde bulunabileceği gibi, ayni tablespace’lerin icinde farkli semalara ait nesneler de bulunabilir.

 Baslica sema nesneleri sunlardir:

     - Tablolar : İliskisel Veri Tabani Yonetim Sistemleri’nde veriler tablolar icerisinde yer alir. Oracle veritabanin da en temel veri saklama birimidir tablolar. Her tablo bir isimle tanimlanir ve her biri  bir “kayit” olarak adlandirilan satirlar ile bu kayitlardaki verilerin ozelliklerini belirleyen sutunlardan olusur. Her tablo bir ya da daha fazla sutuna sahip olabilir. Her sutunun bir adi ve veri tipi vardir.

     - Viewler : Viewler bir veya birden fazla tablo yada view'deki verinin ozellestirilmis bir gosterim seklidir. Bir view ayni zamanda saklanmis bir sorgu olarak da degerlendirilebilir. Viewlar aslinda veri icermezler. Bunun yerine verilerini kendilerine temel teskil eden ve view’in temel tablolari olarak adlandirilan tablolardan cikartirlar. Tablolar gibi viewlerin de bazi kisitlamalar olmakla birlikte verisi sorgulanabilir, degistirilebilir, silinebilir ve yeni veri girilebilir ama view’lerin adi uzerinde goruntu almak icin kullanilmasi asil amacidir. View’ler uzerinde yapilan her islem aslinda view’in temel tablolarini etkiler. Viewler tablonun onceden belirlenmis satir ve kolonlarina erisimi kisitlayarak, tablo guvenliginde ekstra bir seviye saglar.

     - İndeksler : İndeksler tablo ve cluster’lar icin kullanilan veri tabani nesneleridir. Burada amac aranilan bir kayda daha hizli erisimdir. Ozellikle uzerinde cok arama yapilan alan veya alanlar uzerinde indeks olusturmak cok etkilidir.  İndeks olusturulduğunda ilgili tablonun kayitlari yer değistirmez. Sadece ilgili kayitlarin kayit numaralari olarak adlandirilan “rowid” ‘ler alinarak siralama yapilir. Bir tablo uzerinde olusturulabilecek indeks sayisi sutunlarin kombinasyonlari farkli olduğu muddetce sinirsizdir. Bir sutun diğer sutunlarla değisik kombinasyonlarda kullanildiği muddetce birden fazla indeks icerisinde yer alabilir.  Ayni sutun kombinasyonlarinin indeksi, fakli indeks ismi kullanarak olusturulmaya calisilsa bile gerceklestirilemez.

İndeksler mantiksal ve fiziksel olarak olusturulduklari tablodan bağimsizdirlar. Eğer bir indeks silinirse, ilgili tablo zarar gormez, calismaya devam eder. Fakat indeks olmadiği icin veri erisim suresi artacaktir. Oracle, bir indeks olusturulduğunda onu otomatik olarak kullanmaya baslar ve  indeksin olusturulduğu tablodaki silme, guncelleme ve ekleme islemleri indekse otomatik olarak yansitilir.

     - Kumeler : Kumeler, fiziksel olarak birlikte saklanan bir veya birden fazla tablonun olusturdugu gruba denir.Bir baska ifade ile Ayni anda sorgulanan birden fazla tablonun bir arada kaydedilmesidir. Bu yapi, beraber sorgulanan tablolarda hiz kazanmak icin cok onemlidir. 
      Bu tablolar ortak kolonlar icerir ve genelde birlikte kullanilir. Birbiriyle iliskili satirlar fiziksel olarak bir arada saklandigi icin, disk erisim suresinde bir kazanc saglar. İndekslerde oldugu gibi kumeler uygulama dizaynini etkilemez.

Veri Bloklari, Extentler ve Segmentler

     Veri bloklari, extentler ve segmentlerden olusan mantiksal saklama yapilari sayesinde Oracle'in disk alani uzerinde ayrintili bir kontrolu vardir.

     - Oracle Veri Bloklari : Veri bloklari, Oracle veritabaninda verinin saklandigi en kucuk yapidir. Bir veri blogu, fiziksel veritabani alaninda belirli sayidaki byte'a karsilik gelir. Standard blok buyuklugu DB_BLOCK_SİZE baslangic parametresiyle belirlenir. Bunun disinda en cok 5 adet blok buyuklugu belirtilebilir.

     - Extentler : Mantiksal veritabani alanindaki bir sonraki seviye extentlerdir. Bir extent, belirli sayidaki ardisik veritabani blogundan olusur, bir seferde alinir ve belirli bir tipteki bilgiyi tutmak icin kullanilir.

     - Segmentler : Extentlerin uzerindeki mantiksal veritabani depolama seviyesi segmentlerdir. Segment, belirli bir mantiksal yapi icin tahsis edilmis extentler kumesidir. Bir segmentin icindeki tum extentler doldugunda, Oracle dinamik olarak yeni yer tahsis eder. Baska bir deyisle, bir segmente ait butun extentler doldugunda, Oracle bu segment icin yeni bir extent tahsis eder. Extentler gerek duyuldugunda tahsis edildiginden, segmente ait extentlerin ardisik olma zorunluluklari yoktur. Dort cesit segment tipi vardir:

     1- Veri Segmenti : Her kumelenmemis tablonun bir segmenti vardir. Tablonun butun verisi, veri segmentinin extentlerinde tutulur. Bolumlenmis tablolarda, her parca icin bir veri segmenti bulunur. Her kume icin bir veri segmenti vardir. Kumedeki her tablonun verisi kumeye ait olan veri segmentinde tutulur.

     2- İndeks Segmenti : Her indeksin kendi verisinin tutuldugu bir indeks segment vardir. Bolumlenmis bir indeksin her bolumune ait bir indeks segment vardir.

     3- Temporary segment : Temporary segmentler bir SQL cumlesinin isini tamamlamak icin gecici bir alana ihtiyac duyuldugunda Oracle tarafindan yaratilir. SQL cumlesinin calistirilmasi tamamlandiginda temporary segment yeniden kullanilabilmesi icin sisteme geri verilir.

     4- Rollback Segment : Oracle veritabaninin guvenliği acisindan “Select”, “İnsert”, “Update” ve “Delete” gibi islemlerin yedeğini almaktadir. Alinan bu yedeklerin konulduğu yerlere geri alma parcasi denir. Kullanici bu tip islemleri yaptiktan sonra “Rollback” komutunu uygularsa, yaptiği değisiklikler geri alma parcalarindan getirilir ve boylece kayitlar eski haline donmus olur. Kullanici “Commit” komutunu kullandiktan sonra yaptiği değisiklikler geri alma parcalarindan geri getirilemez.

Asağida veri bloklari, extentler ve segment iliskisini gosteren bir sekil yer almaktadir.

 Tablespace’ler

      Her veritabani, tablespace adi verilen ve biribiriyle iliskili mantiksal yapilari gruplayan mantiksal depolama birimlerine bolunmustur. Ornegin, tablespaceler genelde yonetimsel isleri kolaylastirmak icin butun uygulama nesnelerini birlikte gruplar. Tablespace icindeki tum mantiksal yapilari fiziksel olarak tutmasi icin bir veya birden fazla datafile yaratilir. Datafilelarin toplam buyuklugu, tablespace'in toplam depolama kapasitesini verir. Tablespacelerin toplam depolama kapasitesi, database'in toplam depolama kapasitesini verir. Bir tablespace online yada offline olabilir. Tablespaceler, kullanicilarin icindeki veriye ulasabilmesi icin, genelde online durumdadir. Fakat bazi durumlarda veritabaninin bir kismini erisilemez hale getirmek icin tablespacelerin bir kismi offline hale getirilir. Bu bircok yonetimsel islerin yapilmasini kolaylastirir.

Asagidaki sekil veritabani, tablespace ve veri dosyalari arasindaki iliskiyi aciklamaktadir.