Uzun zamandır yazmak istediğim geç kalmış bir konu benim için. Tüm detayları ile Oracle Veri tabanı mimarisini anlatmaya çalıştım:
ORACLE DATABASE
Nedir: Bir veya birden fazla
instance’ın ve fiziksel dosyaların toplamıdır.
ORACLE veri
tabanı RDBMS ilişkisel veritabanıdır. İlişkisel veri tabanları Primary Key,
Foreign Key alanları ile tabloları ilişkilendirilen veri tabanıdır.
ORACLE
mimarisini 3 temel alan ile ele alabiliriz. Memory, İşlemler (Processes),
Depolama yapısı (Storage)
Oracle
server bir veya birden fazla makinada çalışabilmektedir. Bu mimari:
Client-aplication
Server-Database (Three tier) è
Kullanıcı kendi bilgisayarından App. Server’a erişir buradaki konfigürasyon ve
yetkilendirme sonrası Database’e erişim sağlanır.
client-server
(two tier) è
Kullanıcı kendi bilgisayarından direk uzak veri tabanına bağlantı yapar
Host based è Bu yapı kendi
makinasından gene kendi makinasında kurulu veri tabanına ulaşır.
Oracle sunucusunda server process dışında, disk Input/Output
işlemleri gibi background (arkaplan) işlemlerini gerçekleştiren background
process’ler de vardır. Bunlar user process ile doğrudan ilişkili değildirler.
Belirli zaman aralıklarında veya belirli koşulların sağlanması durumunda
çalışırlar.
Her çalışan Oracle veritabanı bir instance ile
ilişkilendirilir. ORACLE_SID parametresi ile işletim sistemine
tanıtılan instance, belirli bir zamanda sadece bir veritabanını açıp
kullanabilir.
Instance iki process’den oluşur. Memory ve
Background. Ve bu işleme Instance denir ki oracle 1 veya 1’den
çok instance’tan oluşabilir.
INSTANCE: Oracle’ın
çalışmasını sağlayan bileşenidir. Ram üzerinde
çalışır. Datafile’lara erişmemizi sağlar. Ayrıca RAM üzerinde belirli
alanları ayırarak, kullanmamızı sağlar. Çeşitli Background process
(arkaplan işleç)’lerini kullanır ve bu sayede database’in çalışmasını sağlar.
Buna göre instance iki bileşenden oluşur. İlki Memory ikincisi ise Background
Proess’ler. Oracle Database mimarisini aşağıdaki şemada inceleyebiliriz. Database
açıldığında otomatik olarak başlamaktadır.Oracle’ı ilgilendiren Memory ve
Proses parçalarının tamamını oluşturmaktadır. Oracle Database bir veya birden
fazla Instance dan oluşabilir (Rac Olarak düşünebiliriz. Instance 1, Instance 2
, ..) SGA ve PGA database’in instance’ını oluşturmaktadır
Oracle Database Mimarisini 3 ana
başlıkta inceleyebiliriz.
1- Memory
Birimleri (SGA – PGA)
2- Process
Birimleri (BACKGROUND PROCESS)
3- Storage
(Depolama) Birimleri (PHYSICAL FILES)
1-) ORACLE BELLEK MİMARİSİ.
Tüm DBA ler
hem fikirdir ki, IO maliyetli bir iş! Bu yüzden memory menagment oldukça
önemlidir.
En basit
anlatım ile sık kullanılan işlemleri gidip diske yazmak sonra geri istemek
yorucudur. Bu yüzden bu sık kullanılanlar bellekte tutulur. Bu şekilde çalışmak
performans açısından önemlidir. Bellek yapısını iki temel alandan oluşur. SGA
(Sytem Global Area) ve PGA (Program Global Area)
Oracle da
memory de neler tutuluyor nasıl işliyor bakalım.
1.
SGA (Sytem Global Area)
i.
Sheared
pool
1. Libary cache
2. Data dict. Cache
3. Result cache
4. User Global Area
ii.
Buffer
Cache
iii.
RedoLog
buffer
iv.
Large
Pool
2.
PGA (Program global Area)
1.1-) SGA (System Global Area)
Paylaşılan bellek alanı olarak tanımlanır.
Veri tabanına bağlanan tüm sessionlar SGA alanını kullanır. Arka plan
processleri ve server işlemleri bu alanı kullanmazlar. Bu alan veri tabanı
kurulurken 3 faklı şekilde ayarlanır Automatic Memomry menagment, Automatic
Shared memory menagment,
Memory
menagment... tabi daha sonrada bunları konfigure edebilirsiniz
Bu alan fizikesel sunucu açılışında veri
tabanına verilir yani alocate edilir ve kapanana dek Oracle veri tabanında
kalır ve başka hiç bir işlem için kullanılmaz. “show parameter
sga;”
SGA kapsama alanlarına gireceğimizde de
göreceksiniz, cache lenen tüm veriler bu alanda saklanırlar. Kaynaklar Sga
alanını oldukça fazla verilmesi gerektiğini söyler öyleki veriler daha fazla
depolansın ve diske erişim azalsın.
i.Shared pool
1.
Libary cache
2.
Data dict. Cache
3.
Result cache
4.
User Global Area
Paylaşılmış
SQL alanıdır. Biliyoruz ki bir sql
çalıştırılmadan önce bir plan oluşturur. (İlk kez çalışıyorsa hard_parse yapılır sql ifadesi
hash’lenerek ona özel bir kimlik “SQL_ID” verilr.) Kabaca bu planlar burada
saklanır ve sonra bu sql yeniden çağırıldığında buradan yanıt döner. Her istek gelince parse etmeye uğraşmaz. Sql
query sonuçları, pl/sql blok sonuçları, pl/sql çalışma planlarını,Paralel çalışan
işlemler için gerekli memory alanı shared pool içerisinden kullanılır. Bu
işlemler gerçekleştiğinde önce buraya bakılır bu şekilde gereksiz yere diske
gidilmez.
Büyüklüğü SHARED_POOL_SIZE parametresi ile belirlenir. Default 64 mb (64 bit için)
Sık kullanılan sorguları daha hızlı getirmenin mantığı budur. SGA nın %10 kadar verilmelidir.
SQL > ALTER SYSTEM SET SHARED_POOL_SIZE = 64M;
Burada dikkat edilmesi gerek ayarlanan bu büyüklük SGA nın büyüklüğünü etkileyeceği için asla toplam SGA değeri SGA_MAX_SIZE’ı aşmamalıdır.
Kapsam olarak içinde Libary cache, data dictionary cache, result cache yapılarını barındırır.
Şunuda paylaşmakta fayda var. Örneğin bind kullanan bir sql ilk hard
parse yapıldığında verilen bind değişkenlerine göre en iyi cost hesaplanır.
Daha sonra gelen sql ler de bu plan üzerinden devam eder. Örneğin önceki bind
değişkeni geniş bir tarih aralığında ise o tabloya full okuma yapar ama sonra
daha dar bir tarih aralığı olsun bu sefer index üzerinden gidebilecekken bin
önceki plandan dolayı full gidebilir. (Bu ayrıntıları ile farklı bir
konudur)
1.Libary cache
Shared poolun en önemli ayrılmış alanlarındandır. Yakın geçmişinde
kullanılan sql cümlelerinin, planlarının, derlenmiş PL/SQL hallerinin
depolandığı alan diyebiliriz. Oracle çalıştırılan bir sql cümlesinin daha önce
kullanılıp kullanılmadığını ilk buradan kontrol eder. Eğer gelen sorgu daha önce
çalışmış ise oracle yeniden parse etmez ve hazır planı kullanır buna Soft parse denir. Eğer daha önce
çalışmamış ise sql’i parse eder ve libary cache içindeki shaered SQL Area ya
kaydeder bu olayada Hard Parse
denir. Bu alan dolduğunda eski parse edilen alanlar silinir yerine parse
edilenler eklenir. Hard parse konusu
başlı başına incelenmesi gereken bir durumdur. Büyük küçük harf farklılıkları
bile ASCI Karakter kodu farkı olduğu için farklı algılanır. Ve Libary cahce de
ayrı plan olarak tutulur. LRU (Least Recently Used) algoritmasına göre çalışır.
2.Data dictonary cache
Data dictonary içeriği oracle tarafından sık kullanıldığından bu
bilgiler cache de tutulmak istenir. Tüm bu bilgilerde shared pool içerisinde
data dictonary cache alanında barındırılır. Bu alan veri tabanının tüm
metadatasını, tablo yapıları, yetkileri vs. bilgileri tutar. Parse edilecek tüm
işlem öncesinde buraya bakar.
3.Result cache
Veri tabanı üzerinde çalışan sorguların sonuçları bu alanda saklanır.
Örneğin çok sık çalışan bir sorgu yada parametre vari , yada bir hesaplamayı
sürekle yeniden yapmaktansa bu alandan yeniden çağırır. Bazı sorgularda
RESULT_CACHE kullanımı ile bu alanda saklayabiliriz.
SQL> show parameter result
4.User Global Area
Oracle için gerekli bağlantı bilgileri vs. tipi bilgileri tutar.
ii. Buffer cache
(Veri tabanı tamponu) Tampon bölge olarak
mantığımıza kazıyabiliriz. Veritabanında çok sık kullanılan ve en güncel olan datalar
burada tutulur. Veritabanında
kullanıcı yada uygulama tarafından bir transaction başlatıldığı zaman o
transaction a ait dataların tutulduğu alandır. Database üzerinde DML
(INSERT/UPDATE ...) işlemleri yapıldığında değişen veri blokları önce data file
üzerine yazılmazlar. Örneğin: Personel tablosuna bir kayıt insert, update yada
delete yapıldığı zaman ilgili değişiklik direk olarak datafile lara yazılmaz
bir süre buffer cache de kirli data adıyla tutulur.
Bunlar database buffer cache yazılır (Dirty blocks) aynı şekilde select
cümlerleri de bloklardan okundukdan sonra buralarda tutulur. Sık kullanılan
veri blokları da burada tutulur diyebiliriz. Amaç veri erişimine hızlı
ulaşmaktır.
Çalışma mantığına bakarsak Datafile’dan okunan tüm veriler SGA
içerisinde burada tutulur Veri tabanında işlem yapan tüm kullanıcılar burayı
kullanırlar. Belirli bir sistematik sırası vardır. Buffer cache te write list
ve son kullanılanları tutan liste LRU (Least Recently Used) olarak 2 liste
vardır. Write list, dirty buffer denilen
üzerinde değişi klik yapılmış fakat henüz diske yazılmamış verileri tutar. LRU
ise boş olanları, henüz write liste gönderilmemiş dirty buffer bilgilerini ve o
an işlem gören alanları tutar (pinned buffer)
Kullanıcının veri okuma isteği olduğunda
önce bu cache’te varmı diye bakılır.Var ise veri bellekten direk olarak
okunur.Eğer yok ise veri ilgili datafile’ın bloğundan okunur.Ama bunu yapabilmesi için önce hafızada
boş alan bulunması gerekir.Bunun için
LRU listesine bakılır. Boş bir alan bulunana ya da tanımlı bir eşik değere
ulaşıncaya kadar arama sürer. LRU listesinde Dirty buffer bulunca bu alan write
liste’e alınır ve arama işlemi sürdürülür, boş alan bulununca burası LRU
listesinin en sonuna atılarak ilgili veri bulunan boş alanına yazılır.Boş
alan bulunamadığı esnada belirlenen eşik değerine ulaşılınca LRU listesinde
arama bitirilir ve DBW0 background process’ine bir takım dirty buffer alanını
diske yazması için sinyal gönderilir.
Buffer cache de bulunan veri nin data fillere yazılmasına oracle karar
verir. Commit işlemi aldıktan sonra bu verinin garantiliği redo loglara yazar
ve sonra oracle uygun zamanda bunu dosyalara yazar check point işlemi
yapılamadan ve Cache dolmadığı sürece Database buffer cache diske yazma işlemi
yapmaz. Bu arada diske yazma işlemini DBW(database wrieter) backroun processi
yapar.
Buffer cache oranı kuruluş sırasında belirlenir ve kaynaklara göre ne
kadar büyük olursa oldukça performans sağlar. “DB_CACHE_SIZE” ile ayarlanır.
DB_KEEP_CACHE_SIZE Blokların default olarak ne kadar tutulacağını belirleyen
parametredir. DB_RECYLE_CACHE_SIZE ise
kullanılmayan blokaların boyutunu.
Db buffer cache LRU(Least Recently Used) algoritmasına göre eski
verileri cacheden temizler. Bu algoritma az kullanılan verileri listeleyip
temizler buna “Cache miss” denir.
iii.Log Buffer (Redo Log buffer
– Log Tamponu)
Instance çöktüğünde ya da bir sorun olduğunda recover işlemi için
gerekli olan bilgiler burada saklanır. Verilerin en sık giriş çıkış yaptığı alan
olarak düşünebiliriz. Örneğin bir tabloda değişen bir satırın tamaı değil
yalnızca değişen sütünların (Delta )yeni halleri yazılır. Eski halleride UNDO
yazılır. Olası bir ROLLBACK işleminde UNDO dan geri gelir. INSERT/UPDATE/DELETE/CREATE/ALTER/ ve DROP
işlemleri sonucu oluşan değişiklikler öncelikle burada tutulur. COMMIT komutunun çalıştırılmasından sonra LGWR
Log bufferdaki veriyi redo log dosyalarına yazar. Log Buffer parametresi redo
log alanının büyüklüğünü belirler.
iv.Large pool
Veri tabanı üzerinde çalıştırılacak büyük işlemler için bu bellek
kullanılır
Yedekleme mekanizmaları, Backup alma, Export,Import, Parallel sql
sorguları gibi durumların kullandığı bir alandır.
v.Java pool
Java kodlarının veri tabanı içerisinde konumlandırılması için
kullanılmaktadır. Java tabanlı
procedürlere sahipsenniz bu prosedürler java poolu kullanır.
vi.Streams pool
Replikasyon için kullanılır. Aslında şimdi bunun yerine DataGuard
kullanılıyor.
vii.Keep Buffer pool
Veri
tabanının buffer cacheinden ayrı bi alandır. Buffer cacheteki
mantıkla aynıdır. Hatırlayalım buffer cache dolduğunda en ez
kullanılan veri dışarı atılmaktaydı. Belirleyeceğimiz sık kullanılan
verileri keep buffer pool alanına çekeriz ve mümkün olduğu kadar uzun
tutmasını sağlayabiliriz. Opsiyoneldir.
1.2 ) PGA (Program global Area)
Kısa bir
tanım yapmak gerekirse, kullanıcıların yapmış olduğu SQL sorgularının
sonuçları private area üzerinde saklanır. Oracle veri tabanının bu
bölgede kullandığı alan ise PGA (Program Global Area) olarak
adlandırılır. PGA için ayrılacak belleği hesaplamak için kullanıcı
sayısını 40 MB ile çarpmak yeterli olacaktır. Bu alan sunucu
işlemlerinin, arka plan vs gibi işlemler için ayrılmış alandır.
Pga_aggregate_target parametresi ile ayarlanır. Oracle db ye bağlanan her
kullanıcı için sistem ram den private area (Paylaşılmayan alan) bir bellek
ayırır bu alana PGA denilir.
Select * from V$PGASTAT order by value;
PGA, Oracle kullanan her bir process (server
process)için bellekte reserve edilen alandır.Kullanıcı tarafından
gelen isteğe User proses, user prosesi oracle serverde karşılayan process
de server proces s ‘ dir.
Örnekte görüldüğü gibi veritabanı kullanıcısı tarafından
talep edilen bir sql cümlesini olduğunu düşünelim. Oracle Net yardımı ile
Client tarafında oluşturulmuş bir “User process1” olduğunu
varsayalım.Gelen talep doğrultusunda server tarafında Listener(dinleyici)
aşamasını geçtikten sonra Oracle server tarafında bir “Server
process1” isimli process oluşacaktır.
User
prosess, bir kullanıcı uygulama yada bir tool aracılığı ile, oracle
server ile bağlantı kuran bir program, Oracle client yada sql plusda olabilir
bir user process başlatır. User prosess server prosess ile iletişim kurduğunda
bir session açılır ve işlemler bunun üzerinden yürür.
Database Process:
Oracle tarafından oluşturulan bağlantıdır. Bu processlerin bir
kısmı Background Process bir kısmı da Server Process’lerdir.
Server prosses, User prosesse
karşılık gelen prosessdir. Gelen istek ile beraber Oracle server ile bağlantı
kurar. Dedicated yada Shared olabilir.
Dedicated Server Process ve Shared Server Process.Dedicated Server
Process her User Process’ e karşılık bir Server Process vardır.Bire bir ilişki
olduğundan Shared Server Process’ e göre daha hızlıdır.Shared Server Process’de
ise bire bir ilişki yoktur,birden çok Client Process’e karşılık 1 Server
process üzerinden bağlanabilir.
llanıcı
Oracle’a bağlanarak bir işlem yaptığında ya da tablolardan veri okumaya
çalıştığında ya da çalıştırdığı program sonuç dönmek istediğinde server
process’ler oluşturulur.
Memory’nin
son kısmıdır, ne zaman bir sorgu atarsak ve o sorguyu bir düzen dahilinde
görmek istersek memory tarafında bu işlem PGA (Program Global
Area) tarafından gerçekleştirilir.
PGA alanına
ayrılan bellek yetmediğinde sıralama ya da verinin düzenlenme işlemi database
tarafında storage alanında bulunan Temp File’ında yapılır.
2. PROCESS Birimleri (BACKGROUND PROCESS)
Backround prosess:
Bu prosessler fiziksel ve belleksel yapı arasında
çalışırlar. Oracle
açıldığı andan kapatıldığı zamana kadar ki süre içerisinde bir
takım process’ler veritabanının işlevlerini yapmasını sağlamaktadır. Bu
processler SGA ve PGA bellek yapılarıyla bir araya gelerek
Oracle veritabanı instance olarak bilinen yapıyı oluşturmaktalar.
Oracle 11G veri tabanı açık ve çalışıyorsa arka planda mutlaka process’ler
çalışıyor olacaktır. Windows işletim sisteminde process olarak
sadece oracle.exe olarak görünmektedir. Ancak diğer işletim
sistemlerinde bir den çok process görünmektedir ve Windows hariç
diğer bütün işletim sistemlerinde birkaç processi kapatabiliriz ancak
windowsta kapatılamaz.
2.1-) DBWR(Database writer) görevi, bos bellek alanı bulabilmeleri
için database buffer cache ‘i yönetir. Degisiklige
ugramis tüm verileri (DML ile) veri bloklarını buffer cache den alıp veri
kütüklerine (data file) yazar. Unutulmaması adına yeri gelmişken Yakin zamanda
kullanilan veri bloklarini bellekte tutmak için LRU (Least Recently Used)
algoritmasini kullanilir.
DBWR (Database write
prosess) şu durumlarda aktif olur.
• Incremental yada normal checkpoint oluşmuşsa
•
Bozuk data bloklar eşik değeri eriştiklerinde
•
Bir proses boş blok aradığında ama bulamadığında
/ Database buffer cache dolduysa
•
Zaman aşımı
gerçekleştiğinde
•
RAC
kontrolünde
•
Tablepsace
Online yada Offline olduğunda.
•
Tablespace
Read Only moduna geldiğinde.
•
Tablonun drop
yada Truncate edilmesinde.
•
ALTER
TABLESPACE tablespace name BEGIN BACKUP komutu çalıştığında
Yazma işlemi sırasıyla SGA içerisinde
yer alan Log Buffer alanına ve
ardından LGWR işlemiyle Online Redo Log dosyalarına
yazılır. Daha sonra DBWn Process’i değişmiş olan veriyi son
haliyle Datafile dosyalarına yazar.
2.2 -) LGWR
(Log writer) prosessi
oldukça önemlidir. Redo log buffer ve online redo log arasında yazma işlemleri
yapar. Şu durumlarda redo log buffer alanındaki
bilgileri diskteki Online Redo log file yazar
·
Transaction commit görüldügünde
·
redo log buffer dolulugu esik degerine ulastigi
zaman
·
DBWR checkpoint için buffer bloklarin
temizlemeye gerek duyarsa
·
time-out görülürse
·
Her Oracle instance ‘i için bir tane LGWR görevi
vardir.
Bir
transaction redo log kütügüne islenmeden commit edilmis sayilmaz. DBWR görevi,
veri bloklarini veritabanina geri yazmadan önce yapilan degisiklikleri korumak
amaciyla LGWR görevine redo log buffer ‘larini bosaltmasi sinyalini gönderir.
2.3 ) Checkpoint (CKPT)
Databasedeki tutarlılığı sağlar.
Checkpoint bir tür sistem değiştirme numaraları saklayan veri birimleridir.
DB olağan dışı kapandığında smon
prosessi redo log dosyaları ile kurtarma işini yaparlar. Bu operasyon
database’in tekrar açılmasını doğrudan etkileyeceğinden Checkpoint process bu
durumda kurtarma süresini en aza indirmekle görevlidir. Checkpoint Process,Databasedeki
checkpoint işlemini gerçekleştirmekle görevlidir. Control File’lere
ve Data File’lere yazılır. System
bir checkpoint oluşturduğunda control file’lerin içeriğini
veData File headerların güncelleme işlemini Checkpoint
process üstlenir.Checkpoint demek;değişen bilgileri(database buffer
cachedeki) datafile’a atma işlemidir.Bu işlem sürerken Control
File dosyalarını günceller.Control File dosyaları Database’imiz için
hayatı önem taşır.
Alter system Checkpoint ;
Full checkpoint çok zaman aldıgından istersek partiol
checkpoint(parçalı checkpoint)’de yapabiliriz.Parçalı checkpointi
tablespace’e,datafile ‘e uygulayabiliriz.
NOT : Checkpoint çok sık aralılarla meydana gelirse
sürekli olarak diskte ki dosyalar güncellendiginden sistemde yavaşlama
olabilir.Eger checkpoint olayı çok az aralıklar ile meydan gelirse de bu durum
Instance arızası durumunda geri kurtarma işleminin süresini uzatacaktır.
2.4 ) SMON (System Monitor Processes) Veritabanının NOMOUNT modunda başlamasının
ardından OPEN modunda tam açıldıgı ana kadar gerçekleştirilmesi gereken denetim
işlemlerini SMON prosesi yürütür.
Biraz açacak olursak Oracle ilk
açıldıgında “init.ora” dosyasını okuyacaktır ve bu aşama
veritabanının NOMOUNT modda oldugu aşamadır. Bunun ardından SMON controlfile
dosyasına erişir ve burada ki bilgilerin geçerliligini denetler bu süreç
başarıyla tamamlanırsa MOUNT moda geçer.Daha sonra ise SMON,veritabanına ait
tüm datafile dosyalarının yerlerini kontrol eder yerlerinde olup
olmadıklarına bakar, SMON bu denetlemeden sonra son olarak da redo log
dosyalarının konumlarını ve içeriklerini kontrol eder. Tüm denetlemelerin
başarıyla sonuçlanmasıyla birlikte veritabanı kullanıma açılır
yani OPEN moda geçer.
NOT : SMON aynı zaman da Oracle ‘ın bir hata sonucu
kapanması sonucunda açılırken devreye girer ve redo log dosyaları sayesinde
recovery işlemini yapar.
SMON aynı zamanda kullanılmayan geçici parçaları(temporary
segment) temizlemekte ve birleştirmektedir.
2.5) PMON (Processes
Monitor)
PMON herhangi bir user(kullanıcı) prosesi bozuldugunda o
prosesin kurtarılmasını saglamaktadır. PMON bozulan prosesin kullandıgı bellegi
ve kaynakları temizlemekte ve proses tarafından tutulan kaynakları serbest
bırakılmasından sorumludur. Bir kullanıcı process’ i fail olduğunda process
recovery işlemini PMON yapar.
Bu noktada Database buffer cache yi temizlemek bu user
tarafından kullanılan kaynakları tekrar kullanılabilir yapmak Pmon
görevlerindendir.Ayrıca timeout olan veya askıda kalan session ların izlenmesi
ve ayrıca listener yardımları ile database servisleri register etmekte yine
Pmon tarafından yapılır.
PMON aynı zamanda dispatcher ve sunucu işlemlerini kontrol
eder ve kapandıklarında yeniden çalıştırır/PMON periyodik olarak çalıştırılır
ve uyarılır.
2.6) RECOVER PROCESSES
(RECO) Dağınık database configurasyonları ile birlikte kullnılır. RECO
process otomotik olarak , fail olma olasılığı olan transactionlara sahip
databaselere bağlanır.Ve bu şüpheli transactionların çözümlenmesini
yapar.Sonrasında bu şüpheli transactionlara uygun kayıtları siler.
2.7) ARCn (Archiver
Processes:)
Veri tabanında
yapılan insert, update ve delete işlemleri ile yapılan
değişiklikler anında datafile’lere yazılmadığından
bahsetmiştik. DML komutları ile yapılan değişiklikler ilk olarak SGA içindeki Log
Buffer Cache’e kaydedilirler. Sonrasında diskteki Online Redo
Log dosyalarına yazılırlar. LGWR işlemi
ile SGA altındaki Log Bufferda yer alan veriler
1’nci Redo Log Dosyasından yazmaya başlar, 3’ncü dosya dolduğunda ki
dosya boyutları varsayılan olarak 50 mb’dir, 1’nci dosyanın üzerine yazmaya
başlar. Buda 1’nci dosyadaki verilerin silinmesi anlamına gelir ki biz bunu
istemeyiz. Yazma işlemi 1’nci dosyaya geçmeden yedeklenmesi
gerekmektedir. Online Redo Log yazılma işlemleri biter bitmez yedeği
bir başka konuma kopyalanır bu işlem Archiving (Arşivleme) işlemidir.
Bu yedeklenen dosyalar artık Archivelog olarak adlandırılır.
2.8) Process Startup
Sequence: Bu özellik 11G R2 ile gelen bir özelliktir. Oracle 11G R2
sistemlere kadar Linux bir işletim sistemi başlattığımızda bazı önemli
servisleri start etmezdi. ASM instance, Listener, DB Instance gibi.
Bu servisleri manuel olarak start etmemiz gerekirdi. Bu servislerin
start olmasını sağlanyan processdir. Bunun
için Grid Insfrasttucture yüklemiş olmamız gerekmekte.
2.9) MEMORY
MANAGER(MMAN)-(Bellek Yönetimi)
Oracle veritabanında arkaplan görevlerini yürütmekle yükümlü
olan arkaplan prosesidir.Biraz açacak olursak Oracle 11g database server ile
bellek yönetimi daha da gelişti,veritabanın kurulumu esnasında veya sonradan
yapılandırmak suretiyle Oracle Instance tarafından kullanılabilecek en yüksek
SGA ve PGA degerlerini bildirip ihtiyaca göre dagılım ve kullanım yönetimi
yapılması işini tamamen Oracle’a bırakabilmekteyiz.İstersel Oracle Instance
toplam kullanmasını istedigimiz RAM miktarını verip SGA ve PGA arasında ki
dagılımı bile yönettirebiliriz.
MMAN aynı zamanda Oracle için ayrılan fakat kullanılmayan
RAM bellegini ,işletim sistemine devreder ve ihtiyaç harinde geri alabilir.
2.10 )MANAGEBILITY
MONITOR (MMON)
Oracle veritabanının arka planda yürütmesi gereken bakım ve
izleme görevlerini gerçekleştirmesinden sorumludur.Oracle MMON prosesini
kullanarak kullanım istatistiklerini ,performans istatistiklerini ve otomatik
bakım için gerekli bilgileri toplar
MMON işleminin görevi SGA bellek alanında bulunan kullanıma
hazır ve bakıma yönelik istatiksel bilgileri her saat başında veritabanına
yazmaktır.MMON tarafından SGA bellek alanından toplanan bu bilgiler data
dictionary bölgesine yazılırlar.Varsayılan olarak 8 gün burada saklanılırlar.
MMON işlemi çalıştıgı her seferde,SGA bellek alanından
istatiksel bilgiler toplamanın yanısıra,Oracle ADDM(Automatic Database
Diagnostics Monitor) bileşinini de tetikleyerek çalışmasına sebep olur.ADDM
çalıştıgı zaman data dictionary bölgesine en son yazılan istatiksel
bilgileriyler bir önce ki seferde yazılmış olanları karşılaştırarak bir
performans hesaplaması yapar.Gerekli görürse DBA için uyarılar oluşturabilir.
2.11 ) SPACE
MANAGEMENT COORDINATOR (SMCO) (Alan Yönetim Koordinatörü)
SMCO arkaplan prosesi fiziksel disklerde yer alan ve
Oracle’ın kullanmakta oldugu datafile dosyalarının boyut ve kapasite
yönetiminden sorumludur.Oracle veritabanına yeni veriler eklendikçe datafile
dosyalarının boyut olarak artması gerekecektir,benzer şekilde silinen verilerin
daha önce kullanmış oldukları datafile içinde ki bloklarıda tekrar
kullanılabilir hale getirir.
2.12 ) JOB QUEUE
PROCESSES(Jnnn)-(İş Kuyrugu İşlemleri)
Job Queue Processe atılan işlerin belirlenen zamanlarda çalışmasını
saglar.İşlem sırasıyla aşagıda ki şekilde gerçekleşir.
JOBS tablosundan zamanı gelmiş yapılacak işleri
seçer.Dinamik olarak işleri yürüten bir köle iş kurugu(slave job queue)
oluşturulur.
Job Queue Process seçilen işlerden birini çalıştırır.(Senkron
olarak). Seçilecek iş yoksa uyku moduna geçer ve daha sonra periyodik olarak
“iş var mı” diye denetler.
2.13) QUEUE MONITOR
PROCESSES(QMNn)
Gelişmiş kuyrukları denetler ve bir mesaj elverişli hale
geldiginde bekleyeneleri haberdar ederler.Ayrıca kuyruk oluşturulmasından da
sorumludur.
3.
STORAGE (DEPOLA) BİRİMLERİ (PHYSICAL
FILES)
Veri Tabanının
Mantıksal Yapısı: Mantıksal yapılar
tabiki anlaşılabileceği gibi fiziksel yapılar
içierisinde bulunur. Oracle veri
tabanı yönetilebilmesini kolaylaştırmak amacıyla mantıksal olarak daha küçük
parçalara ayrılmıştır. Ve her parça bir sonrakini oluşturur. Mantıksal yapıda
bulunan parçalar, tablespace, segment, extent ve blocklardan ve schema(şema)lardan
oluşmaktadır. Blocklar extentleri, extentler segmentleri ve segmentler tablespaceleri
oluşturmaktadır.
1. Tablespace:
Tablespace için mantıksal yapıların tamamını gruplandıran mantıksal bir
depolama alanıdır tanımlamasını yapabiliriz . Fiziksel olarak datafile, mantıksal olarak tablespace ismini
almaktadır diyebiliriz. Buna göre datafilelerin toplam boyutu tabalespacein
boyutunu, tablespacelerin boyutu ise bize databasein toplam boyutunu
verir.
2. Schema (Şema) objeleri: İçerisinde
tablolar, viewlar, indexler ve kümeler bulunmaktadır. Kullanıcı tarafından
kullanılır ve kullanıcı adı ile bilirir. Tablo, view, prosedure, fonksiyon,
paket, trigger, index … vs gibi mantıksal database objelerinin tutulduğu, yani
database ‘e ait bir yapıdır.
3. Data
Blokları: Oracle Databaseinin verileri data bloklarında saklanır. Bir data
bloğu en az 8 KB boyutunda olmaktadır, en fazla ise 64MB boyutunda
olmaktadır. Oluşturulan tablespace için datablok sayısı belirlenebilir. Database data
bloklarını ayırabileceği gibi, kullanabilirde.
4. Extent: Extentler
birbirlerini takip eden Data blocklar ‘dan meydan gelir. en düşük boyutu 64
KB’dir.
5. Segments:
Segmentlerde
birbirlerini takip eden extentlerden oluşur. Bir segment; veri segmenti İndex
segmenti, undo segmetni yada temporary segment olabilir.
Data Segment: Bir tablo
oluşturulur oluşturulmaz daha veri girmeden alanı ayrılan yapıdır. Doldugunda
otomatik olarak extendler bu data segment için ayrılır.
Index Segment: Her bir index ‘in verisi için oluşturulur.
Temproray Segment: Bir SQL çalıştırıldığında gerek
duyulursa Oracle tarafından kullanılır. İşlem bittiğinde bu alan sistemin
kullanımı için kullanılır.
Rollback Segment: Rollback işlemlerinde kullanılır.
Veri Tabanının
Fiziksel Yapısı:
Fziksel disk üzerinde bulunan ve işletim sisteminde
gördüğümüz dosylardır. Birden fazla datafile, birden fazla logfile ve
birden fazla controlfileden oluşabilir
1. Control
Files (Kontrol Dosyaları): Kısaca bahsetmek gerekirse Control file
oracle DB nin olmaz ise olmazıdır (Çünkü sadece Control file konusu ayrıca
incelenmelidir).
İçerisinde Online Redo Log dosyalarının, Data
Fileların ve Archive Log dosylarının nerde tutulduğunun bilgisi ve Checkpoint işlemlerine
ait bilgiler bulunur. RMAN (Recovery Manager) ile yedek alındıysa,
yedekleme bilgileri gibi neyin nerede olduğuna dair veri tabanı bilgileri
bulunmaktadır. Ayrıca güncel SCN (System Change Number) de control
file içerisinde bulunmaktadır. Database ismi, database archivelog modda
çalşıyorsa, archivelog dosyalarının bilgisi gibi bütün fiziksel
yapıya ait bilgiler control filede bulunmaktadır. Veri tabanı açık
durumdaysa Control File kopyalanamaz. Eğer Control File herhangi
bir sebepten dolayı bozulur ya da silinirse, Veri Tabanı kapanır ve çalışmaz.
Bu yüzden yedek alınmalıdır. Yedekleme işlemi Recovery Manager ile
yapılabilmektedir. 3. Party bir yazılım ile de alınabilir ancak bütün 3. Parti
yedekleme yazılımları arka planda RMAN kullanmak zorundadırlar. Control
File’lar binary değerdedir ve üzerlerinde değişiklik yapılamaz.
Veri tabanında eğer FRA oluşturulmuşsa 2 tane control
file bulunmaktadır. Biri +DATA diğeri +FRA içerisinde
dir. Ancak biz bu sayıyı istersek yükseltebiliriz. Bunu yapmak istersek
bilinmesi gereken başka bir lokasyonda tutulursa daha güvenli olacak ve başka
bir lokoasyonda control file yedeğini saklamış olacağız. Eğer +DATA içerisindeki control
file dosyasını kaybedersek +FRA da olmasına rağmen veri tabanı
çalışmayacaktır. Bu durumda SPFile içerisinden +DATA ya ait
bilgi silinir ya da +FRA daki control file diğeriyle
birebir aynı olduğunda +DATA altına kopyalayarak eklenebilir. SPFile üzerinde
değişikliğin nasıl olacağı bilgisi SPFile konusunda inceleyeceğiz.
İstersek enterprise manager üzerindende değiştirilebilir ki enterprise
manager konusunuda inceleyeceğiz, istersek RMAN ile +FRA’dan dönüş
yapabiliriz. RMAN ile ilgili konuyu başka konularda detaylı olarak
inceleyeceğiz.
2. Data Files (Veri
Dosyaları): Data Files (Veri Dosyaları): Tüm verilerin fiziksel olarak tutulduğu
dosyalardır. System, undo, sysaux, users ve Temp datafileleri
default kurulumda gelir.
è Sysaux: enterprise manager bu dosya ile
çalışır. Enterprise manager AVR raporları burada saklanır. Enterprise
manager repository’nin tutulduğu yer bu tablespace’dir.
è
System: içerisinde Data Dictionary bulunmaktadır.
èTemp: geçici
olarak oluşturduğumuz tablolar burada oluşturulur. create temporary table
komutuyla bir tablo oluşturduğumuzda yapılmak istenen işlemler yapıldıktan
sonra ilk commit ya da rollback yapıldığında bu tablo
silinecektir. Raporlama ağırlıklı sistemlerde analizler gerçekleştirirken veri
düzenli bir şekilde (group by gibi) gelmelidir. Server processin aldığı kaynak (PGA) içerisinde
sourt area bulunmakta, sourt alanında düzenleme işlemi yapılır ki veri çok
büyük olduğunda o alan yetmez. Alanın yetmediği durumlarda o düzenleme işlemini temp üzerinde
yapar.
è
Undo: Yapılan update, delete, insert işlemleri ile girilen işlemlerin eski
halleri burada tutulur. (İlerki konularda daha detaylı değineceğiz.)
è
Users: bu datafile kurulumla gelir ve varsayılan tablespace olarak atanır.
3.Online Redo Log: Kısaca
redo loglar oracle'de yapilan islemlerin datafilelere yazilmadan önce tutuldugu
dosyalardir. (Sadece Redo log konusu ayrıca incelenmelidir.) Bir veritabanı iki
veya daha fazla redo log dosyasından oluşur. En az iki olmasının nedeni,
archivelog şeklinde çalışıyorsanız, redo log dosyalarından bir tanesi
kullanılırken diğeri arşive çıkılabilsin diyedir. Böylece her zaman çalışabilir
olmayı sağlar. Çalışma mantığına
bakarsak LGWR, bir sonraki redo log dosyasına geçtiğinde, bir önceki redo log
dosyasının durumunu controlfile içinde CURRENT’ten ACTIVE’e çevirir. (Bir
sonraki bölümde, bu statüler açıklanmıştır.) Akabinde DBWR (Database Writer)
işlemini durumdan haberdar ederek, bir önceki redo log dosyasında checkpoint
işlemi yapmasını gerektiğini belirtir. DBWR tarafından checkpoint işlemi
tamamlanıp, redo log’daki değişiklikler veritabanı dosyalarına yazıldığında
CKPT process’i çağrılır. CKPT işlemi veritabanı dosyalarının header bilgilerini
ve check point bilgisini (sadece) controlfile içerisinde günceller.
Veritabanının ihtiyacına göre RedoLoglar eklenebilir yeni
grouplar oluşturulabilir, mevcut gruplara member eklenebilir. Silinebilir. (Bunu
da ayrıca Redo log Konusunda inceleyeceğiz)
4. Paramater
File: Oracle instance yapılandırma bilgileri burada tutulur. Ayrıca
içerisinde bütün dosyaların bilgisi ve control file’ın bilgisi var. “SPFILE”
ve “PFILE” dosya adıdır.
5. Password
File: Password file adından da anlaşılacağı üzere oracle kullanıcı
şifrelerini tutan bir dosyadır. Oracle Password file Linux sistemlerde $ORACLE_HOME/dbs klasörü altında orapw$ORACLE_SID isim formatında
bulunmakta Oracle Password dosyasında bilgiler encrypted olarak tutulur.
6. Backup
File: Database’i recover yapmak için kullanılan alandır. Datafile’ların
birebir kopyalarıdır.
7. Archived
Redo Log Files: Online Redo Log File’larının birebir yedeğidir. Bir redolog dosyası
dolduğu anda başka bir dizine yedeği alınır.
8. Trace
amd Alert Files: Server ve background processlerin kayıtlarının
tutulduğu, hataların yazıldığı dosyalardır. Bu dosyalardan faydalanarak
processler izlenebilir, sessionlar görülebilir. Bir DBA olarak her durumda
bakıp bilgi alabileceğimiz yerdir...
Ayrıntıları ile Oracle VeriTabanı mimarisine girmiş olduk. Umarım faydalı olmuştur.
İyi Çalışmalar...
2 yorum:
harika olmus tesekkurluk emeyinize saglik!
Teşekkür ederiz, elinize sağlık.
Yorum Gönder