Home / MAKALELER / Veri Tabanı / Oracle Veritabanı Mimarisi -1

Oracle Veritabanı Mimarisi -1

Merhaba,

Bu yazımda sizlere Oracle Veritabanı Mimarisini anlatacağım. Oracle Veritabanı dünyada özellikle büyük çaplı projelerde çokça tercih edilen bir veritabanı olduğu için Oracle Veritabanını Developer ve DBA lerin mutlaka bilmesi gerekmektedir. Oracle Veritabanını ayrıntılı öğrenebilmek için sanırım ilk yapılması gereken şey Oracle Veritabanı mimarisini bilmektir. Yani kullanıcı bir transaction başlattığı zaman arka planda neler oluyor Oracle bu transaction ı gerçekleştirmek için neler yapıyor bunu bilmemiz gerekmektedir. Bende Bu yazımda sizlere Oracle Veritabanı mimarisini dilim döndüğünce anlatacağım.

mimari1

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. İşte Oracle Instance sı derken de akla SGA+Background process ler gelir. Oracle Veritabanı mimarisini aşağıdaki görsel öğe güzel bir şekilde belirtmektedir. Ben bu şekil üzerinden tüm kavramları açıklayacağım.

mimari2

Control Files: Control file bir Oracle veritabanı için olmazsa olmaz olan işletim sistemi üzerinde fiziksel olarak tutulan .ctl uzantılı bir dosyadır. Bu dosya aynı zamanda Oracle veritabanımız için beyin görevi üstlenir. Oracle veritabanı ilk başladığı esnada SPFILE yada PFILE dediğimiz parametre dosyalarını okuyup Control file ın yerini öğrenir çünkü Control file veritabanımızın beyni olduğu için Veritabanının çalışabilmesi için bu dosyayı bulması gerekmektedir bulamazsa eğer Oracle veritabanı başlamayacak ve hata verecektir o yüzden production veritabanlarında Control file dosyası minimum 2 aynı kopya halinde tutulurken Oracle ın bize tavsiye ettiği konfigürasyon ise 3 aynı kopyayı ayrı disklerde tutmamız yönündedir.  Control file çok önemli dedik peki neden önemlidir hangi bilgileri içeriyorda bu kadar olmazsa olmaz oluyor işte onları aşağıdaki gibi maddeler halinde belirteceğim.

  1. Veritabanı adı bu dosyada saklanır. Veritabanı açılırken veritabanının adının ne olduğu bilgisini instance bu dosyayı okuduktan sonra öğrenir.
  2. Veritabanı verilerinin fiziksel olarak saklandığı Datafile dosyalarının yerini içerir.
  3. Kullanıcının başlattığı transaction ların saklandığı Online Redo log dosyaları ve bunlarının arşivlendiği Archive log dosyalarının fiziksel yerlerini içerir.
  4. RMAN ile alınan Backup bilgileri yine bu dosyada bulunmaktadır. Dolayısıyla alınan bir full backup sırasında eğer Control file ında Backup ı alınmamışsa o Backup geçersizdir Restore yapılamaz. Dolayısıyla Backup almanın en önemli kurallarından biriside Control file ında backup ını almaktır.
  5. Veritabanı işlemleri sırasında kullanılan SCN(System Change Number) numarasının güncel hali yine Control file içerisinde bulunur. SCN, veritabanına gelen transactionlar commitlendiği zaman verilen bir numaradır. SCN sırayla artan unique bir değerdir.
  6. Checkpoint bilgisi control file içerisinde yer alır. Checkpoint ile ilgili ayrıntılı bilgiyi sırası geldiğide belirteceğim.
  7. Veritabanının oluşturulma tarihi bilgisi yine bu dosyada tutulur.
  8. Transactionların tutulduğu log dosyalarının sequence number bilgisini tutar.

Saydığım maddelerden de anlaşılacağı gibi Oracle veritabanımız için Control file dosyası olmazsa olmazdır bu yüzden bir Oracle DBA in bu dosyanın alınan backuplarla birlikte mutlaka backup ının alındığından emin olması gerekiyor. RMAN tool u eğer aşağıdaki gibi konfigüre ettiğimiz takdirde bu dosyanın otomatik backup ının alınmasını sağlıyor.

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

Control file mızın location nerede olduğunu aşağıdaki gibi sorgulayabiliriz.

bash-4.1$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Thu Oct 3 11:47:59 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> show parameter control_file;

NAME                                 TYPE        VALUE

———————————— ———– ——————————

control_files                        string      /oracle/data/TESTDB/control01.ctl, /oracle/data/TESTDB/control02.ctl

SQL>

Data Files: Oracle veritabanı tarafından kullanıcılara ve uygulamalara ait tutulan verilerin işletim sistemi tarafında saklanıldığı dbf uzantılı fiziksel dosyalardır. İşletim sistemi üzerinde bu dosyaları *.dbf şeklinde görebilirsiniz. Oracle veritabanı ilk oluşturulduğu zaman default olarak System, sysaux, undo, user ve temp datafile ları oluşturulmuş bir şekilde gelmektedir. Kullanıcı bir transaction başlattığı zaman Oracle ilkin Database Buffer Cache de aranan veriyi bulmaya çalışır burada bulamadığı takdirde bu veriyi bulmak üzere Data files lara yönlenir. Veritabanına ait tüm datafile ları aşağıdaki sorgu ile görebiliriz.

bash-4.1$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Thu Oct 3 13:26:26 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> set lines 800

SQL> select FILE_NAME,FILE_ID,TABLESPACE_NAME,BYTES,BLOCKS,MAXBYTES,ONLINE_STATUS from dba_data_files;

FILE_NAME     FILE_ID TABLESPACE_NAME                     BYTES     BLOCKS   MAXBYTES ONLINE_

——————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————— ———- —————————— ———- ———- ———- ——-

/oracle/data/TESTDB/system01.dbf   1 SYSTEM                          734003200      89600 3.4360E+10 SYSTEM

/oracle/data/TESTDB/sysaux01.dbf   2 SYSAUX                          744488960      90880 3.4360E+10 ONLINE

/oracle/data/TESTDB/undotbs01.dbf   3 UNDOTBS1                        519045120      63360 3.4360E+10 ONLINE

/oracle/data/TESTDB/users01.dbf    4 USERS                             5242880        640 3.4360E+10 ONLINE

/oracle/data/TESTDB/fda01.dbf   5 FDA                            1073741824     131072          0 ONLINE

SQL>

SGA: Oracle instance sı işletim sistemi üzerinde başladığı zaman kurulum aşamasında belirtilen SGA değeri kadar bir alan Oracle tarafından  işletim sisteminden allocate edilir işte bu alana System Global area denir. Oracle instance sı kapatılana kadar bu alan fiziksel sunucunun RAM ünitesinden allocate edilir, kapatıldığı zaman ise bu alan işletim sistemine geri verilir. SGA alanı ne kadar büyükse fiziksel disk ünitesinden  I/O oranı o derece azalır buda performansın artmasını sağlar.

SGA değerini Oracle database ini create ederken belirleriz ve bu değerin doğru ve optimum bir şekilde ayarlanması oracle ın performansını doğrudan etkileyecektir.  Oracle Veritabanı için ayrılan SGA değerine aşağıdaki gibi bakabiliriz.

bash-4.1$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Thu Oct 3 15:31:32 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> show parameter sga

NAME                                 TYPE        VALUE

———————————— ———– ——————————

lock_sga                             boolean     FALSE

pre_page_sga                         boolean     FALSE

sga_max_size                         big integer 512M

sga_target                           big integer 512M

SQL>

PGA ( Program Global Area): Sunucu üzerinde bir Oracle instance sı ile ilgili bir process başlatıldığı zaman sunucu fiziksel belleğinden tahsis edilen alana denir. Oracle ile ilgili process sonlanıncaya kadar bu bellek alanı kullanılır. Process tamamlanınca ise bu alan serbest bırakılır. Veritabanında bu alan için belirlenen değeri aşağıdaki gibi sorgulayabilirsiniz.

bash-4.1$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Fri Oct 4 14:56:59 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> show parameter pga

NAME                                 TYPE        VALUE

———————————— ———– ——————————

pga_aggregate_target                 big integer 2635M

SQL>

Shared Pool: Veritabanı operasyonlarının büyük çoğunluğunda kullanılan önemli bir alandır.Çünkü veritabanına gelen tüm transactionlara ait queryler, bunların execution planları (Çalışma planları) , PL/SQL kodlarının parse edilmiş ve derlenmiş halleri hep bu alanda tutulmaktadır. Shared pool alanı aşağıdaki bileşenlerden oluşmaktadır.

mimari3

Library Cache: Bu alan Shared pool içerisindeki en önemli alanlardan birisidir. Çünkü 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.

Bir DBA in en önemli görevlerinden biriside çok ağır yük altında bulunan veritabanında gereksiz yere Hard Parse yapan sorguları tespit edip bunları düzeltmektir. Gereksiz yere hard parse ların en önemli nedenlerinden biriside aynı sql cümleciğinin 1 yada birden fazla karakterinin büyük küçük harf yönüyle farklı olmasıdır.

1 nolu sorgu: select * from hr.personel;

2 nolu sorgu: select * from hr.Personel;

Yukardaki 2 sorgu da aynı tabloya atılan sorgu olup her iki sorguda aynı cevabı dönecek olmasına rağmen her iki sorgu Shared pool da library cache üzerinde farklı 2 sorgu gibi çalışacaktır. Bilgisayar dünyasında her karakterin bir ASCII numarası vardır ve aynı harfin büyük harf ile küçük harfinin ASCII karakter kodu farklı olduğu için hesaplama yapıldığı zaman bu 2 sorgunun değerleri farklı çıktığı için library cache de bu 2 sorgu ayrı ayrı tutulur.

Library cache ile ilgili yapılan hatalardan biriside uygulamalardan sürekli olarak gelen aynı sorgu tiplerinde Bind Variable ın kullanılmıyor olmasıdır. Aşağıdaki örnekte bunu açık bir şekilde belirteceğim.

örnek sorgu:

SQL> select name,surname,phone from hr.personel where id=1;

Yukardaki sorguda id si 1 olan personel in bilgileri isteniyor. Bu sorgunun sürekli olarak farklı id lerle çekildiğini düşünürsek normal bir kullanımla Oracle sürekli olarak sorgu aynı olmasına rağmen library cache de bu sorguyu tekrar tekrar parse edip duracak yani soft parse yapıp Cpu kaynağını daha az tüketmek yerine Hard parse yapıp CPU kaynağını gereksiz yere meşgul edecek. İşte bu noktada bind variable değeri karşımıza çıkıyor ve id kolonunu bind variable değeri atayıp her farklı gelen id değerinde aynı sorgunun eski execution planı kullanmasını sağlıyoruz. Yukardaki sorgunun bind variable lı kullanımı aşağıdaki gibidir.

SQL> variable person_id number

SQL> exec :person_id : =180251;

SQL> select name,surname,phone from hr.personel where id :=person_id;

Yukardaki gibi bir kullanım yapıldığı takdirde id kolonuna hangi değer gönderilirse gönderilsin Oracle aynı execution planı kullanacaktır.

Dictionary Cache: Bu alan veritabanımızın metadatasını tutar yani bir tabloya erişim yetkisinin kimlerde olduğu, tablespace bilgileri ve bir tablonun kolonları gibi alanlar bu alanda tutulur. Bir sorgu parse edilirken bu alan çok sık kullanılır.

Böylece bu yazımın daha sonuna geldim bir sonraki yazımda Oracle Veritabanı mimarisini anlatmaya devam edeceğim.

Şimdilik Esen Kalın.

Mehmet Salih Deveci

Oracle Veritabanı Yöneticisi

About Mehmet Salih Deveci

Karadeniz Teknik Üniversitesi Bilgisayar Mühendisliği bölümünden 2011 yılında mezun oldu. C#, ASP.NET ve Oracle, SQL Server Veritabanları Teknolojileri Alanlarında Çalışmalarını Sürdürmektedir. Şuan Türk Telekom A.Ş de Veritabanı Yöneticisi olarak Kariyerini Sürdürmektedir.

İlginizi Çekebilir

SQL Server ile Veri Şifreleme

Bilgi teknolojilerinde verinin güvenliği çok kritik bir öneme sahiptir. Önemli verileri korumak için ekstra bir …

One comment

  1. Teşekkürler harika bi yazı olmuş

Bir Cevap Yazın