ORACLE Database Mimarisi (ORACLE DATABASE ARCHITECTURE)

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)

 

Oracle veri tabanı mantıksal ve fiziksel olmak üzere iki yapıdan oluşur.

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...