4 – Oracle Process’leri

Oracle Eğitimleri - Oracle Processes

Oracle’daki her process belirli görevleri gerçekleştirmek için PGA’den bellek almak zorundadır ki görevleri yerine getirebilsin. Bir Oracle instance üç ana process sınıfına sahiptir:

Server Process: Bu process’ler client’ların taleplerine göre çalışırlar. Daha önce göz attığımız dedicated ve shared server bağlantıları bu process ile ilgilidir.

Background Process: Bu process’ler database ayağa kalktığı anda devreye girerler. Performans bakım görevlerini, online redo log içindeki data block’larının diske yazılmasını, abort edilmiş process’lerin bellekten temizlenmesini ve AWR (Automatic Workload Repository) bakımını gerçekleştirir.

Slave Process: Bu process’ler, Backgound Process’lere benzerler; fakat Background veya Server process’lerin extra iş yapma ihtiyaçları doğduğu anda Slave Process’ler devreye sokulurlar.

Server Process’leri

Server process’leri bir client tarafından session başlatıldığı zaman taleplerini karşılamak için devreye girerler. Bu process’ler bizim uygulamalarımız tarafından iletilen SQL deyimlerini alıp database iletir ve işlenmesini sağlarlar ve ardından result’ı bize geri döndürürler.

Daha önce Oracle bağlantı yapısına dair iki türü incelemiştik:

Dedicated Server bağlantısı: Bu bağlantı türü bir server process’idir. Bu process aracılığı ile database ile birebir bağlantı kurmuş olursunuz.

Shared Server bağlantısı: Bu da bir server process’idir. Daha önce değindiğimiz gibi işlemler kuyruklanır ve sırasıyla talep eden kullanıcılara tahsis edilirler ve işleri bittiğinde yeni bir kullanıcı için tahsis edilirler. Burada da dispatcher kullanıldığına değinmiştik.

Bu iki bağlantı process’i sonuçta aynı işlemleri yerine getirirler, PL/SQL deyimlerimizin iletilip işlenmesini sağlamak ve bize sonuç döndürmek. Örneğin bir Select ifadesi yazdığınızda da iki bağlantı process’i de bilgiyi iletince parse ve execution plan çıkartıldığında Shared Pool üzerinde bu plan saklanır ve yeni talep doğrultusundan buradaki yol hesabına göre benzer sorgularda da aynı yol izlenir. Bunun için bazen process’ler kendi query planları ile birlikte gelirler ve hangi block’un nereden okunması gerektiği bilgisini de iletmiş olurlar.

Bu process’ler en yüksek kaynak tüketimini yapan process’lerdir. Genellikle CPU tavan yaptığında arkasında bu process’leri buluyor olacaksınız.

Dedicated Server Connection

Bu bağlantı türünde daha önce de değindiğimiz gibi Instance ile birebir bağlantı kuruyor olursunuz. Her bir client başına bir yalıtılmış process (Windows’ta thread) tahsis edilir. Şekil olarak göstermek gerekirse:

Dedicated Server Bağlantı
Dedicated Server Bağlantı

Resim Kaynak: Oracle® Database Net Services Administrator’s Guide 11g Release 2 (11.2) Part Number E10836-05 https://docs.oracle.com/cd/B28359_01/network.111/b28316/img/net81097.gif

Şekilde de görüleceği üzere client bir uygulama yürüttüğünde Oracle üzerinde işlem yapabilmek için uygulama Oracle kütüphanesine başvuracaktır. Bu kütüphaneler aracılığı ile uygulama Oracle instance ile iletişim sağlayabilecek api’lere sahip olacaktır. Bu api’ler instance üzerine gönderilecek verilerin nasıl paketleneceği ve bu paketlerin nasıl açılacağını bilirler. Bu sisteme / yazılıma / process’e Oracle Net adı verilmektedir.

Oracle Net arabirimi client tarafından gelen istekleri karşılar. Bu arabirim client ve server’da aynı iki işi gerçekleştirmektedir:

Uzaktan Çalıştırma (Remote Execution): Database’in kurulduğu sunucu dışında bir client taleplerini işletir.

Adres Alanı İzolasyonu (Address Space Isolation): Server Process’lerin SGA’e okuma ve yazma işlemi için yetkisi vardır. Bu yazma erişimi esnasında hatalı bir pointer ile SGA üzerinde bulunan veri yapıları kolaylıkla bozulabilir (corrupt).

Shared Server Connection

Bu bağlantı türünde client, database sunucu üzerinde işlem yapıyor dahi olsa Oracle TNS Listener’ını kullanamaz. Daha önce bu bağlantıda Dispatcher kullanıldığını söylemiştik. Siz bir client application açtığınız zaman TNS Listener sizi otomatik olarak dispatcher’a yönlendirecektir. Burada Dispatcher, client ile instance arasındaki iletişimi kanalı olmaktadır. Aşağıdaki şekilde bu yapıyı görebilirsiniz:

Shared Server Bağlantı
Shared Server Bağlantı

Resim Kaynak: Oracle® Database Net Services Administrator’s Guide 11g Release 2 (11.2) Part Number E10836-05  https://docs.oracle.com/cd/B28359_01/network.111/b28316/img/netag118.gif

Şekilde görüldüğü gibi client’lar isteklerini Dispatcher’a iletir, o da Request Queue’ya iletir. SGA içinde istekler kuyruklanır. İstekler Shared Server process’leri tarafından UGA’e session ile birlikte eklenir. Herhangi bir çıktı döndüğü anda Shared Server process’leri tarafından çıktı Response Queue’ya iletilir. Dispatcher’a gelen response, yine sırayla ilgili session’a sahip client’a iletilir.

Dispatcher sayısı genelde birden fazladır; ama bir tane olduğu durumlarda mevcuttur. Bir Dispatcher rahatlıkla yüzlerce client isteğini karşılayabilir; fakat daha önce de değindiğimiz gibi yükse transaction blokları söz konusu ise ve client sayısı yüzleri ve belki binleri bulacaksa o zaman Shared Server bağlantısı pek işinizi görmeyecektir.

Database Resident Connection Pooling (DRCP)

DRCP, yeni ve opsiyonel bir oturum (session) açma yöntemidir. Bu daha çok doğal yollarla client application oluşturamayan PHP gibi web için geliştirilmiş diller tarafından kullanılır. DRCP, Dedicated ve Shared Server bağlantılarının bir karışımıdır. DRCP, Shared Server bağlantıdan shared server havuzunu kalıtım yolu ile alır; fakat Dedicated Server’daki gibi yalıtılmış bir process ile çalışır.

Shared Server bağlantıda hatırlayacağınız gibi bir shared process’leri birden çok session kullanabilmekteydi. DRCP’de ise bu geçerli değildir. DRCP, Dedicated Server gibi yalıtılmış bir kanal açar, fakat talep eş zamanlı olarak birden fazla process tarafından işlensin diye dedicated server’ın tek process mantığını devre dışı bırakıp shared process’ler ile farklı ifadeleri farklı process’lerde ileterek sonuçlarını birleştirir, bu sayede normalden çok daha hızlı sonuç elde etmesi mümkün olmaktadır.

DRCP Bağlantı
DRCP Bağlantı

Resim Kaynak: Python and Oracle Database: Scripting for the Future https://oracle.github.io/python-cx_Oracle/samples/tutorial/resources/python_pool.png

Connection ve Session’ın Karşılaştırılması

Genel olarak Session ve Connection aynı şeymiş gibi düşünülür; ama temelde ikisi farklı anlamları ihtiva etmektedir. Bir connection üzerinde bir veya daha fazla session olabilir. İkisi de fiziksel verilere erişiyor olsa da aslında birbirinden bağımsızdır. Örneğin bir session ile commit edilen komutlar, diğer session’da da gerçekleşmez, çünkü session her bir kulanıcının kimlik bilgisi ile tutulur ve işlemler birbirinden rahatlıkla izole çalışabilir.

Temelde bir connection client ile instance arasındaki alışverişi sağlar. Bu alışveriş dedicated server veya dispatcher ile de yapılabilir. Oracle Net ile connetion havuzundaki bir nesne bir session’a atanabileceği gibi aynı nesneye birden fazla session da atanması mümkündür, sonuçta connetion bir process gibi düşünülmemelidir. İki nesne arasındaki farkı biraz daha detaylandırırsak:

Connection: Bir connection, client ve istemci arasındaki fiziksel bir yoldur. Bu connection network üzerinden sağlanabileceği gibi IPC (Inter Process Communications) yalnızca database’in üzerine kurulu olduğu sunucu üzerinde gerçekleştirilebilir.) mekanizması ile de sağlanabilir. Bir client bağlantı sağlamak istediğinde CMAN (Connection Manager) tarafından talep karşılanır ve instance ile arasında fiziksel bir yol oluşturulur.

Session: Bir session ise sadece mantıksal bir varlıktır, fizikselliği ifade etmez. Bir session bilgisi sizin kimlik bilginizi ifade eder, bu sadece sizden talebi almak ve size talebi iletmek için kullanılan bir kimliktir yani adresiniz gibi düşünebilirsiniz. Siz sunucuya connection açmak istediğinizde TCP katmanında size bir kimlik tanımlanır, bu şekilde sunucu sizin nerede olduğunuzu bilir.

Background Process’ler

Background process’ler, database’de gerekli işlemlerini yerine getirirler. Örneğin veri block’larının buffer’a yazılması veya data file’lara kaydedilmesi işlemlerini gerçekleştirir. Yine Online Redo Log’ların archive disklerine kopyalanmasını sağlarlar. Diğer taraftan abort olmuş client işlemlerini temizlemekle meşguldürler. Çalışan process’leri görmek için şu view’i kullanabilirsiniz:

Background process’leri aşağıdaki resimde görebilirsiniz:

Background Process’leri
Background Process’leri

Resim Kaynak: Oracle® Database Net Services Administrator’s Guide 11g Release 2 (11.2) Part Number E10836-05 https://docs.oracle.com/cd/B10501_01/server.920/a96524/cncpt154.gif

Şimdi bu process’leri kısaca görelim:

PMON (Process Monitor)

Bu process’ler beklenmedik şekilde sonlandırılan connectionları temizlemekle sorumludur. Örneğin dedicated moddaki bir connection herhangi bir nedenle kill edilirse PMON duruma müdahale eder, kurtarma veya geri yükleme yapar ve kaynakları serbest bırakır. Bir rollback ya da commit edilmekten vazgeçilmiş işlemlerde kaynaklar üzerindeki lock’ları kaldırır, tahsis edilmiş SGA kaynaklarını geri iade eder.

Yine PMON, abort edilen connection veya dispatcher’da bir crash gerçekleşirse anında müdahale eder, gerekirse işlemleri yeniden başlatır. Herhangi bir işlem beklenmedik şekilde gerçekleşirse yine onu ayağa kaldırmak PMON’un görevidir. Örneğin LGWR (Database Log Writer) hataya düşerse bu ciddi bir durumdur, hemen data recover edilir ve durum düzeltilerek LGWR ayağa kaldırılır.

PMON’un diğer bir işlemi de TNS Listener’dan faydalanarak instance’ların register edilmesi işlemidir. Bir instance startup olduğu anda PMON pool devreye girer ve instance’ın ayakta olup olmadığını sorar. Bu işlem için default olarak 1521 numaralı port kullanılır. Eğer farklı bir porttan çalışılıyorsa local listener ayarlarına bilgi set edilir ve PMON işlemi bu port üzerinden gerçekleştirir. Instance açılmaya başladığı halde nomount veya mount modda takılı kalırsa open moduna gelene kadar PMON instance ile sürekli iletişim kurmaya çalışacaktır. Instance devreye girdiği anda çalışır durumda olduğu bilgisi sistemde register edilecektir.

SMON (System Monitor)

SMON, server seviyesi işlemleri gerçekleştirmekten sorumludur. Örneğin database için garbage collector görevini üstlenir. İşlerinden bazıları şöyledir:

Temporary Space’i Temizler: Temporary tablespace ile bazı angarya işler ortadan kaldırılır; ama bazen temizlenmesi sorun olabilir. Örneğin bir index oluşturulması esnasında index build edilirken extentler bu işlem için tahsis edilir. Fakat bu index oturumu beklenmedik şekilde abort olabilir. Bu durumda SMON devreye girer ve kaynaklardaki işlemleri temizleyip sisteme yeniden kullanılmak üzere iade edilir.

Free Space’leri Birleştirir: Eğer Dictionary – Managed Tablespace kullanıyorsanız, SMON ufak parçalara ayrılmış extent’leri işleri bittikten sonra boş büyük bir bütün extent haline getirir.

Transaction Recovery İşleminde Kullanılamayan Dosyaları Kurtarır: Bu database startup sırasındaki işleme benzer. Bir sistem çökmesi (crash) gerçekleştiğinde instance nomount modundan sonra mount ederken recover işlemlerine başlamaya çalışacaktır, burada bozulmuş olan dosyalar varsa SMON bu dosyaları recover edecektir.

RAC’da Bir Node Fail Olursa Recovery Yapar: RAC yapısındaki bir cluster’da bir instance çöktüğünde diğer node ayağa kaldırılır ve node üzerindeki redo log file aracılığı ile çöken instance’ı dataları ile recover eder.

OBJ$’ı Temizler: OBJ$, low-level bir data dictonary table’dır. Database içindeki hemen hemen tüm nesneler (tablo, index, trigger vb.) burada saklanırlar. Bir nesne arandığında buraya bakılır. Zaman zaman obje silme işlemleri gerçekleştirilir. Bu objelerin OBJ$’dan da temizlenmesi gerekir, işte bu durumda SMON devreye girer ve gerekli temizliği yapar.

Undo Segmentleri Shrink Eder: Eğer gerekli ayarlar yapıldı ise rollback edilen segmentleri optimize etmek için SMON otomatik olarak segmentler üzerinde shrink işlemini uygular.

SMON’un bundan başka yaptığı birçok iş vardır ve detaylı incelenmesi gerekir; ama burada yerimiz bunların tamamını incelemek için yeterli değil maalesef

RECO: Distributed Database Recovery

RECO, tamamen işlem odaklıdır. Bir two-phase commit (2PC) işlemi esnasında connection kopar veya bir crash gerçekleşirse hazırda bulunan tranaction’ı recovery yapar. 2PC bir dağıtık mimari protokolüdür, database modifikasyonunu sağlayan işlemleri otomatik olarak commit eder. Örneğin SQL*Plus’ınızı “x”’ya basarak kapattığınızda 2PC devreye girer ve commit edilmemiş transaction’ı otomatik olarak commit eder. Bu tür bir işlem yapmaya kalktığınızda transaction başarısızlıkları mümkün olduğunca giderilmeye gayret edilir. 2PC n tane database üzerinde çalışmaktadır ve bu işlemleri koordine etmek gerekir. Bir oto commit durumunu devreye sokmak için tüm database’lerde bir oylama yapar ve commit edilip edilmeyeceği konusunda oy verir, sonuç evet ise oto commit işlemi yapılır, değilse rollback edilir. İşte bu koordinasyonu sağlayan RECO’dur.

CKPT: Checkpoint Process

Bellekte değişmiş (SGA) block’lar belirli aralıklarla fiziksel data file’lara yazılmaktadır. Bu yazılma işlemine başlarken bir checkpoint işlemi gerçekleştirilir. Checkpoint işlemi gerçekleştiği anda control file ve data file header’ında checkpoint atılmış olan SCN numarası güncellenir ve dirty block’lar yazılmaya başlanır. SCN güncelleme işlemi CKPT tarafından gerçekleştirilir, bu database’in güncel kalması ve herhangi bir crash olması durumunda sistem recover edilirken dataların senkronizasyonu SCN numaralarına göre yağılmaktadır, bu yüzden oldukça önemlidir.

DBWn: Database Block Writer

Temel görevi bellekte bulunan değişmiş block’ları data file’lara yazmaktır. Bunu sürekli yapmaz, en azından performans kaybı olmasın diye bazı olaylar neticesinde tetiklenir ve yazma işlemini yerine getirir. Bunlar:

  • CKPT tarafından checkpoint atıldığı zaman
  • SGA üzerinde yeterli bellek alanı kalmadığı zaman, genişletmek için
  • Commit edilmiş data block’larının sayısı çok fazla olduğu zaman
  • Abort metodu dışında instance shutdown edildiği zaman
  • Herhangi bir tablespace offline veya backup modunu alınırsa
  • Bellekte bir veri araması çok uzadığı zaman

Bir instance’da default olarak 1 tane DBWn bulunur; ama bu sayıyı artırmak mümkündür, tabii ki bu sayı cpu core sayısından yüksek olmamalıdır. Sayının artması işlem yapma hızını artıracağı için faydalı olacaktır şüphesiz.

LGWR: Log Writer

Bellekte bulunan Redo Log bölgesindeki log bilgilerini Online Redo Log dosyalarına yazar. Bu yazma işleminin gerçekleşmesi normalde 3 saniyede bir yapılır. Bunun dışında bir transaction sonrasında commit komutu gelince de hemen devreye girer. Ayrıca log buffer 1 mb’ı bulduğu zaman da devreye girer ve belleği boşaltıp Online Redo Log dosyasına yazar.

Online Redo Log dosyasına yazılma işlemini daha önce işlemiştik. Eğer unuttuysanız tekrar Online Redo Log Files konusuna bakmanız faydalı olacaktır.

ARCn: Archive Process

LGWR tarafından Online Redo Log yazıldığında, bu log dosyası eğer dolmuş ise ARCn ile dosyanın bir kopyası arşivlenir. Tabii bunun için ARCHIVE LOG modun açık olması gerekir. Eğer Online Redo Log dosyasının arşivlenmesini sağlamazsanız herhangi bir instance çöküşünde bütün dataları kurtarmak mümkün olmayabilir. Temel olarak iki tane Online Redo Log dosyası bulunur, biri dolduğunda diğerine yazılır, doğal olarak diğeri dolduğunda da ilkine geçecektir, elbetteki üzerindeki verileri silerek. Bu yüzden arşivlenmediyse önceki transaction’lara ulaşmanız mümkün olmaz.

DIAG: Diagnosability Process

DIAG’ın temel görevi instance’ı izlemektir ve hata oluştuğu durumda bunu kayıt altına almaktır.

FBDA: Flashback Data Archiver Process

Flashback Database oldukça yeni bir teknoloji sayılabilir. İlk defa Oracle 11g R1 ile hayatımıza girdi. Temelde Flashback Database geçmişe yönelik datalarımıza ulaşmak için kullanılmaktadır. Oldukça eski datalarımıza bile ulaşmamız mümkündür, mesela 1 yılık, 5 yıllık gibi. Bu geçmiş datalar üzerinde bir veri getirme işlemi yürütüldüğünde FBDA devreye girer ve verinin dönmesini sağlar.

DBRM: Database ResourceManager Process

Bu process temelde instance için kaynak planlaması ve implemente edilmesini sağlar.

GEN0: General Task Execution Process

Adından da anlaşılacağı üzere database üzerinde yürütülen işler için thread’leri yönetir. Temelde arkaplanda oluşan blocking durumlarını yönetir. Mesela ASM file’lar üzerinde güvenli bir yazma işlemi yapılacağı zaman bu process tarafından blocking yapılır ve veri tutarlılığı korunacak şekilde değişiklik yapılır.

QMNC ve Qnnn

QMNC, AQ (Advanced Queue) servisini takip eder, kuyruklar ve alert mesajlarını iletir. CJQ0 ise job’ları çalıştırır. Qnnn ise aradaki iletişimi sağlamak ile yükümlüdür. Ayrıca bir database üzerinde herhangi bir taşıma işlemi gerçekleşirse bunu diğer database’ler tarafından da öğrenilmesini sağlamakla yükümlüdür.

EMNC: Event Monitor Processes

Bu process’te AQ mimarisinini bir parçasıdır. Sisteme subscriber olan instance’lara gerekli bilgileri iletir. Bir sistem mesajı OCI (Oracle Call Interface) aracılığı ile register edilir. Register edilen bu mesaj subscriber’lara ulaştırılması için callback OCI fonksiyonu kullanılır. Callback edilen mesaj da EMNC aracılığı ile iletilir.

MMAN: Memory Manager

Bu process SGA boyutunu ayarlama işlemini otomatize eder. Shared Memory component’lerinin boyutlandırılması veya yeniden boyutlandırma yapılması işlemlerini koordine eder.

MMON, MMNL ve Mnnn: Manageability Monitors

Bu process AWR (Automatic Workload Repository)’yi doldurmak için kullanılır. MMNL, SGA’den gelen istatistikleri schedule eder. MMON, database performans sorunlarını otomatik olarak algılar ve tuning işlemini gerçekleştirir. Mnnn ise Jnnn ve Qnnn gibi çalışır, aradaki iletişimi sağlar.

CTWR: Change Tracking Processes

Database üzerinde yapılan değişiklikleri izler ve değişiklikleri korur.

RVWR: Recovery Writer

Bu process Flashback Database komutundan veri kurtarma işleminde eski dataları yazmak için kullanılır. Daha önce de değindiğimiz gibi normalde bir değişiklik yaptığınızda değişiklik öncesinde önce data block’larının snapshot’ı alınır ve eğer Archive Log açıkça bunu saklar ve dilediğiniz tarihteki verilere dönmeniz mümkün olur.

DMnn/DWnn: Data Pump Master/Worker Processes

Data Pump Oracle 10g R1 ile gelen bir özellik. Eski import / export datalarının yeniden yazılabilmesi için tasarlanmıştır. PL/SQL kullanılarak çalıştırılır. Data Pump Master (DMnn) PL/SQL komutları ile girdileri alır ve koordine eder, worker process (DWnn) ile data ve metadata bilgilerini işler.

Slave Process

İki tip slave process bulunur: I/O ve Pnnn.

I/O Slave

I/O slave processler I/O desteği olmayan sistem ve aygıtlar için asenkron I/O yapar. Mesela tape cihazlar için I/O desteği yoktur, I/O slave’ler kullanılarak işletim sistemi için normal sabit diskler gibi I/O desteği sağlamak mümkündür.

I/O slave’ler birkaç yerde kullanılmaktadır: DBWn ve LGWR asenkron I/O simüle etmek istediğinde kullanılır. Yine RMAN tarafından tape cihaza yazmak istediğinde kullanılmaktadır.

I/O slave’ler için iki kontrol parametresi kullanılmaktadır:

BACKUP_TAPE_IO_SLAVES: RMAN tarafından backup veya restore işlemi yapmak için tape kullanılmak istenip istenmediğini belirtir. True veya False boolean değerlerinden birini alır. Default olarak False değerine sahiptir, bu da tape cihazı kullanılmayacağı anlamına gelmektedir.

DBWR_IO_SLAVES: Bu parametre, DBW0 process’i tarafından kullanılabilecek I/O slave sayısını belirtir. DBW0 process’i bellekteki dirty block’ları diske yazarken I/O slave’lerden faydalanabilir, bu performans için iyi olacaktır. Default olarak 0 değeri ile gelir, eğer bu parametrenin değeri 0 olursa hiçbir I/O slave kullanamaz hale gelecektir.

Pnnn: Parallel Query Execution Servers

Select, Create Table, Create Index, Update gibi SQL cümleleri birden çok çalıştırıldığında bunları execution planlarının oluşturulmasına ve çalıştırılmasına yardım eder. Büyük boyutlu tablolarda özellikle çok işe yarar. Mesela elinizde büyük boyutlu block’ları, doğal olarak extent’leri epey yayılmış bir tablo olsun. Sistemde 16 core CPU var ve buradan data çekmek istiyorsunuz, şu halde mecburen adhoc sorgu yürütmek gerekecek. Bu işlemin 32 küçük parçaya ayrılması ise sizin için daha kolaylık sağlayacaktır. Bu tür işlemlerde Pnnn’den faydalanılır ve bu dataları merge etme işlemini de gerçekleştirebilir.

0
0

Patreon

üzerinden bize destek olabilirsiniz!

.

Birlikten kuvvet doğar! Sizde #patreon üzerinden bizim yanımızda olabilirsiniz. Yaptığımız gönüllü çalışmaları arttırmak için bize destek olun.

Ücretli ve Ücretsiz Eğitimler

Türkiye'nin en büyük veri bilimi topluluğu ile kariyerinizi inşa edin.

Data Science Earth

Data Science Earth ekibi, üst düzey Veri Bilim çözümleri üretmek amacı ile toplanmış akademisyenler ve uzmanlardan oluşmaktadır. Öncelikli olarak veri bilincini geliştirmeyi ve küreselleşen rekabet ortamında verinin gücünün doğru kullanılmasını sağlamayı amaçlamaktadır.

Sponsor

QuestionPro 35 farklı soru seçim özelliği ile anket çalışmalarımıza güç katmaktadır.