ORACLE DATABASE ARCHITECTURE

Herkese Merhaba,

Bu yazımda Oracle Database Mimarisinden bahsettim.

Keyifli okumalar dilerim.

İlk önce Oracle Database’in ne olduğuna bakalım.

Oracle Database Nedir?

• Oracle Database, Oracle firması tarafından geliştirilen ve pazarlaması yapılan gelişmiş bir ilişkisel veritabanı yönetim sistemidir.
• Büyük yapılardaki verilerin güvenliğini en iyi şekilde sağlayan bir RDBMS yazılımıdır.
• Veritabanı merkezli, uygulama geliştirmelerinde ve web tabanlı yazılımlarda kullanılır.
• Oracle veritabanı müşterilerin istekleri doğrultusunda farklı standartlar altında kullanıcılara sunulur.

Şimdi adım adım Oracle Database mimarisini inceleyelim.

ORACLE DATABASE MİMARİSİ

• Oracle veritabanı da diğer ilişkisel veritabanlarında olduğu gibi 3 yapı üzerine kurulmuştur.

1. Bellek Yapısı(Memory Structure)
2. İşlem Yapısı (Process Sturcture)
3. Depolama Yapısı(Storage Structure)

Aşağıdaki görsel üzerinden Oracle veritabanı mimarisini adım adım açıklamaya çalışalım.

Genel olarak açıklamak gerekirse, Oracle Veritabanı çalıştığı zaman işletim sistemi üzerinde Shared Global Are (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.

1. BELLEK (MEMORY) YAPISI

• Oracle veritabanı memory yapısı 2 farklı alandan oluşur.

1. System Global Area (SGA)
2. Program Global Area (PGA)

• Yani Oracle RAM üzerinde kullanmak için kendisine belirli bir alan ayırıyor. Bu alanlar SGA ve PGA yapılarından oluşuyor.

1.1. System Global Area (SGA):

• Paylaşılmış bellek alanı (Shared Memory Area) olarak da bilinir.
• Oracle instance işletim sistemi üzerinde başladığı zaman kurulum yapılırken belirtilen SGA değeri kadar bir alan Oracle tarafından işletim sisteminden allocate edilir, allocate edilen bu alana SGA denilir.
• Her veritabanının kendine ait bir SGA alanı vardır.
• Veritabanımıza bağlanan tüm oturumlar(session) SGA ortak alanını kullanırlar.

Not:

Oracle Instance: SGA ve Background processlerden oluşur. Yani Oracle’ın çalışmasını sağlayan bileşendir. RAM üzerinde çalışır ve veri dosyalarına erişmemizi sağlar. Oracle veritabanı bir veya birden fazla instancedan oluşabilir.

System Global Area Bileşenleri

1. Database Buffer Cache:

• Veritabanında kullanıcı ya da uygulama tarafından bir transaction başlatıldığı zaman o transactiona ait dataların tutulduğu alandır.
• Veritabanında çok sık kullanılan ve en güncel olan datalar burada tutulur ve tüm kullanıcılar tarafından bu alan ortak olarak kullanılır.
• Buffer cache de tutulan datalar bir süre sonra data file lara yazılır, yerine yeni transactionlara ait veriler gelir.
• Buffer cache de tutulan data blokları “Dirty Blocks” olarak adlandırılır.
• Bu data blokları fiziksel diske yazıldığı zaman “Clean Blocks” olarak işaretleniyor.
• Buffer cache deki verilerin fiziksel diskteki data dosyalarına yazma işlemini ise DBW(n) dediğimiz background processi gerçekleştirir.

Not: Örneğin, bir select işleminde veritabanı ilk olarak Buffer Cache bakarak istenilen sorgu daha önce çalıştırılmış ise buffer cache den sorguyu döndürür. Eğer atılan select sorgusu daha önce atılmamışsa o zaman data file’dan buffer cache kopyalayarak sorgu sonucunu getirir.

2. Redo Log Buffer:

• Veritabanı üzerinde çalıştırılan her DML ve DDL işlemi ile ilgili kayıt bilgisini tutar. Bu kayıt bilgilerine “redo” denilir.
• Kullanıcı ya da uygulama bir transaction başlattığı zaman bu transaction ın kaydı ilk olarak Redo Log Buffer’a yazılır.
• Belli aralıklarla redo log buffer alanındaki kayıtlar LGWR processi ile Online Redo Log dosyalarına yazılır.

3. Shared Pool(Ortak Alan):

• Veritabanı operasyonlarının büyük çoğunluğunda kullanılan önemli bir alandır.

·Veritabanına gelen transactionlara ait sorgular,

·Bunların execution planları(çalışma planları),

·PL/SQL kodlarının parse edilmiş ve derlenmiş halleri

Bu alanda tutulmaktadır.

• Aşağıdaki göreselde de olduğu gibi Shared Pool alanı iki alt başlıktan oluşur.

3.1.Library Cache:

• Oracle veritabanına bir SQL sorgusu geldiği zaman, Oracle ilk olarak bu SQL sorgusunun daha önce çalıştırılıp çalıştırılmadığına Library Cache bakarak anlar.
• Eğer atılan sorgu daha önce çalıştırılmışsa, yani SQL cümlesi Library Cache de bulunan “Shared SQL Area” da bulunuyorsa Oracle bu sorguyu tekrardan parse etmeden önceki execution planını kullanır.
• Bu işleme de “Soft Parse” denir.
• Eğer atılan sorgu daha önce çalıştırılmamışsa Veritabanı çalıştırılan SQL cümlesini parse eder ve “Shared SQL Area” ya kaydeder.
• Bu işleme “Hard Parse” denir.
• Library Cache de yer kalmazsa, kullanılmayan en eski SQL cümlesi Shared SQL Area dan silinir ve yeni SQL cümlesi kaydedilir.

3.2.Dictionary Cache:

• Bu alan veritabanımızın metadatasını tutar, yani;

·Bir tabloya erişim yetkisinin kimlerde olduğu,

·Tablespace bilgileri,

·Bir tablonun kolonları

Gibi alanlar Dictionary Cache de tutulur.

• Kısacası Veritabanımızdaki objeler hakkında detaylı bilgilerin bulunduğu alandır.
• Veriler satır olarak tutulduğu için “Row Cache” olarak da bilinir.

1. 2. Program Global Area(PGA)

• Paylaşılmamış bellek alanıdır.
• Bir sunucu işlemi başlatıldığı zaman sunucu fiziksel belleğinde tahsis edilir. Server process sonlanıncaya kadar PGA alanı kullanılır.

Program Global Area (PGA) Bileşenleri

1. Özel SQL Alanı (Private SQL Area):

• Parse edilen SQL cümlesinin bilgisini tutar.

2.SQL Work Areas:

• Yoğun bellek işlemlerinde kullanılır.
• Örneğin ORDER BY gibi işlemlerde sort alanının kullanılması gibi.

3.Session Memory:

• Oturuma özel değişkenlerin tutulduğu alandır.

2. Process (İşlem) Structure

• 3 yapıdan oluşur.

1. User Process
2. Server Process
3. Background Processes

1. User Process:

• Kullanıcı SQL Plus gibi bir araç veya veritabanını kullanan bir uygulama çalıştırdığında, istemci makinede bir User Process başlatılır.
• Daha sonra kullanıcı, bilgilerini ve bağlanmak istediği veritabanının ismini girerek Oracle sunucusuna bağlandığı anda sunucu makinede bir server process oluşturur.

2. Server Process:

2.1. Dedicated Server Process:

• Her istemci işlemine bir server process oluşturulur.

2.2. Shared Server Process:

• Her user process için ayrı bir server process oluşturulmaz. Her oturum dispatcher tarafından paylaşımlı server process havuzuna yönlendirilerek, user process’in faaliyette olan bir server process ile ilişkilendirilmesi sağlanır.

3. Background Processes

3.1. SMON(System Monitor):

• Oracle Instance’sını kurtarmak için devreye giren önemli bir process’tir.
• Bu process çalışmıyorsa veritabanı down olmuş demektir.
• Aniden kill edilen transaction’ların kurtarılmasını da SMON Process’i sağlar.
• Yani Oracle Veritabanı tutarsız bir şekilde kapandığı zaman bu process veritabanının açılışı sırasında Online Redo Log dosyalarını kullanarak instance’ın tutarlı bir şekilde açılmasını sağlar.

3.2.PMON(Process Monitor):

• PMON process’i başarısız olan ya da aniden sonlandırılan process’lerin kullandığı sistem kaynaklarını serbest bırakıp sunucuya teslim eder.
• Oracle instance’ın listener ile iletişim kurmasını sağlar.
• Instance açılırken Listener’ların açık olup olmadıklarını kontrol eder.
• Listener açık ise gereken parametreleri, listener’a gönderir. Kapalı ise PMON, ara ara Listener’ın durumunu kontrol eder.

3.3.Database Writer Process(DBWn):

• Bir transaction başladığı zaman ilgili bloklar Buffer Cache de yok ise data file’lardan bu blokları Buffer Cache DBWn process’i tarafından taşınır.
• Datafile’lara yazılması gereken “dirty blokların” Buffer Cache’den Datafile’lara yazılma işlemini de DBWn process’i gerçekleştirir.
• Oracle veritabanı ilk kurulumda default olarak 1 tane db_writer_process’i oluşturur ve bu parametrenin maksimum değeri 36’dır.

DBW(n) Process’i Hangi Durumlarda Çalışır?

• Database Buffer Cache’de alan dolduğu zaman eski bloklardan başlanarak datafile’lara yazma işlemi başlar.
• Checkpoint process’i tetiklendiği zaman
• Bir tablespace read-only moduna getirildiği zaman,
• Bir tablespace offline duruma getirildiği zaman,
• Herhangi bir tablo drop yada truncate edildiği zaman.

3.4.Log Writer Process (LGWR):

• Bu process Redo Log Buffer ile Online Redo Log dosyaları arasında çalışır.
• Redo Log Buffer’daki transaction bilgilerini sıralı bir şekilde Online Redo Log dosyalarına yazar.

Bu process aşağıdaki durumlar oluşturulduğuda çalışı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 1mb’lık Redo Log oluştuğu zaman,
• Redo log buffer alanının 3 te biri dolduğu zaman,
• DBW(n) process’i değişen blokları datafile’a yazma işlemini gerçekleştirecekse.

3.5. Checkpoint Process(CKPT):

• DBW(n) işleminin bütün dirty buffer’ları veri dosyalarına yazdığı zaman Checkpoint işlemi gerçekleşmiş olur.
• Checkpoint’ler bir instance kurtarımı durumunda zamanı kısaltmaya yardımcı olmaktadır.
• Checkpoint işlemi otomatik olarak, bir Redo Log geçişi yapıldıktan sonra tetiklenmekte ve çalıştırılmaktadır.

Not: Bu process çok sık aralıklarla tetiklenirse eğer sürekli olarak diske yazma işlemi gerçekleşeceği için Veritabanında yavaşlamalar görülür, nadir olarak çalıştığı takdirdeyse değişen bloklar datafile lara yazılmadığı için ve değişen blok sayısı biriktiği için Oracle veritabanı instance sı ani bir şekilde crash olduğu zaman instance sı kurtarmak biraz zaman alacaktır.

3.6.Archiver Process(ARCn):

• Bu process veritabanımız eğer Arşiv modundaysa aktifleşen bir process’dir.
• Online Redo Log grupları dolduğu zaman log switch işlemi sırasında dolan Redo Log dosyasının kopyasını arşiv dosyası olarak kopyalayan process’dir.
• Hot Backup alabilmek için veritabanı ArchiveLog modda olması gerekir.

Not: Çalışma mantığına bakacak olursak veritabanımızda birden fazla redo log dosyası olacağından ilk redo log dosyasına yazma işlemi bittiğinde artık log bufferdan gelen veriler 2. Redo log dosyasına yazılacak bu sıradada ARCn prosesi 1.redo log dosyasının kopyasını alacak ve bu şekilde veri güvenliği daha da güçlenmiş olacaktır.

3.7.Recovery Process(RECO):

• Dağıtılmış veritabanı konfigirasyonu ile birlikte kullanılır.
• Veritabanı işlemlerini tamamlamakla görevlidir.
• Yani otomatik olarak, fail olma olasılığı olan transaction’lara sahip database’lere bağlanır. Ve bu şüpheli transaction’ların çözümlenmesini sağlar.

3.Depolama Yapısı(Storage Structure)

• Oracle veritabanı depolama yapısı Fiziksel ve Mantıksal yapılardan oluşur.

Fiziksel Yapı: Fiziksel olarak görebildiğimiz dosyalardan oluşur.

Mantıksal Yapı: Oracle veritabanı içinde yer alan ‘extend, segment, tablespace’ gibi mantıksal kavramlardan oluşur.

1. Mantıksal Yapı:

• Database’i daha iyi yönetebilmek amacıyla mantıksal parçalara bölünmüştür.

Blok > Extend > Segment > Tablespace > Veritabanı

Not: Oracle veritabanı mantıksal parçalarının en küçük depolama birimi blok.

Bloklar bir araya gelerek extendleri, extendler bir araya gelerek segmentleri, segmentler bir araya gelerek tablespaceleri ve tablespaceler de veritabanımızı oluşturur.

Veritabanı Blokları:

• Bir mantıksal veri bloğu, işletim sistemi bloklarına karşılık gelir.
• Veritabanı okuma/yazma işlemleri blok seviyesinde gerçekleşir.
• Bir bloğun büyüklüğüne veritabanı oluşturulurken karar verilir ve sonradan değiştirilemez.
• Data blokları default olarak 8 kb olarak gelir.

Extend:

• Ardışık bloklardan oluşan depolama kümeleridir.

Segment:

• Extendlerin bir araya gelmesiyle oluşan yapılardır.
• Segmentleri tablo, index gibi objeler olarak düşünebiliriz.

Tablespace:

• Segmentlerin bir araya gelmesiyle oluşan en üst mantıksal depolama yapısıdır.
• Bir tablespace en az bir fiziksel veri dosyasından oluşur.

2. Fiziksel Database Dosyaları:

2.1. Data Files:

• Oracle veritabanı tarafından kullanıcılara ve uygulamalara ait tutulan verilerin işletim sistemi tarafında saklandığı “.dbf” uzantılı fiziksel dosyalardır.
• Oracle veritabanı ilk oluşturulduğu zaman default olarak;

• System,

• Sysaux,

• Undo,

• User,

• Temp

Data file’ları oluşturulmuş bir şekilde gelmektedir.

2.2 . Online Redo Log File:

• Veritabanındaki tüm transactionların kaydedildiği işletim sistemi üzerindeki fiziksel dosyalardır.
• Eğer database Arşiv modundaysa buradaki dosyalar da belirli aralıklarla switch olarak arşivlenir.
• Default olarak 50 mb lık 3 tane redo log dosyası vardır. 50 mb ihtiyaca göre arttırılabilir.
• Log yazıcısı dediğimiz LGWR background processi, redo log buffer alanı ile online redo log dosyaları arasındaki iletişimi sağlar.
• Yani birinci dosya dolarsa ikinci dosyaya geçiyor ikinci dolarsa üçüncü dosyaya, üçüncü dosya dolarsa tekrar birinci dosya üzerine yazmaya başlıyor.
• Veritabanı üzerinde Online Redo Log dosyalarının tutulduğu mantıksal Redo Log grupları vardır ve her group içerisinde birbirinin aynısı 2 dosya bulunur. Amaç biri bozulduğu zaman diğerinden devam edebilmektir.
• Online Redo Log gruplarından herhangi biri dolduğu zaman yeni Redo Loglar artık bir diğer gruba yazılmaya başlar. Bu işeleme de “log switch ” denir.

2.3.Control Files:

• Veritabanında olması gereken en önemli dosyadır.
• Oracle Veritabanımızın beyni olarak adlandırabiliriz.
• Oracle veritabanı ilk başladığı esnada SPFILE veya PFILE dediğimiz parametre dosyalarını okuyup Control file ın yerini öğrenir çünkü Control file Veritabanının çalışabilmesi için bu dosyayı bulması gerekmektedir bulamazsa eğer Oracle veritabanı başlamayacak ve hata verecektir.

Control Files Dosyası hangi bilgileri içerir?

• Veritabanı adı,
• Datafile’ların yerini,
• Online Redo Log dosyaları ve Archive Log dosyalarının fiziksel yerlerini,
• Alınan backup bilgileri,
• Checkpoint bilgisi,
• Veritabanının oluşturma tarihi bilgisini tutar.

2.4.Parameter Files:

• SPFILE ve PFILE dosyalarından oluşur.

SPFILE:

• Database açılırken instance’ın yapılandırmak için kullanmış olduğu parametre dosyasıdır.
• Bu dosya olmadan veritabanı başlatılmaz
• İçeriği binary formatındadır ve normal bir metin editörü ile düzenlenemez.

PFILE:

• SPFILE dosyasından farkı, PFILE düz metin dosyasıdır ve metin editörü ile düzenlenebilir.
• PFILE dosyasında yaptığımız değişiklikler veritabanında hemen geçerli olmaz, restart gerektirir.
• PFILE dosyası default olarak oluşmaz. SQL*Plus aracı ile aşağıdaki gibi oluşturmamız gerekiyor.

SPFILE ve PFILE Arasındaki Farklar;

• Pfile, bir metin dosyasıdır ve edit edilebilir. Spfile direk olarak düzenlenemez.
• Pfile’de yapılan değişikliklerin etkin hale gelmesi için database’i restart etmek gerekir. Spfile üzerinde yapılan değişikliklerin birçoğu hemen etkin hale gelir.
• Spfile dosyası default olarak gelir, Pfile dosyası sonradan oluşturulur.

2.5.Online Redo Log Files:

• Beklenmedik durumlar karşısında veri kaybını önlemek için veritabanında olan değişikliklerin kaydını tutan dosyalardır.

2.6.Backup Files:

• Veritabanını kurtarmak için kullanılan dosyaların tutulduğu alandır.

2.7.Archived Redo Log Files:

• Redo log dosyalarının offline kopyaları gibidir.
• Online Redo Log dosyaların arşivlerinin tutulduğu dosyalardır.

2.8.Password File:

• En yetkili kullanıcıların şifrelerini tutar.

2.9.Alert Log File:

• Veritabanı çalışırken bir hata olduğunda mesajlar alert dosyasına yazılıyor.

Böylelikle bir yazımın daha sonuna geldik :)

Bir sonraki yazılarımda görüşmek üzere.

Kaynakça: http://senaeroglu.com/

Yazımı incelediğiniz için teşekkürler.

LinkedIn hesabımdan bana ulaşabilirsiniz. HARUN ERDİNÇ