01-Oracle Mimarisi (Exploring The Oracle Architecture) | Sysdba
Oracle veritabanının büyük resmi ,
Database ve instance Oracle veritabanı sunucusunu oluşturan kavramlardır. (aynı sunucuda birden fazla instance olabilir herbiri kendisine ayrılmış olan Memory yi alır.)
Instance = Memory (SGA) + background process meydana gelir. Instance ı açtığımızda (sql>startup) kendisine ayrılmış olan memory sistemden alır, background processesleri çalıştırır ve kullanıcılara hizmet vermeye başlar.
Oracle’da fiziksel ve mantıksal olarak iki yapı vardır. Fiziksel yapı , mantıksal yapıyı etkilemeden değiştirilebilir. (Datafile ın ismini ya da lokasyonunu değiştirmek gibi)
Database = datafile control file ve online redologların bulunduğu yer.
Oracle işlemleri mümkün olduğunca memory de yapmaya çalışır. Diskten yapılan işlerin maliyeti (cost) memory den yapılan işlerin maliyeti arasında ciddi farklar vardır. Oracle açılırken aldığı memory yi şekildeki gibi parçalara bölerek farklı amaçlar için kullanır. Kiminde execution planları kiminde veriyi tutar ve bunları kullanıcılar ile paylaşır.
DB’yi açıkken değişiklik yapılabilecek alanlar
memory_target ve memory_max_target alanları ayarı yapılırsı oracle otomatik olarak memory yönetimini yapacaktır. Aynı zamanda yukardaki alanları set ederek set edilen değerden aşağıya düşmesini engelleyebiliriz.
System Global Area (SGA) / Shared Global area ;
İçerisinde veri barındıran, paylaşılmış memory gruplarından oluşur (shared memory structure), SGA’daki verilerde hem yazma hem okuma işlemleri gerçekleştirilir. Bu veriler Kullanıcılar tarafından paylaşılırlar.
-Her instance ın kendi SGA’sı vardır.
Instance başlatıldığında kendisi için ayrılan RAM’i sistemden alır kapatıldığında da geri bırakır.
Show parameter memory ; (11G)
Show parameter sga ; (9i, 10G, 11G)
Program Global Area (PGA) ;
SGA gibi paylaşık bir alan değildir. Server ve background process lerin veri ve kontrol bilgilerini tutar. Server process veya background process başlatıldığında oluşturulur. Her server process ve backgorund process in kendi kendi PGA’ sı vardır.
( amaç cache_hit_percent ı yuzde 90 nın üzerinde tutmak.)
Show parameter pga ;(9i, 10G, 11G)
Order by, group by rollup gibi işlemleri pga de yapmaya çalışır , pga yetmezse temp tablespace inde yapar.
Her kullanıcıya bir server process açılır ve pga alanı ayrılır.
dept_id=b1 kullanıcılardan biri bu b1 e 5 atarken başka biri 7 atayabiliyor herkesin farklı değeri var ,bu değerlere bind variable adı verilir ve pga de saklanır.
Dedicated modda sga ve pga ayrı ayrı
Shared modda pga , sga nın içinde yer alıyor. large pool opsiyonel alanı, ayarlanır,
PGA den bir kerede geçen sorgulara “optimal executions” denir.
2 kerede geçene one pass executions denir.
çok kerede geçene de multipass executions deniyor.
amaç multipass ları (kırmızı) azaltmaktır.
where upper(name) like ‘%ADVICE%’ ;[/box]
v$ ile baslayan tüm tabloların adı v$fixed_table da tutulur.
name kolonunun default oldugu yerde size_factor un 1 oldugu yer buffer_cache in miktarıdır.
name kolonunun keep oldugu yerde size_factor un 1 oldugu yer keep in miktarını gösterir.
ESTD_PHYSICAL_READS düştüğü SIZE_FOR_ESTIMATE deki ram miktarına bakıyoruz.
ESTD_LC_TIME_SAVED , libray cache te kazanılan zaman . LC ye ayrılan ram arttıkça kazanılan zaman da artıyor. Belli bir noktadan sonra artma gerçekleşmiyor.
ESTD_PGA_CACHE_HIT_PERCENTAGE yüzde yüzlerde tutmaya çalışıyoruz (%90 nın üstünde).
SGA içinde kullanıcılara paylaşılmış bir alandır. Datafile lardan okunan Data blocklarının kopyasını tutar.
Bir Kullanıcı select cümlesi çalıştırıp veri okumak istediğinde , önce DBC kontrol edilir,
var ise (cache hit) DBC’ten veri okunarak kullanıcıya iletilir.
Yok ise (cache miss) veri datafile dan okunup bir kopyası DBC’e bir kopyası da kullanıcıya iletilir. Tabi veriyi DBC’e yazabilmesi için boş yer olması lazım. Eğer yok ise yer açıp bu veriyi DBC’ye kopyalar. Yer açmak için LRU kombinasyonlarından oluşan karışık bir algoritma kullanır. Basitçe çok kullanılan veri Memory de tutulur gibi düşünebiliriz. (FIFO vb değil )
gibi bir sql cümlesinde employees tablosunun tamamı DBC’e kopyalanmaz sadece where koşlundaki alan kopyalanır.
buffer cache = db_cache_size olarak görünür.
not: buffer cache wait event fazla ise buffer cache artırılır.
logical read ile fizikıl read oranı yuzde 90 ve üstü olması gerekir. fizikıl read ın mümkün oldugunca düşük olması gerekir.
Üzerinde fazla okuma yazma olan tabloları sürekli beffer cache te tutabiliriz.
SQL>alter table hr.employees storage(buffer_pool keep);
SQL> alter table hr.employees storage(buffer_pool default);
Database yapılan (insert, update, delete, create, alter, drop ) değişiklikleri tutar . Gerekli oldugunda recovery işlemleri için lazım olan bilgileri tutar. Dairesel (circular)çalışma mantığı vardır. LGWR background process burada bilgileri redolog dosyalarına yazar. (9i de default deger 512K idi bu yüzden alertlog dosyasına hata basar 5-10 MB da artırılabilir, sisteme göre) log_buffer = redo log buffer
SGA içinde bir alandır;
Data Dictionary Cache : Database in yapısı ve kullanıcıları ile ilgili referans bilgilerini içeren tablo ve viewların tutulduğu alandır. SQL cümleciklerinin parse işlemi sırasında data dictionary ye çok sık erişilir bu yüzden memory de tutulması performans açısından önemlidir.
library cache : (shared SQL area) SQL cümlelerinin parse bilgilerini ve çalıştırma planını (exection plan) tutar. İki kullanıcı aynı SQL cümlesini çalıştırdığında oracle bunu tanıyor ve tekrar parse işlemlerini gerçekleştirmeyip library cache deki bilgileri kullanıyor buna soft parse adı verilir. Yeni bir SQL parse edildiğinde oracle shared pooldan memory alır. Alınanan memory sql cümlesinin komplexliğine bağlıdır.
PL/SQL kodları/program parçacıkları için de aynı durum geçerlidir. (procedure, function, packages, anonymous blocks, triggers)
LRU algoritması kullanılır.
İstatistik (DBMS_STATS) alındığında shared pool flush eder. (9i 10G 11G farklılıgı anlatılabilir)
obje değitirildi ise (alter) reparse gerekir . Çünkü o sql statement invalid duruma düşer
global db name değiştirildi ise
dba manuel olaral “alter system flush shared_pool” çalıştığında flush eder.
BC veriyi cachliyordu , shared pool sorguların çalışma planlarını (execution plan) keşler.
sorgu kontrolü , tablo kolon erişim hakları kontrolü
sonra parse işlemine geçer,
index mi kullanacak full table scan mi yapacak bunlara karar verir.
aynı sorgu tekrar gelirse aynı işlemleri yapmasına gerek kalmaz.
bilgi için v$sgastat view ı sorgulanabilir.
Opsiyonel bir alandır.
Shared modda çalışan db lerde ve oracle xa interface kullanan uygulamarda
I/O server processesleri için
ve backup restore işlemleri için fazldan memory gerekli oldugunda aktif edilebilir.
Eğer large pool ayarlanmamışsa, rman, shared pool u kullanır. Bu da performansı olumsuz etkiler.
Birden fazla işlemcilerin oldugu sistemlerde parallel sql lerde kullanılır . (hintler aracılığı ile )
Eğer shared server modda ise , large pool un daha büyük ayarlanması gerekir.
java kodları ve JVM verileri içi kullanılan alandır. Java_pool adviser ,library cache in java için kullanımı ve java pool un değiştirildiğinde parse ratingini nasıl etkileyeceğine dair istatistik bilgiler verir. (statistics_level =typical veya daha üst seviye ise)
Streams Pool :
SGA’ dan replikasyon için ayrılan alandır. (Dataguard , golden gate gibi yapılarda)
Anlık sga değerlerini görelim
SQL>select * from v$sgainfo ;
Not: pfileORCL.init dosyasındaki orcl._db_cache_size= vb değer, sga yönetimi otomatikken oracle ın o an için atadağı değerlerdir.
11G’de otomatik memory yönetimi
SQL>ALTER SYSTEM SET MEMORY_MAX_TARGET=6G SCOPE=SPFILE;
SQL>ALTER SYSTEM SET MEMORY_TARGET=5G SCOPE=SPFILE;
SQL>ALTER SYSTEM SET PGA_AGGREGATE_TARGET=0 SCOPE=SPFILE;
SQL>ALTER SYSTEM SET SGA_TARGET=0 SCOPE=SPFILE;
10G’de otomatik memory management
SQL>ALTER SYSTEM SET sga_max_size=5G SCOPE=SPFILE;
SQL>ALTER SYSTEM SET sga_target=5G SCOPE=SPFILE;
SQL>ALTER SYSTEM SET pga_aggregate_target=1G SCOPE=SPFILE;
Oracle processlerini iki ana gruba ayırabiliriz;
1- Bir uygulama çalıştırıldığında ya da bir arac ile kod koşulduğunda çalışan processes.(java uygulaması /sqlplus veya toad vb.)
2- Oracle database in kendi çalıştırdığı processler (server ve background processsler)
Kullanıcı sqlplus ya da toad vb bir uygulama çalıştırdığında, Oracle database user process i ve user process in koştuğu kodu çalıştırmak için server process i oluşturur. Bunlara ek olarak instance ın background processleri vardır. Background processler memory yönetimini asenkron Disk yazma okuma işlerini ve diğer gerekli işleri gerçekleştirir.
Processes yapıları database configurasyanuna işletim sistemine ve oracle database seçeneklerine göre değişiklik arz eder. Örneğin archive log modda olmayan Db ‘lerde archwr process çalışmayacaktır, dedicated server modda çalışan sunucularda her user processine bir server process açılır.
Shared modda çalışan sunucuda ise her user prosesse i için bir server prosess açılmaz. Dispatcher, session isteklerini bir havuzda tutup çoklu user isteğini bir server processeste çalıştırır. Bazan uygulama ile oracle database aynı makinede oluyor bu durumda oracle sisteme fazla yük getirmemek için aynı processle çalıştırılabilmekte.
User processine karşılık gelen Server processi aşağıdaki işlemlerin birini yada bir kaçını gerçekleştirir.
–parse ve sql cümlesinin koşulması
–data blocklarının datafile dan okunup bir kopyasının SGA ya aktatırılması.
RAC ve ASM olmayan instance lardaki background processler
– Recover process ((RECO)
– Queue monitorprocess (QMNn)
v$bgprocess view ından background processlerle ilgilibilgi alınabilir.
BG processlerden bazılar instance başlatıldığında otomatik olarak başlar bazıları da ihtiyaç oldukça çalışır.
BackGround Processleri görmek için:
Database buffer cache deki dirty data yı diske yazmaktan sorumludur. (dirty data değişiklik yapılıp commit edilmiş veri) Çoğu sistem için tek dbw process yeterlidir ama istenirse artırılabilir. Eğer database inizde çok fazla yazma işlemi varsa yeni DBW proceses ler eklenerek yazma performance ı artırılabilir. Tek işlemcili sistemlerde DBW sayısını artırmak kullanışlı değildir.
DBC’deki bir buffer alanınde değişiklik yapılıp commit edilince , dirty olarak işaretlenir ve LRUW (LRU write) listesine eklenir bu liste SCN sırasında tutulur. Bu sıralama redolog lara yazılacak redo sıralamasıyla uygun hale getirilir. DBC de yer kalmayınca (threshold a ulaşılınca) DBW process LRUW list sıralamasına göre dirty buffer ı datafilelara yazar.
LRU algoritması sık erişilen blokları buffer cache de tutar. Diske yazdıkları büyük ihtimal erişimi az olan bloklardır.
System change number ı görmek için
SQL>select current_scn from v$database ; –10G de
SQL>select dbms_flashback.get_system_change_number from dual ; –9i de
LGWR, redo log buffer daki verilerin redolog dosyalarına yazılmasından sorumludur. Aşağdaki durumlarda yazma işlemini gerçekleştirir.
transaction commitlendiğinde (daha fazla redo buffer gerektiği bazı zamanlarda commit olmadan da yazabilir.)
redo log buffer ın 1/3 ü doldugunda
DBW diske yazmadan önce
3′ sn de bir
Database writer processesi tarafından DBC’deki dirty buffer diske yazdırılır, checkpoint işlemi değişen block ların bilgisini kontrol file a ve datafile ların headerlarına yazar. Checkpoint işleminin amacı instance recover işleminin başalatılacağı redolog file ların içindeki konumu belirlemektir.
Buna Checkpoint Poisition denir.
Değişen data blockların memory den diske düzenli bir biçimde yazıldığından emin olur,
Böylece instance yada database hatası meydan gelirse data kaybı önlenmiş olur.
Instance recovery (instance kurtarma) işlemi için gerekli olan zaman, azaltılmış olur.
Shutdown işlemi sırasında commitlenmiş tüm verilerin diske yazıldığından emin olmak için.
Özetle checkpoint bilgileri checkpoint process tarafından kontrol filelerin içerisine yazılır. Çünkü oracle başlatıldığından kontrol filelerden gerekli bilgileri okur. Ayrıca checkpoint işlemlerinin önemli içeriklerini özetlemek gerekirse;SCN number(System change number), recover işleminin başlatılacağı redo log filelerin içerisindeki konum, log bilgileri
Instance ın açılışı sırasında, eğer gerekli ise recovery yapar , datafile lar ile control file ın SCN sini eşit hale getirip VT yi açmaktır. Commitleri roll forward commit edilmemiş rollback yapar.
Kullanılmayan temporary segmentlerini temizler. ihtiyaç olduğunda diğer prosessler smon u tetikleyebilir.
Kullanıcı processesi herhangi bir nedenden istenmediği halde kapanırsa bu processesin recover işlemini gerçekleştirir. Kullanıcının kullanımına sunulan buffer cache i ve diğer kaynakların boşa çıkartılmasından sorumludur. Örneğin ; eğer aktif transactionlar iptal edilirse kilitler kaldırılır, aktif processeslerden processes id silinir.
Kullanıcılar üzerindeki kilitleri kaldırır; kullanıcıların commitlemediği (o sırada vt kapandığı vb. durumlarda) ve dolayı ile kilitli kalan satırları. serbest bırakır.
pmon periyodik olarak dispatcher ve server processeslerini kontrol eder kapanan varsa açar.(bilinçlli olarak kapatılanları açmaz)
instance ve dispatcher bilgilerini listener a kayıt eder.
smon da oldugu gibi ihtiyaç halinde diğer prosessler pmonu tetikleyebilir.
Birden fazla instance ın kullanıldığı yapılarda çalışır. hatalı gerçekleşen transactionları replikasyonlarını otomatik olarak diğer DB ye bağlanıp sorunu halleder.
DB archive log modda ise çalışır , log switch olduktan sonra redo loglerı gösterilen pathe arşivler. standby makineler varsa bu makinelere transferini yapar. (Dataguard dersinde göreceğiz)
MMON (manageability monitor process): alertlerin yayınlanması istatistiklerin alınması yönetimle ilgili işleri gerçekleştirir.
MMNL (Lightweight manageabiliy monitor process): session history takibi gibi lightweight manageility işlerini yapan process
MMAN (memory manager process): otomatik memory yonetimini yapar, memory ihtiyacı olmayandan olana memry dagıtımını otomatik gerçekleştiren process.
RBAL (rebalance process ): ASM kullanılan db lerde disk dengelemesi yapan processes
CJQ0 (Job Queue Coordinator Process) : kullanıcıların job lerinı çalıştırır. zamanlama servisi olarak düşünülebilir. (plsql statements procedures)
QMNC(AQ Coordinator Process) : advanced queue servisini monitor eder ve AQ ve oracle streams ın çalışmalarına yardımcı olur.
Daha önce de bahsettigimiz gibi bir sorgu geldiğinde , oracle istenen blogun buffer cachte olup olmadığına bakar eger varsa cach ten kullanıcıya iletir. Yok ise datafile dan yani diskten okur bir kopyasını buffer cache iletir, sonrasında aynı sorgu gelirse buffer cacheten hızlı bir şekilde erişip kullanıcıya iletebilmek için bir kopyasını da kullanıcıya iletir.
Buffer alanları 4 farklı statuste olabilir.
pinned : birden fazla kullanıcının aynı bloga yazmak için bekledikleri durum 1.den sonra gelen kullanıcılar yazmak için beklerler. (1. session oturumu kitlediği için,commit ettikten sonra açılır.)
clean : unpinned zaman aşımına uğramaya aday alandır.(tabi mevcut daki bloklara tekrar erişim olmazsa)
free or unused : buffer ın boş olduğu durum instance ın yeni açıldıgı zamanki durum.
dirty : buffer daki alan değiştirilmiş commitlenmiş ve diske yazılmaya hazır olunan durum.
İki kişi arasında telefon hattının olması bağlantının var olduğu anlamına gelir, ne zaman biri diğerini ara ve karşıdaki telefonu açarsa ozaman arada session başlamış olur. (client processes ine karşılık server processes başlar)
1- Instance başlatılır, işletim sisteminden memory yi alır , backkground processleri çalıştırır. ve kullanıcı erişimine hazır hale geldi.
2- Kullanıcı uygulamayı başlatır ya da oracle aracı ile bağlantı talebini gönderir.
3- Server, listener servisi ile instance servisini network üzerinde erişilebilmesini sağlar. Gelen bağlantı taleplerini alıp user processe karşılık gelen dedike server processini oluşturur.
4- Kullanıcı dml ya da sql çalıştırdığında , örneğin bir çalışanın kimlik bilgilerini değiştirsin.
5- Server processes statementı alır shared pool u kontroller eder daha önce aynı sql çalıştırılmış mı diye. Eğer çalıştırıldı ise kullanıcının haklarını kontrol eder. istenen bilgi ve çalıştırılan sql için . Shared pool da bulamazsa , yeni sql alanı alınır , sql parse edilir ve işlenir.
6- İstenilen veri blokları varsa buffer cacheden yoksa datafile lardan getirilir.
7- Server processes SGA daki veriyi değiştirir.
logwriter değişiklikleri redologlara yazar.
Oracle uygun oldugunda DBW değişiklikleri datafile lara kalıcı olarak yazar.
8- Bu değişiklik işlemi (transaction başarılı bir şekilde gerçekleşirse server process network üzerinden uygulamaya mesaj gönderir. Eğer başarılı olmazsa hata mesajı döner.
9- Diğer background processleri baştan sonra tüm prosedürleri izler ve gerekli olduğunda devreye girer. örneğin redolog switch ederse arcW redologu arşivler. Ek olarak database server diğer kullanıcıların transactionlarını da yönetir örneğin aynı data üzerinde değişiklik yapılmak istenirse çakışmaları önler.
Control Files : Veri tabanının kimlik bilgilerini tutar. Her instance ın en az bir adet controlfile ı vardır, tavsiye edilen farklı fiziksel disklerde en az iki adet bulundurulmasıdır. Defaultta 3 adet gelir, bunları farklı disklere dağıtmakta fayda var.
Controlfile’ lar datafile, redolog file isimleri lokasyonları, current log sequence numaraları, backup set bilgileri, ve en önemlisi de “system change number” (SCN),bilgisini tutar. Binary bir dosyadır kullanıcılar bu numaraları görüp değiştiremez. Ayrıntılı bilgi için ControlFile yönetimi adlı makaleye bakınız.
DataFiles : Kullanıcıların objelerini tuttuğu dosyalardır. Mantıksal kavram olarak tablespace ‘e karşılık gelen fiziksel kavramdır. Bir datafile tek bir tablespace e ait olabilir. Bir tablespace in birden çok datafile ı olabilir .(Big file tablespace hariç). Ayrıntılı bilgi için tablespace yönetimi adlı makaleye bakınız.
Online RedoLog Files : Transection bilgilerinin tutulduğu dosyalardır. Defaultta 3 adettir. Min 2 adet olmalı ihtiyaca göre sayısı da boyutu da artırılabilir. Farklı disklerde üyelerinin olması şiddetle önerilir. Çevrimsel çalışma mantığı vardır ( recycle )
1. ye yazar 2. ye yazar 3. ye yazar dolunca 1. nin üzerine tekrar yazar.
Parameter File : Başlangıç dosyası olarak da adlandırılır. VT açılırken ilk bu dosyayı okuyup işletim sisteminden ne kadar memory alması gerektiği control file ların nerede olduğu vb bilgileri alır . Binary dir . istenirse txt file olarak kopyası oluşturulabilir. (sql>create spfile from pfile) .
BackUp Files : Export , dbf ve rman backup dosyaları. Oracle ‘da 3 tür yedekleme vardır.
1- export (mantıksal yedek)
2-Cold BAckup (user backup) db nin kapatılarak dosyaların yedeklenmesi
3-Rman backup (asıl backup aracı )
Archive Redo Log Files : Archive moda alınan VT , online archive log ların yedeklerini alır yani arşivler bu dosyalara verilen addır. bu archive log dosyaları sayesinde istenilen bir noktaya restore işlemi yapılabilir.
Password File : Vt ‘nin kapalı olduğu durumlarda da harici bir dosyadan kimlik sorgulama işlemleri yapılarak VT ye giriş yapabilmeyi sağlayan bir dosyadır. bir sorun olması durumunda yeniden oluşturulabilir.
Alert Log : VT’de olup bitenlerin yazıldığı dosya hata msj ları vs. Veritabanı yöneticilerinin sürekli izlemesi gereken bir dosya.
Trace files : Hata mesajları ile ilgili daha çok detayın yazıldığı dosyalar . Eğer çalışan SQL üzerinde trace raporları da başlatıldı ise , bu bilgiler de trace file lara yazılır.
Schema = Kullanıcı (objeler kataloğu) (MSSQL de ve MYSQL de database)
Database = tablespace lerden oluşur.
Tablespace = segmentlerden oluşan objelerin tutulduğu mantıksal kavram.
Segment =Extentlerden oluşur.
data segments kullanıcıların tablolarını/indexlerini vb objelerini segmentlerde tutar segmentler de table spaceleri oluşturur. (index segment )
okuma tutarlılığı için kullanılan undo segments undo tablespace ini oluşturur.
Extent = Blocklarda oluşur.
Datablock = oracle ın en küçük yapı birimi, oracle bilgilerini bu blocklarda tutar.
Oracle database ‘i mantıksal olarak tablespace lere bölünmüştür.
user tbs (big / small)
system tablespace ; DB oluşturulurken otomatik olarak oluşturulur. Her DB de olması zorunludur.
Data dictionary gibi DB’ nin çalışması için gerekli olan tabloları barındırır . Offline a alınamaz.
SysAux tablespace : 10G ile gelen bir TBS system tablespaceine yardımcı olarak gelmiştir . AWR istatiskleri bu TBS de tutulur.