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.
