21 Temmuz 2007 Cumartesi

LOB Tipi

LOB (Large Object, Büyük Nesne) veritipi olan BFILE, BLOB, CLOB ve NCLOB, yapılandırılmamış (unstructured) veri bloklarının 4GB'a kadar depolanmasını sağlar (örneğin metin, grafik görüntüleri, video klipleri, ses gibi). Ayrıca veriye, etkili, rastgele ve parça parça erişime olanak verir.

LOB tipleri LONG ve LONG RAW tiplerinden şu şekilde farklıdır: NCLOB dışındaki LOB 'lar, nesnelerin bir niteliği olabilir, LONG ' lar olamaz. Bir LOB en fazla 4 GB, LONG ise 2 GB olabilir.
LOB 'lar veriye rastgele (random) erişimi, LONG 'lar ise sıralı (sequential) erişimi destekler.

LOB tipleri, lob yerleştiricilerini (lob locators) depolar, bunlar da dışsal (external) bir dosyadaki büyük nesnelere işaret eder (satır içinde veya satır dışında). BFILE verileri ise veritabanı dışında, işletim sistemi dosyalarında sakalanır.

PL/SQL, LOB 'lar üzerindeki işlemleri yerleştiricileri (locators) kullanarak yapar. Örneğin bir BLOB kolon değeri seçildiğinde sadece bir yerleştirici döndürülür, işlem ID'si (transaction ID) bunun başka bir işlemde güncelleme için kullanılmasını engeller; benzer şekilde başka bir oturumda da kullanılamaz.

Oracle9i'den itibaren CLOB 'lar CHAR ve VARCHAR2 'ye çevrilebilir, bunun tersi de geçerlidir. BLOB 'lar RAW'a, RAW 'lar da BLOB 'a çevrilebilir. LOB' lar üzerinde okuma, yazma ve parça parça işlemler yapmak için DBMS_LOB paketi kullanılabilir.

20 Temmuz 2007 Cuma

SUNUCU

Öncelikle Oracle ile ilgili iki kavramın iyi anlaşılması gerekir: veritabanı ve instance (örnek).
Veritabanı, işletim sistemi dosyalarının oluşturduğu fiziksel topluluğa denir. Instance (örnek) ise bir takım Oracle işleçlerinden (process) ve de bir tür bellek olan SGA ‘den (System Global Area) oluşur. Bir veritabanı birden çok instance tarafından açılabilir. Instance ‘ın açtığı veritabanı günden güne veya birkaç saat içinde değişebilir.

Oracle’a bir kullanıcının bağlanması iki türlü olabilir: atanmış sunucu (dedicated server) veya MTS (Multi-Threaded Server) (Çoklu iş parçacıklı sunucu). Atanmış sunucuda oturum (session) boyunca bir sunucu işleci (process), kullanıcı işlece atanır. Her bir oturum için, birebir eşleme şeklinde yeni bir atanmış sunucu oluşacaktır. Bu atanmış sunucu gönderilen SQL komutlarını işleyecektir.

MTS modunda ise Oracle, paylaşılmış sunuculardan (shared servers) oluşan bir havuz kullanır. Bunda kullanıcılar gruplar halinde sunucuları paylaşırlar, böylece ihiyaç duyulan sunucu sayısı belirgin oranda azalır.

MTS ‘de kullanıcı doğrudan sunucu ile bağlantı kuramaz, bunun yerine dağıtıcı (dispatcher) ile bağlantı kurar. Dağıtıcı kullanıcının isteğini SGA ‘deki bir istek kuyruğuna yerleştirir. Boştaki bir sunucu kuyruktan aldığı komutu işler ve sonucu yanıt kuyruğuna yerleştirir. Dağıtıcı, yanıtı kuyruktan alıp kullanıcıya gönderir.

DOSYALAR

Instance ile ilgili olan dosyalar parametre dosyalarıdır. Veritabanı ile ilgili olan dosyalar ise veri dosyaları, redo log dosyaları, kontrol dosyaları, temp dosyalar ve şifre dosyalarıdır.
Parametre dosyalarında kontrol dosyalarının nerde olduğu ve bazı bellek yapılarının büyüklükleri gibi bilgiler tutulur.

Veri dosyaları en önemli dosyalardır, bunlar tablolar, indeksler ve diğer segmentler gibi veritabanını oluşturan temel bilgileri tutarlar. Redo log dosyaları transaction (işlem) kütüklerini (log) tutarlar.

Kontrol dosyaları, veri dosyalarının yerlerini ve durumları hakkındaki bilgiyi tutar. Temp dosyaları disk tabanlı sortları ve geçici depolamaları tutar. Şifre dosyalarında kullanıcı şifreleri tutulur.

Parametre Dosyaları

Bir veritabanının parametre dosyası, init dosyası veya init.ora dosyası olarak bilinir, UNIX’te default adı init.ora ‘dır, Windows’ta ise init%ORACLE_SID%.ora ‘dır. SID ‘si (Site Identifier) tkyte816 olan bir veritabanının init dosyası inittkyte816.ora olacaktır.

Parametre dosyası veritabanının başlatılmasını sağlayan dosyadır, basit bir metin dosyasıdır, dolayısıyla herhangi bir metin editörü ile yazılabilir. Basit bir parametre dosyasında veritabanının adı, veritabanı blok büyüklüğü ve kontrol dosyasının yeri bulunur.

Parametre dosyasının yeri UNIX ‘te $ORACLE_HOME/dbs , Windows’ta ise %ORACLE_HOME%\DATABASE ‘dir. Bu dosyanın içeriği bazen şu şekilde tek bir satır da olabilir:

IFILE=`C:\oracle\admin\tkyte816\pfile\init.ora`

IFILE komutu C’deki #include komutuna benzer şekilde çalışır. Belirtilen yoldaki dosyayı (init.ora) dahil eder.

Veri Dosyaları

Veri dosyaları redo log dosyaları ile birlikte veritabanındaki en önemli dosyalardır. Veritabanındaki bütün veri, en sonunda veri dosyalarında depolanır. Hemen hemen her veritabanında birden fazla veri dosyası olur, en az iki tane olacaktır: biri sistem verileri için biri de kullanıcı verileri için.

Oracle veritabanında nesneleri tutmak için tablespace (tablo alanı), segment (bölüm), extent (kapsam) ve block (blok) gibi paylaşım birimleri kullanır. Depolama alanında yer kaplayan veritabanı nesnelerine segment denir. Bir tablo yarattığımızda tablo segmenti yaratırız. Bölümlü (partitioned) tablo yarattığımızda her bir bölüm için bir segment yaratırız. Aynı şekilde bir index için gene bir index segmenti yaratılır.

Her bir segment bir veya daha fazla extent’ten (kapsam) oluşur. Extent, bir dosyadaki ayrılmış bitişik boşluklardan oluşur. Bir extent tek bir blokla 2GB arasında bir büyüklükte olabilir. Extent, bloklardan oluşur. Blok, Oracle’daki en küçük boşluk paylaştırma birimidir.

Veri satırları, index girişleri ve geçici sort sonuçları bloklarda depolanır. Blok, Oracle’ın diskten okuduğu veya diske yazdığı şeydir. Bloklar genelde 2KB, 4KB veya 8KB büyüklükte olur (16 KB ve 32 KB’a da izin verilmiştir). Blok büyüklüğü veritabanı oluşturulduktan sonra değiştirilemez, veritabanındaki bütün bloklar aynı büyüklüktedir.

Bir blok şu bölümlerden oluşur: Header (başlık), Table Directory (Tablo Dizini), Row Directory (Satır Dizini), Free Space (Boş Alan), Data (Veri). Bunlardan ilk üçüne Block Overhead (Blok Yükü) denir ve Oracle tarafından bloğun yönetiminde kullanılır, buraya veri yazılamaz.

Tabloalanı (Tablespace), segmentleri içeren bir yüklüktür (container). Her bir segment tek bir tabloalanına aittir. Bir segmentin bütün extentleri, segmentin bulunduğu tabloalanında bulunacaktır. Bir tabloalanındaki herhangi bir segmentin bir extenti bütünüyle tek bir veri dosyasında yer alacaktır, ancak bir segment farklı veri dosyalarında bulunan extentlere sahip olabilir.

Bir veritabanı bir veya daha fazla tabloalanından oluşur. Bir tabloalanı bir veya daha fazla veri dosyası içerir ve de segmentleri içerir.

Temp Dosyalar

Oracle’daki geçici veri dosyaları (temp files), özel bir tip veri dosyasıdır. Oracle RAM’da yeterli yer olmadığında sort işlemlerinin ara sonuçlarını ya da sonuç kümesini bu temp dosyalara yazar, kalıcı veri nesneleri bu dosyalarda saklanmaz.

Normalde, Oracle’da bir nesneye yapılan değişiklik redo kütüklerinde (log) saklanır, ancak temp dosyaları için bu geçerli değildir. Temp dosyaları için ise UNDO oluşturulur. Veritabanının yerel yönetimli geçici tabloalanları ile konfigüre edilmesi önerilmektedir. DBA, CREATE TEMPORARY TABLESPACES komutunu kullanmalıdır.

Kontrol Dosyaları

Kontrol dosyası oldukça küçük bir dosyadır, anormal şartlarda 64 MB’a kadar büyüyebilir, Oracle’ın ihtiyaç duyduğu diğer dosyaların dizinini tutar. Parametre dosyası (init.ora dosyası) Oracle instance’ına kontrol dosyalarının nerede olduğunu söyler, kontrol dosyaları da instance’a veritabanının ve online redo log dosyalarının nerede olduğunu söyler ayrıca checkpointler, veritabanının adı ve archive redo log geçmişi (history) hakkında da bilgi verir.

Kontrol dosyaları ya donanımla (RAID) çoklanmalıdır ya da ayrı ayrı disklerde birden fazla kopyası alınmalıdır (diskin bozulma ihtimaline karşın), bu dosyaların kaybolması kurtarma (recovery) işlemini zorlaştırır.

Redo Kütük (Log) Dosyaları

Bu dosyalar Oracle veritabanı için çok önemlidir, veritabanının işlem kütükleridir (transaction logs), sadece kurtarma (recovery) amaçlı kullanılırlar (instance veya ortam bozulmasında) veya destek (standby) veritabanı tutmak için. Instance’ın çökmesi halinde online redo kütükleri (logs) kullanılır.

Sabit diskin bozulması halinde ise hem archived redo kütükleri hem de online redo kütükleri (logs) kullanılır ayrıca bu iki kütük yanlış bir commit işleminin geri alınması için de kullanılabilir.

Online Redo Kütüğü (log)

Her Oracle veritabanı en az iki tane online redo kütüğüne sahiptir ve bunların büyüklükleri sabittir. Oracle bir kütük dosyasına yazmayı bitirdikten sonra diğer kütük dosyasına yazmaya başlar, bu geçişe kütük değiştirme (log switch) denir ve kötü ayarlanmış bir veritabanında veritabanının geçici olarak beklemede kalmasına neden olabilir.

Oracle içindeki bilgileri kullanmayacağına emin değilse, online redo kütüğündeki veriler diske yazılana kadar veritabanı işlemlerini geçici olarak durdurur.

Veritabanı tampon önbelleği (database buffer cache), veritabanı bloklarının geçici olarak depolandığı yerdir, Oracle’ın SGA (System Global Area) kısmında bulunur, bloklar okundukça burada depolanır. Bu önbelleğin görevi fiziksel I/O işlemlerini hızlandırmaktır.

Örneğin bir UPDATE komutu ile bir blokta değişiklik yapılırsa, bu değişiklik tampon önbellekteki (buffer cache) bloklarda yapılır, geri alma için gerekli bilgi redo log tamponunda (redo log buffer) tutulur. COMMIT komutu ile de redo log tamponundaki veriler online redo kütüğüne aktarılır ve böylece veriler sabit hale gelir.

Database block writer (DBWn) işleci (process), arkaplanda (background) çalışır, buffer cache’deki (tampon önbellek) verileri sabit diske yazar. Farklı uygulamalar farklı sayıda online redo kütüklerine ihtiyaç duyar, ihtiyaç tiplerini üçe ayırabiliriz:

Destek Veritabanı (standby database) : Redo kütükleri dolduktan ve veritabanının kopyasına uygulandıktan sonra destek veritabanına gönderiliyorsa çok sayıda küçük redo kütük dosyası kullanmak yerinde olacaktır, böylece destek veritabanı sürekli güncel kalır.

Pek Çok Kullanıcının Aynı Blokları Değiştirmesi : Diske yazmadan önce bloklar mümkün olduğunca çok defa güncellenmelidir (update) ve de checkpoint sayısını azaltmak için kütükler seyrek değiştirilmelidir, bu yüzden büyük redo kütük dosyaları kullanılamalıdır.

Kurtarma İçin Gereken Süre (Mean Time to Recover) : Küçük ve çok sayıda redo kütüğü kullanmak kurtarma süresini kısaltır ancak veritabanının işleyişini yavaşlatır.

Archived Redo Kütüğü (log)

Bir Oracle veritabanı ARCHIVELOG modunda çalıştırılmalıdır aksi halde eninde sonunda veri kaybı olacaktır. Sadece test veya geliştirme sistemleri NOARCHIVELOG modunda çalıştırılabilir.

RAID desteği bile olsa donanıma fazla güvenilmemelidir çünkü sabit disklerin bozulma ihtimali vardır. Düzgün konfigüre edilmiş bir arşivleme fazla bir yük getirmez. Veri kaybeden hızlı bir sistem kullanışsız olacaktır.

BELLEK YAPILARI

Üç temel bellek yapısı vardır, bunlar:

SGA (System Global Area) (Sistem Küresel Alanı) : Bu büyük paylaşımlı bir bellek bölümüdür, bütün Oracle işleçleri (process) eninde sonunda buraya erişirler.

PGA (Process Global Area) (İşleç Küresel Alanı) : Bu alan tek bir işlece (process) veya iş parçacığına (thread) özeldir, diğerleri bu alana erişemez.

UGA (User Global Area) (Kullanıcı Küresel Alanı) : Bu alan oturum ile ilişkilendirilmiştir. MTS modunda SGA’de bulunur, atanmış sunucu (dedicated server) modunda ise PGA’de bulunur.

PGA ve UGA

PGA tipik olarak C’nin çalışma zamanı çağrısı (run-time call) malloc() ile oluşturulur ve çalışma zamanında küçülüp büyüyebilir. PGA her zaman SGA’in içindedir. UGA ise oturuma aittir ve yeri Oracle’ın konfigüre edilme şekline göre değişir.

PGA ve UGA’in büyüklüğünü etkileyen en önemli etkenlerden biri init.ora ‘daki oturum seviyesi parametreleri olan SORT_AREA_SIZE ve SORT_AREA_RETAINED_SIZE ’dır. Bunlar Oracle’ın diske yazmadan önce verilerin sort işlemi için ne kadar alan ayıracağını ve işlemden sonra bu alanın ne kadarını tutacağını belirler. SORT_AREA_SIZE genelde PGA ‘in dışında yer alır, SORT_AREA_RETAINED_SIZE ise UGA ‘in içinde olur.

SGA

Her bir Oracle instance’ının (örnek) büyük, paylaşımlı bir bellek yapısı vardır, buna topluca SGA (System Global Area) (Sistem Küresel Alanı) denir. Oracle işleçleri (process) bu alana erişirler. SGA’i görüntülemek için V$SGASTAT adlı sihirli (magic) V$ tablosu kullanılabilir.
SGA çeşitli havuzlara (pool) ayrılmıştır, bunlar:

Java pool (Java Havuzu) :Veritabanında çalışan JVM için ayrılmıştır, sabit büyüklüktüktedir.

Large pool (Büyük Havuz): MTS tarafından oturum belleği (session memory) için, Paralel İşlem (Parallel Execution) tarafından mesaj tamponları (message buffers) için ve RMAN (Recovery Manager) Backup (Kurtarma Yöneticisi Yedekleyicisi) tarafından disk I/O tamponları (buffers) için kullanılır.

Shared pool (Paylaşımlı Havuz) : Paylaşımlı kürsörleri, kayıtlı yordamları (stored procedures), durum nesnelerini (state objects), dizin önbelleklerini (directory caches) ve diğer pek çok veriyi tutar.

The ‘Null’ pool : Bu bölümün aslında bir adı yoktur. Üç bellek türünü içerir: Blok tamponları (block buffers) (cached database blocks), redo kütük tamponu (redo log buffer) ve sabit (fixed) SGA.

Sabit SGA (Fixed SGA)

Genellikle çok küçüktür. Büyüklüğü platformdan platforma ve sürümden sürüme değişir. Kurulum sırasında Oracle binary’ye derlenir, bu yüzden sabittir. SGA, bu bölümü SGA’in diğer bölümlerine ve parçalarına erişmek için kullanır. Çeşitli parametre değerlerini tutan ve SGA’in diğer bileşenlerine işaret eden değişkenleri tutar.

Redo Tamponu (Redo Buffer)

Online redo kütüklerine (log) yazılacak veriler diske yazılamadan önce geçici olarak burada tutulur. Redo kütük tamponlarının (redo log buffer) kullanımı veritabanının işleyişini hızlandırabilir. Bu bölümün içeriği şu durumlarda boşaltılır:

3 saniyede bir veya birisi commit (işlemek, teslim etmek) ettiğinde veya üçte biri dolduğunda veya verilerin toplamı 1 MB’a ulaştığında. Bir veritabanı sisteminin bir iki MB’tan daha büyük bir redo tamponuna ihtiyaç duyması çok ender görülen bir durumdur.

Redo tamponunun ayarlanmamış (default) büyüklüğü 512 KB ile (128*CPU sayısı)’dan büyük olanın değerine eşittir, bu init.ora dosyasındaki LOG_BUFFER parametresi ile kontrol edilir. Redo tamponunun en küçük büyüklüğü ise en büyük veri bloğunun dört katıdır.

Blok Tampon Önbelleği (Block Buffer Cache)

Oracle, veritabanı bloklarını diske yazmadan önce ve diskten okuduktan sonra burada depolar. Bu bölüm küçük olursa sorgular çok uzun sürer, büyük olursa diğer işleçler (process) görev yapamaz hale gelir.

Üzerine veri yazılmış bloğa ‘kirli’ blok, henüz üzerine veri yazılmamış yani boş olan bloğa da ‘temiz’ blok denir. Kirli bloklar ayrı bir listede, temiz bloklar ayrı bir listede tutulur. Kirli bloklar Veritabanı Blok Yazıcısı (Database Block Writer, DBWn) tarafından yazılır.

Oracle, her bir blok için ‘dokunma sayısı’ (touch count) şeması tutar. Önbellekteki blok hit aldıkça sayacı bir artırılır. X$BH tablosu, Blok Tampon Önbelleğindeki (BTÖ) bloklar hakkında bilgi verir.

Oracle 8.0’dan itibaren BTÖ’ye çoklu tampon havuzları özelliği eklenmiştir. Bu özellik sayesinde BTÖ’de belirli miktarda bir alan özel segmentler için ayrılabilir (örneğin lookup tabloları için). Bu ayırdığımız alandaki blokların ilgisiz bloklar tarafından yaşlandırılmasını (age out) engeller. Yaşlanmaya dayalı saklamaya, saklama havuzu (KEEP pool) denir.

Geri dönüşüm havuzlarında (RECYCLE pool) ise blok, ihtiyaç duyulmaz hale gelir gelmez yaşlandırılır.

Paylaşımlı Havuz (Shared Pool)

Başarım (performance) ve ölçeklenirlik (scalability) açısından önemlidir. Küçük olursa başarımı durma noktasına kadar düşürebilir, çok büyük olursa da gene aynı etkiyi yapacaktır, yanlış kullanıldığı takdirde de sonuç felaket olacaktır.

Oracle pek çok program veri parçasını burada önbellekler, örneğin bir sorgunun (query) ayrıştırma (parse) sonuçları gibi. Bir sorgu ayrıştırılacağı zaman Oracle öncelikle buraya bakar, daha önce yapılmış mı diye.

PL/SQL kodu burada önbelleklenir, böylece bir dahaki sefere diskten okunması gerekmez ve paylaşılır da, örneğin aynı anda işleyen 1000 tane oturum varsa kodun tek bir kopyası bunlar arasında paylaşılır.
Sistem parametreleri, veri dizin önbelleği (data dictionary cache) ve nesneler hakkındaki önbelleklenmiş bilgi burada tutulur. Paylaşımlı havuz yaklaşık 4 KB büyüklüğündeki bellek parçalarından oluşur ve bellek LRU (Leasy Recently Used) (En Seyrek Kullanılan) ile yönetilir. Paylaşımlı havuz, sorgu planlarının tekrar tekrar kullanılması için tasarlanmıştır.

Büyük Havuz (Large Pool)

Büyük bellek parçalarını tutmak için kullanılır, paylaşımlı havuzun tutmakta zorlanacaklarını. Büyük havuz, geri dönüşüm havuzuna (recycle pool) benzer (yaşlandırma kullnılmaz, veriye ihtiyaç ortadan kalkar kalkmaz silinir). Paylaşımlı havuz ise saklama havuzuna (keep pool) benzer.

Büyük havuzdaki bir bellek parçası serbest bırakıldığı anda bir başka işleç (process) tarafından kullanılabilir. Büyük havuz özellikle
1) MTS tarafından UGA için,
2) İfadelerin paralel yürütülmesi (parallel execution of statements) için,
3) Yedekleme (Backup) için (RMAN disk I/O tamponları için) kullanılır.

MTS kullanırken büyük havuz kullanılması zorunlu değildir ancak kullanılaması tavsiye edilir ayrıca büyük havuz büyüklüğünün elle ayarlanması tavsiye edilir. Ayarlanmamış değer durumunuz için uygun olmayacaktır.

Java Havuzu (Java Pool)

Javada bir kayıtlı yordam (stored procedure) kodlanırsa veya veritabanına EJB (Enterprise JavaBean) eklenirse, Oracle bu kodları işlemek için Java Havuzunu kullanır, çalışma moduna göre kullanım şekli değişir.

Atanmış sunucu (dedicated server) modunda her bir java sınıfının paylaşılan kısımlarını içerir ki bunlar aslında her oturum başına kullanılırlar, her sınıf başına 4-8 KB’lık salt okunur (read-only) kısımlardır. Atanmış sunucu modunda oturum başına durum (per-session state) UGA’da tutulur.

MTS modunda Java havuzu şunları içerir: her bir java sınıfının paylaşılan kısmı ve her bir oturumun, oturum başına durumu için kullanılan UGA’nın bir kısmı. Java havuzunun toplam büyüklüğü sabittir bu yüzden uygulamaların bellek ihtiyacı ile oturum sayısının çarpımı bilinmelidir. “MTS modunda Java havuzu çok büyük hale gelebilir çünkü eşzamanlı (concurrent) kullanıcıların sayısına bağlıdır.

İŞLEÇLER (The Processes)

Bir Oracle instance’ını (örnek) bellek ve işleçler oluşturur. İşleç dediğimiz şeylerin windowstaki karşılığı iş parçacığıdır (thread). Üç tip işleç vardır:

1) Sunucu İşleçleri (Server Processes) : Bir kullanıcının isteği üzerine çalışır; atanmış ve paylaşımlı sunucular gibi.
2) Arkaplan İşleçleri (Background Processes) : Veritabanının başlatılması ile çalışırlar ve çeşitli bakım görevleri yaparlar; blokları diske yazmak, online redo kütüğünün bakımı, bitirilen işleçlerin temizlenmesi gibi.
3) Esir İşleçler (Slave Processes) : Arkaplan işleçlerine benzerler ancak bir arkaplan veya sunucu işleci adına fazladan iş yaparlar.

Sunucu İşleçleri (Server Processes)

Atanmış ve paylaşımlı sunucular aynı işi yapar; onlara verilen SQL’i işler. Bir sorgu gönderildiğinde bunu ayrıştırır ve paylaşımlı havuza koyarlar (veya orda bulurlar). Sorgu planını bu işleç oluşturur, gerekli veriyi tampon önbellekten okur veya diskten tampon önbelleğe okur. En fazla CPU zamanını bu işleçler kullanır; sort, sum ve birleştirme (join) işlemlerini yaparlar.

Atanmış sunucu modunda kullanıcı oturumu ile sunucu işleci arasında birebir eşleme vardır; 100 oturum varsa 100 işleç olacaktır. Kullanıcı ile sunucu arasında Net8 ağ (network) yazılımı/protokolü kullanılır. Atanmış sunucular için Oracle Net8 Dinleyici İşleci (Listener Process) şart değildir ancak paylaşımlı sunucular için şarttır.

Atanmış Sunucuya Karşı Paylaşımlı Sunucu

SQL tabanlı uygulamalar Oracle veritabanına bağlanmak için en yaygın olarak atanmış sunucu modunu kullanırlar (kurması daha kolaydır, hiç/çok az konfigürasyon gerektirir, MTS ise birkaç basit basamak daha gerektirir). Kullanıcı oturumu ile sunucu arasında, atanmış sunucu modunda birebir eşleme varken MTS’de bireçok eşleme vardır; çok kullanıcıdan tek paylaşımlı sunucuya.

MTS, kısa ve sık işlemli (transaction) OLTP sistemleri için çok uygundur ancak veri depoları (data warehouse) için hiç uygun değildir, bunlarda bir sorgu 1, 3, 5 dakika ya da daha fazla sürebilir. Atanmış sunucu ve MTS, tek bir instance’da (örnek) birlikte kullanılabilir. MTS’in avantajları şunlardır:

1) İşletim sistemi (OS) işleçlerinin ve iş parçacıklarının sayısını azaltır : Çok kullanıcılı sistemlerde kullanıcıların sadece küçük bir kısmı aynı anda aktiftir (örneğin %1).
2) Eşzamanlılığın (concurrency) derecesinin suni olarak ayarlanmasına izin verir : Belli bir sınıra kadar eşzamanlı kullanıcı sayısı arttıkça işlem (transaction) sayısı da artar, sonra artış durur ve eşzamanlı kullanıcı arttığı halde işlem sayısı düşmeye başlar. En yüksek işlem hacmi (throughput) için, en yüksek eşzamanlılık bu nokta ile sınırlanmalıdır.
3) Sistemde ihtiyaç duyulan belleği azaltır: MTS kullanıldığında UGA, SGA’in içinde tutulur. MTS kullanılırken ne kadar UGA belleğe ihtiyaç duyulacağı iyice belirlenmelidir. Her bir atanmış/paylaşımlı sunucu PGA kullanır, MTS kullanıldığında ihtiyaç duyulan PGA azalır böylece daha az bellek kullanılır.

ODAKLI ARKAPLAN İŞLEÇLERİ (Focused Background Processes)

PMON – İşleç Denetleyicisi (The Process Monitor)

Anormal bir şekilde sonlandırılan bağlantıları temizlemekle sorumludur. Örneğin atanmış sunucu başarısız olursa veya öldürülürse, kullandığı kaynakların geri verilmesinden PMON sorumludur; commit edilmemiş çalışmayı geri yuvarlar (rollback), kilitleri ve SGA kaynaklarını serbest bırakır.

PMON ayrıca gerekli durumlarda diğer arkaplan işleçlerini de çalıştırır, ayrıca Net8 dinleyicisi (listener) ile bağlantı kurar. Oracle için kullanılan ayarlanmamış (default) port 1521’dir.

SMON – Sistem Denetleyicisi (The System Monitor)

Veritabanının çöp toplayıcısıdır (garbage collector). Sorumlu olduğu işlerin bazıları şunlardır:
Geçici alanların (Temporary Space) temizlenmesi – Örneğin bir index sonlandırıldığında onunla ilişkili extentleri temizler.
Çökme kurtarma (Crash Recovery)
Boş alanları birleştirme
– Dizin yönetimli tabloalanlarında (dictionary-manged tablespaces) boş ve bitişik olan extentleri tek bir büyük boş extente çevirir.
Kullanılamayan dosyalara yönelik aktif işlemlerin (transactions) kurtarılması
OPS’deki başarısız düğümün (node) instance’ının kurtarılması – Oracle Paralel Sunucu konfigürasyonunda instance’ın başka bir düğümü (node) başarısız düğümün redo kütük dosyalarını açarak bütün verileri kurtarır.
OBJ$’ı temizlemek – OBJ$, düşük seviyeli bir veri dizini tablosudur (data dictionary table), hemen hemen her nesne için bir giriş içerir. SMON, silinmiş veya ulaşılamayan neselere ait satırları siler.
Rollback segmentlerinin otomatik olarak ideal büyüklüğüne döndürülmesi
Rollback segmentlerini ‘offline’ yapar – DBA, aktif işlemleri olan bir rollback segmentini ‘offline’ veya kullanılamaz yapabilir.

RECO – Dağınık Veritabanı kurtarma (Distributed Database Recovery)

İki evreli commit (two-phase commit,2PC) sırasında, çökmeden veya bağlantı kopmasından dolayı hazır durumda bırakılmış işlemleri kurtarır. 2PC, dağınık bir protokoldür, birbirinden farklı pek çok veritabanındaki değişiklikle atomik commit’e imkan verir, commit edilmeden önce dağınık başarısızlığa (failure) karşı pencereyi kapatmaya çalışır.

CKPT – Checkpoint İşleci

Checkpoint işlemi yapmaz, veri dosyalarının başlıklarını güncelleyerek checkpoint işlemine yardımcı olur.

DBWn – Veritabanı Blok Yazıcısı (Database Block Writer)

DBWn, kirli (içinde veri olan) blokları asychronous I/O kullanarak diske yazar, çok sayıda dağınık (scattered) yazım yapar oysa LGWR (Log Writer) redo kütüğüne sıralı yazım yapar. DBWn, checkpointi ilerletmek için veya yer açmak için tampon önbellekten (buffer cache) diske yazar.

Görevini yeterince hızlı yapamazsa FREE_BUFFER_WAITS veya ‘Write Complete Waits’ mesajlarını görebiliriz. 10 tane DBWn konfigüre edilebilir, bunun için init.ora parametresi DB_BLOCK_LRU_LATCHES yükseltilmelidir.

LGWR – Kütük Yazıcısı (Log Writer)

SGA’deki redo kütük tamponunun (redo log buffer) içeriğini sıralı (sequential) olarak diske yazar, bunu 3 saniyede bir yapar veya birisi commit ettiğinde vaya üçte biri dolduğunda veya veri toplamı 1 MB’a ulaştığında yapar. Bu Yüzden çok büyük bir redo kütük tamponu kullanışlı değildir.


ARCn – Arşiv İşleci (Archive Process)

ARCn işlecinin görevi, LGWR onu doldurduktan sonra, online redo kütük dosyasını başka en az iki farklı yere kopyalamaktır, bu dosyalar daha sonra ortam kurtarma (media recovery) için kullanılabilir. Online redo kütüğü bir güç kesintisinde veri dosyalarını onarmak için kullanılır, arşiv redo kütükleri ise sabit diskin bozulması durumunda veri dosyalarını onarmada kullanılır.

BSP- Blok Sunucu İşleci (Block Server Process)

Sadece Oracle Paralel Sunucu (OPS) ortamında kullanılır. OPS’de birden fazla instance aynı veritabanını açar. Bunun için SGA blok tampon önbellekleri (block buffer caches), birbirlerine karşı tutarlı durumda tutulmalıdır, BSP’nin ana amacı budur.

LMON – Kilit Denetleyici İşleç (Lock Monitor Process)

Sadece Oracle Paralel Sunucu (OPS) ortamında kullanılır. Bir başarısızlık durumuna karşı bir öbekteki (cluster) bütün instanceları denetler, başarısız olan instance’ın küresel kilitlerini kurtarır, dağınık kilit yöneticisi (distributed lock manager, DLM) ile birlikte.

LMD – Kilit Yöneticisi Daemonu (Lock Manager Daemon)

Sadece Oracle Paralel Sunucu (OPS) ortamında kullanılır. Öbekli ortamda (clustered environment) blok tampon önbelleği için küresel kilitleri ve kaynakları kontrol eder. Ayrıca küresel deadlock denetimini ve çözümlemesini (resolution) de yapar.

LCKn – Kilit İşleci (Lock Process)

Sadece Oracle Paralel Sunucu (OPS) ortamında kullanılır. İşlev olarak LMD’ye çok benzer, ancak bütün küresel kaynaklar için olan istekleri değerlendirir.

KULLANIŞLI ARKAPLAN İŞLEÇLERİ (Utility Background Processes)

Bu işleçler bütünüyle seçimseldir, yani isteğe bağlıdır.

SNPn – Snapshot İşleçleri (Snapshot Processes) İş Kuyrukları (Job Queues)

36 tane iş kuyruğu işleci olabilir, adları şöyle olacaktır: SNP0, SNP1,…, SNP9, SNPA, …, SNPZ. SNPn işleçleri atanmış sunucuyla paylaşımlı sunucunun karışımı gibidir. İşleri birbiri ardına yaparlar ama belleği atanmış sunucu gibi kullanırlar. Her bir iş kuyruğu her seferinde tek bir iş yapacaktır.

QMNn – Kuyruk Denetleyici İşleçler (Queue Monitor Processes)

Gelişmiş kuyrukları (Advanced Queues) denetlerler ve bir mesaj elverişli hale geldiklerinde bekleyenleri haberdar ederler. Ayrıca kuyruk oluşturulmasından da sorumludurlar. init.ora parametresi AQ_TM_PROCESS ile 10 tane oluşturulabilir; QMN0, …, QMN9.



EMNn – Olay Denetleyici İşleçler (Event Monitor Processes)

Gelişmiş kuyruk (Advanced Queue) mimarisinin bir parçasıdır, kuyruk abonelerine asynchoronous olarak mesajlar gönderir.

ESİR İŞLEÇLER (Slave Processes)

I/O Esirleri

Asynchronous I/O ‘yu desteklemeyen sistemlerde (kasetler (tape) gibi), asynchoronous I/O etkisini oluşturmak için kullanılırlar. İşleç önce büyük bir miktar veriyi yığın olarak tutar ve bu yazıldıktan sonra bittiğini haber verir, böylece yavaş aygıt için I/O esirleri bekler ve işlem hacmi (throughput) artar. DBWn, LGWR ve RMAN, I/O esirlerini kullanır.

Paralel Sorgu Esirleri (Parallel Query Slaves)

SQL komutları için (örneğin SELECT, CREATE TABLE, UPDATE gibi), tek bir yürütme (execution) planı yerine pek çok yürütme planı aynı anda paralel olarak uygulanır. Her bir planın sonuçları birleştirilerek tek bir büyük sonuç elde edilir. Böylece işlem daha hızlı yapılmış olur (sıralıya (sequential) göre).