Oracle Veritabanı Mimarisi
Veritabanında da herhangi bir sıkıntı oldugunda, mimariye ne kadar hakim olursak nereye müdahale etmemiz gerektiğini daha iyi biliriz ve çok daha hızlı müdahale ederiz. Bundan dolayı bugünki yazımda Oracle veritabanı mimarisindeki önemli yapılardan kısaca bahsetmek istedim.
Temel mimari yapısını en iyi özetleyen görsel aşağıdaki gibidir, ben de elimden geldiğince özetle bu yapılardan bahsedeceğim.
Oracle veritabanı mimarisi aşağıdaki 3 yapı üzerine kurulmuştur:
- Bellek Yapısı (Memory Structure)
- Arkaplan İşlemleri Yapısı (Background Processes Structure)
- Depolama Yapısı (Storage Structure)
Oracle Veritabanı çalıştığı zaman işletim sistemi üzerinde shared global area( SGA) dediğimiz bir memory alanı Oracle için allocate edilir ve aynı zamanda Oracle tarafından background process ler dediğimiz bazı processler veritabanına gelen talepleri karşılamak için başlatılır.
Oracle işlemleri mümkün olduğunca memory de yapmaya çalışır.Bunun nedeni, diskten yapılan işlerin maliyeti (cost) memory den yapılan işlerin maliyeti arasında ciddi farkların olmasıdır.
→ Bellekteki veriler kalıcı değil, sunucu kapanırsa hepsi gider. Diskteki veriler ise kalıcıdır
1. BELLEK (Memory) YAPISI:
Oracle veritabanı bellek yapısında 2 önemli alan var:
Sistem Global Alanı (System Global Area) 🡪 SGA :
Oracle instance sı işletim sistemi üzerinde başladığı zaman kurulumunda belirttiğimiz SGA değeri kadar bir alan Oracle tarafından işletim sisteminden allocate edilir işte bu alana System Global area denir.
HATIRLATMA: Örnek kurulum ekranı:
[Use Automatic Memory Management] kutucuğunu işaretleyerek bellek yönetimini Oracle’a bırakılması.
Custom seçersek SGA ve PGA alanlarımızı kendimiz belirleyebiliriz.
Program Global Alanı (Program Global Area) 🡪 PGA
Program Global Area paylaşılmamış bellek alanıdır. Bir sunucu işlemi (Server Process) başlatıldığı zaman, sunucu fiziksel belleğinde tahsis edilir. Server Process sonlanıncaya kadar PGA kullanılır.
PGA Nerede Çalışır? :
User Process: Toad, sql* plus
Server User: Veritabanının çalıştığı sunucuda
SGA Bileşeleri : Database Buffer Cache
* Veritabanında kullanıcı yada uygulama tarafından bir transaction başlatıldığı zaman o transaction a ait dataların tutulduğu alandır.
*Insert, Update, Delete gibi DML işlemleri veritabanındaki veri dosyalarına hemen yazılmaz. İlk olarak değiştirilen veri Buffer Cache’de tutulur. Tampon alanda değişen bu veri bloklarına “Dirty Blocks” denir. Yani kullanıcı tarafından değiştirilmiş tampon bölgede tutulan, fiziksel diskteki veri dosyalarına yazılmamış veridir. Bu bloklar veri dosyalarına yazıldıktan sonra “Clean Blocks” olarak adlandırılır.
Dirty Blocks’ları Clean Blocks’lara çevirme aşaması ise arka plan işlemi DBW(n) tarafından gerçekleştirilir. Veritabanı tampon alanı boşaltma işlemi; Random yazar
- Buffer cache manuelolarak boşatılmasını istersek aşağıdaki komut ile bunu gerçekleştirebiliriz.
SQL> alter system flush buffer_cache;
NOT: Canlı sistemlerde ihtiyaç duyulmadıkça yapılmaması gerekiyor çünkü buffer cache boşaltıldığı zaman çekilen tüm sorgular yada transactionlar fiziksel diskten I/O yapacaktır buda sorgularımızın yavaşlamasına sebep olmaktadır.
Peki DBWn proccesleri hangi durumlarda Buffer cache’deki (memory) değişen blokları Data File’a (Diske) yazar?
DBWn process ler aşağıdaki olaylar gerçekleştiği zaman çalışır ve Buffer Cache deki değişen bloklar data file lara yazar.
- Database buffer cache de alan dolduğu zaman en eski bloklardan başlanarak datafile lara yazma işlemi başlar.
- Bir tablespace read-only moduna getirildiği zaman.
- Bir tablespace offline duruma getirildiği zaman.
- Herhangi bir tablo drop yada truncate edildiği zaman.
- Checkpoint process i aşağıdaki komut ile manuel olarak tetiklendiğinde
SQL>Alter system checkpoint;
Datafile Konumuna Bakma:
Datafile’ın konumuna aşağıdaki komut ile bakabilmekteyiz
SQL> Select name from v$datafile;
NOT: DBW(n) işleminin sonundaki n harfi, birden fazla DBW işleminin aynı anda çalışabilmesinin mümkün olduğunu gösterir.
SGA Bileşeleri : Redo Log Buffer
*Veritabanı üzerinde çalıştırılan her DML ve DDL işlemi (transaction) işleminin kendisini tutar. Bu kayıt bilgilerine “redo” denir.
*Kullanıcı yada uygulama bir transaction başlattığı zaman bu transaction ın kaydı ilk olarak Redo log buffer a yazılır.
Peki ne zaman Redo log buffer cache’deki (memory) transactionlar Online Redo Log File’a (diskte) yazılır?
Aşağıdaki durumlarda Redo log buffer alanındaki kayıtlar LGWR processi tarafından Online Redo log dosyalarınayazılır
- Kullanıcı bir transaction sonucunda Commit gerçekleştirdiğinde
- Online Redo log grupları switch ettiği zaman (Log switch)
- Her 3 saniyede 1
- Ortalama 1 mb lık Redo log oluştuğu zaman
- Redo log buffer alanının 3 te 1 i dolduğu zaman
SGA Bileşeleri : Online Redo Log File
Default da varsayılan olarak her biri 50 mb’lık olacak şekilde 3 redolog gelir. Eğer 1. dolarsa 2. ye gecer 2. dolarsa 3. ye. 3 dolarsa 1’in üzerinde yazmaya başlar. 50 mb ihtiyaca göre arttırılır. Trasaction sayısna göre vereceğiz bunu. Yapılan transactionlar burayı etkiliyor. Select etkilemiyor.
Eğer database Arşiv modundaysa buradaki dosyalarda belirli aralıklarla switch olarak ARCn process’i tarafından arşivlenir, yani bir nevi yedeği alınır. Bundan dolayı da veritabanımız veri kaybı istemiyorsak kritikse kesinlikle arşiv modda olmalıdır.
**Redo log dosyasının RMAN de backup alınmaz. Redolog dosyasını arşiv almak için switch edersin.
NOT:Online redologlar switch olurken, arka taraftan gelen işleleri almaz hang olur, arşive cıktıktan sonra kaydetmeye devam edr. Log file switch completion da bütün işlemler bekler. Transaction yogunsa cok switch olur bu cok sık olmamalı.Size çok büyütürsen 10 gb mesela db arşiv cıkmadan göçtü o zaman 9 gb lık kayıp riskimiz var.Redolog default 50 mb ama direk arrtıramaıyız, yeni member olusturup daha yüksek size lı sonra eskileri arşivleri çıkartıp drop etmemiz lazım.
Aşağıdaki görselde arşiv modunda olduğundaki işleyiş mantığı özetlenmiştir. Daha ayrıntılı anlatım için arşiv modua alma yazıma buradan ulaşabilirsiniz
- Aşağıdaki komut ile manuel olarak switch olmasını sağlayabiliriz.
ALTER SYSTEM SWITCH LOGFILE;
- Eğer her 15 dakikada bir otomatik switch olmasını istersek aşağıdaki komut ile gerekli setlemeyi yapabilirsiniz
ALTER SYSTEM SET ARCHIVE_LAG_TARGET = 900 scope=both;
NOT: Burada dikkat edilmesi gereken sistem yoğunluğuna göre ayarlama yapılmasıdır tabi ki işlek veritabanlarında default da gelen 50 mb lık redo log dosyaları yeterli gelmeyecektir bu şekilde sürekli switch olacağından sistemi boşa yoracaktır. En az veri kaybı olacak şekilde her duruma karşı önlem alınmalı ve ona göre yapılandırılmalıdır.
- Online redo log dosyalarının nerede tutulduğunu aşağıdaki sorguyla görebilirsiniz. :
SQL> select * from v$log;
SGA Bileşeleri : Shared Pool (Ortak Alan):
Paylaşılmış SQL alanıdır.
- Veritabanına gelen tüm transactionlara ait queryler burada tutulur
- Bunların execution planları (Çalışma planları) burada tutulur
- PL/SQL kodlarının parse edilmiş ve derlenmiş halleri burada tutulur
SGA Bileşenleri : Shared Pool Bileşenleri : Library Cache:
Oracle veritabanına bir SQL cümleciği geldiği zaman Oracle ilk olarak bu SQL cümleciğinin daha önce çalıştırılıp çalıştırılmadığına Library cache e bakarak anlar.
🡪 Eğer atılan sorgu daha önce çalıştırılmışsa Oracle bu SQL i tekrardan parse etmeden önceki execution planı kullanır bu işleme soft parse da denir.
🡪Eğer gelen sorgu daha önce çalıştırılmamışsa oracle çalıştırılan SQL i parse edip library cache de bulunan Shared SQL Area ya kaydeder bu işleme ise hard parse denir.
SGA Bileşeleri : Shared Pool Bileşenleri : Dictionary Cache:
Veritabanımızdaki objeler hakkında detaylı bilgilerin bulunduğu alandır.
Veriler satır(row) olarak tutulduğundan row cache olarak da bilinir.
2. Background Processes :
SMON (System Monitor):
Oracle veritabanı istenmedik bir şekilde tutarsız bir şekilde kapandığında bu process veritabanının açılışı sırasında online redo log dosyalarını kullanarak instance sın tutarlı bir şekilde açılmasını sağlar.
Bu process çalışmıyorsa eğer veritabanı down olmuş demektir.
- Aşağıdaki komut ile çalışıp çalışmadığına bakabilmekteyiz.
veridata /home/oracle> ps -ef | grep smon
PMON (Process Monitor) :
Bu process te başarısız olan yada aniden sonlandırılan process lerin kullandığı sistem kaynaklarını serbest bırakıp sunucuya teslim eder.
Örnek: SQL*Plus ile veritabanımıza bağlandığımızı ve bir tablomua insert yapacak 10.000 satır insert cümlesinin bulunduğu bir script çalıştırdığımızı düşünelim.
Insert işlemini onaylayan “commit” ise insert scriptinin en sonunda olsun.
1000 satır insert gerçekleştikten sonra elektriğimiz kesilsin.
**Bu durumda bizim işlemimiz (user process) kesilmiş olacaktır, ama bizim kesilen işlemimizden veritatabanı sunucusunun haberi olmayacaktır., ve sunucu işlemi (server process) asılı kalacaktır.
PMON hemen devreye girecek, asılı kalan sunucu işlemini sonlandıracak ve commitlenmemiş 10.000 insert işlemini iptal edecektir.
RECO (RECOVER PROCESSES)
Dağınık database configurasyonları ile birlikte kullanı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.
Sizler için Oracle Veritabanının mimarisinin özeti olacak şekilde aşağıdaki gibi bir görsel hazırladım.
Eveet bir yazımızın daha sonuna geldik, diğer yazılarda görüşmek dileğile :))