IT Tutorial IT Tutorial | Oracle DBA | SQL Server, Goldengate, Exadata, Big Data, Data ScienceTutorial
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.
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.
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.
- 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.
- Veritabanı verilerinin fiziksel olarak saklandığı Datafile dosyalarının yerini içerir.
- 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.
- 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.
- 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.
- Checkpoint bilgisi control file içerisinde yer alır. Checkpoint ile ilgili ayrıntılı bilgiyi sırası geldiğide belirteceğim.
- Veritabanının oluşturulma tarihi bilgisi yine bu dosyada tutulur.
- 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.
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.
Oracle Exadata SQL Server Goldengate Weblogic EBS ve Linux konusunda aşağıdaki konularda 7×24 Uzman Danışmanlara yada Eğitimlere mi
İhtiyacınız var [email protected] adresine mail atarak Bizimle iletişime geçebilirsiniz.
– Oracle Veritabanı Danışmanlığı
– Oracle Veritabanı Bakım ve Destek
– Exadata Danışmanlığı
– Exadata Bakım ve Destek
– SQL Server Veritabanı Danışmanlığı
– SQL Server Veritabanı Bakım ve Destek
– Goldengate Danışmanlığı
– Goldengate Bakım ve Destek
– Linux Danışmanlığı
– Linux Bakım ve Destek
– Oracle EBS Danışmanlığı
– Oracle EBS Bakım ve Destek
– Weblogic Danışmanlığı
– Weblogic Bakım ve Destek
– Oracle Veritabanı Eğitimleri
– Oracle VM Server Danışmanlığı
– Oracle VM Server Bakım ve Destek
– Oracle EPPM Danışmanlığı
– Oracle EPPM Bakım ve Destek
– Oracle Primavera Danışmanlığı
– Oracle Primavera Bakım ve Destek
– Oracle Eğitimleri
– SQL Server Eğitimleri
– Goldengate Eğitimleri
– Exadata Eğitimleri
– Linux Eğitimleri
– Oracle EBS Eğitimleri
– Oracle VM Server Eğitimleri
– Weblogic Eğitimleri
– Oracle EPPM Eğitimleri
– Oracle Primavera Eğitimleri
