ORACLE DERS 2

SERVER KONFİGİRASYONLARI

Dedicated Servers

Her bir Client prcessi için server tarafında Server processi ayarlanır.Client tarafı ve Server ayrı olması

zaten bir avantaj oluşturur.

Shared Servers

Kullanıcılar Server üzerinde bulunan Server Processlerini paylaşırlar.Bunuda Server üzerinde bulunan

Dispatchelar vasıtası ile yaparlar.İstek kuyruğa girip eğer yeterli Server prosesi varsa devreye

alınır.Dedicated server da 100 tane user prosesi için 100 tane server prosesi gerekir.Ama Shared server

da sadece 10 tane server prosesi yeterlidir.Böylece memory kullanımı daha etkin olabilir.

Tnsnames.ora file ında,Server=Shared yada Dedicated diyerek ayarlama yapabiliriz.

ORADATA =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = administ-db80da)(PORT = 1521))

)

(CONNECT_DATA =

(SERVICE_NAME = ORADATA)

(SERVER = DEDICATED)

)

)

1-)Listener herhangi bir bağlantı olup olmadığını bekler,Eğer bir bağlantı olursa ilgili dispatcher ı

ayarlamaya çalışır.

2-)Eğer bağlantı gerçekleşmişse Listener dispatcher’ın adresini kullanıcıya verir.

3-)En son kullanıcı dispatcherla bağlantıyı sağlamış olur.

1-)Kullanıcı dispatcher a bir istek yollar.

2-)Dispatcher bunu SGA da istek kuyruğuna yerleştirir.

3-)Shared server ilgili isteği istek kuyruğundan alır.

4-)Daha sonra shared server bunu Dispatcher’ın cevap kuyruğuna yerleştirir.

5-)Dsipatcher cevabı kuyruktan çeker.

6-)Daha sonra cevap kullanıcıya döner.

İnit.ora file’ın içinde dispatcher sayısı ayarlanabilir.

Aynı şekilde shared server sayısıda init.ora dosyası içinden ayarlanabilir.

İnit.ora dosyasından yine aynı şekilde max_dispatchers,max_shared_servers,

SHARED_SERVER_SESSIONS, ayarlanabilir.

CIRCUITS

User Prosesleri Dispatcher la aktif olduğundan itibaren birer Circuit oluşturular.İnit.ora dosyasında circuits

parametresi bu bağlantı sayısını gösterir.

$ lsnrct l services listener_name

Yazarak servislerin durumu kontrol edilebilir.

Aynı zamanda V$CIRCUIT, V$SHARED_SERVER, V$DISPATCHER, V$SHARED_SERVER_MONITOR,

V$QUEUE, V$SESSION dictionary view lardan da yardım alınabilir.

DATA DİCTİONARY VİEW LARI KULLANIMI

Datadictionary viewlar ve dinamci performans viewları ile sistem hakkında çok detaylı bilgiler

toplayabilmekteyiz.

Database’in mantıksal ve fiziksel yapısı ile ilgili bilgiler alınabilir,

Objelerin doluluk oranları ile ilgili bilgiler toplanabilir,

Tablolar arasındaki ilişkiler gözlemlenebilir,

Kullanıcılar,roller ve yetkiler hakkında bilgi alınabilir.

Oracle sistemi yetkilendirilmelirine dayalı olduğu için bazı viewlara erişip bazılarına erişimimiz yoktur.

Örneğin,

SQL > SELECT owner, object_name, object_type

FROM dba_objects;

SQL > SELECT owner, object_name, object_type

FROM all_objects;

SQL > SELECT owner, object_name, object_type

FROM users_objects;

İle arasındai farklar görülebilir.

SQL > SELECT * FROM dictionary; komutu çalıştırılar database’in kullandığı tüm data dictionary viewlar

görülebilir.

Dinamik performans viewları ise V$_ ile başlamaktadır,

Örneğin

SQL > SELECT * FROM V$FIXED_TABLE;

SQL > SELECT * from V$INSTANCE;

CONTROL FILE VE YÖNETİMİ

Her Oracle veritabanının bir kontrol dosyası vardır. Kontrol dosyasında veritabanının fiziksel

yapısı ile ilgili bilgileri tutulur. Veritabanı, redo log dosyalarında olduğu gibi kontrol dosyalarının da birden

fazla kopyasının tutulmasını desktekler. Kontrol dosyalarında tutulan bilgilerin bazıları veritabanının adı,

redo log dosyalarının yerleri ve adları, veritabanın yaratıldığı zamandır. Oracle veritabanı örneğinin her

açılışında, kontrol dosyası veritabanı ve redo dosyalarının yerlerinin bulunup veritabanı işlemlerine

açılması için kullanılır. Eğer veritabanının fiziksel yapısında bir değişiklik olursa, kontrol dosyası Oracle

tarafından otomatik olarak değiştirilir. Kontrol dosyası veritabanının kurtarılmasında da kullanılır.

Kontrol file’lar database’in mount modunda aktif olurlar.Bir kontrol file aşağıdaki gibi bilgileri tutmaktadır.

Database ismini ve kimliğini

Database’in yaratılma zamanını

Tablespacelerin isimlerini

Datafile ve Redologların isim ve lokasyonları

Aktif olan redolog’un sequnce numaasını

Checkpoint bilgisini

UndoSegment’in başlangıcı ve Sonu

Redolog Arşiv bilgisini

Backup bilgisini.

Kontrolfile’lar db lokasyonunda control01.ctl,control02.ctl,control03.ctl isimli olarak db yaratılırken

oluşurlar.Bunları daha sonra çoğaltmak mümkündür.Ama DB ilk oluştğunda 3 tane oluşur.DB üzerinde

yapılan herhangi bir değişiklik otomatik olarak her birine yansır.

CONTROL FILE ÇOĞALTIMI

İlk olarak SPFILE kullanarak bu çoğaltmayı yapmak istiyorsak,

$ SQLPLUS /NOLOG

SQL> CONNECT SYS/ORACLE@NEWDB as sysdba;

SQL> shutdown immediate;

$ CP d:\oracle\oradata\newdb\CONTROL01.CTL d:\oracle\oradata\newdb\CONTROL04.CTL

SQL> startup nomount;

SQL> ALTER SYSTEM SET control_files =

‘d:\oracle\oradata\newdb\CONTROL01.CTL’,’d:\oracle\oradata\newdb\CONTROL02.CTL’,’d:\oracle\oradat

a\newdb\CONTROL03.CTL’ , ’d:\oracle\oradata\newdb\CONTROL04.CTL’ SCOPE=BOTH;

SQL> ALTER DATABASE MOUNT;

SQL> ALTER DATABASE OPEN;

Eğer bu işlemi init.ora dosyasından yapmak istersek,

$ SQLPLUS /NOLOG

SQL> CONNECT SYS/ORACLE@NEWDB as sysdba;

SQL> shutdown immediate;

$ CP d:\oracle\oradata\newdb\CONTROL01.CTL d:\oracle\oradata\newdb\CONTROL04.CTL

Bu aşamada initi.ora dosyasını açıp içine

control_files=d:\oracle\oradata\oradata\CONTROL01.CTL, d:\oracle\oradata\oradata\CONTROL02.CTL,

d:\oracle\oradata\oradata\CONTROL03.CTL, d:\oracle\oradata\oradata\CONTROL04.CTL

ekliyoruz.

SQL> startup

İstenirse control file ‘ın backup’ını almakta mümkündür.Bunu aşağıdaki komutlarla yapabiliyoruz.

SQL> ALTER DATABASE BACKUP CONTROLFILE TO 'FILENAME'

SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

Kontrol file ların durumu ve içeriği hakkında bilgi almak istiyorsak dinamik performanc viewlarına

başvurmak gerekmektedir.

SQL> SELECT name FROM V$CONTROLFILE;

NAME

------------------------------------

/u01/home/db03/ORADATA/u01/ctrl01.ctl

/u01/home/db03/ORADATA/u01/ctrl01.ctl

2 rows selected.

SQL> SELECT name, value from V$PARAMETER

WHERE name = ‘control_files’;

NAME Value

------------- -------------------------------------

control_files /u01/home/db03/ORADATA/u01/ctrl01.ctl

SQL> SELECT type, record_size, records_total, records_used

FROM v$controlfile_record_section

WHERE type=’DATAFILE’;

TYPE RECORD_SIZ RECORDS_TO RECORDS_US

------- ---------- -------- ------------------

DATAFILE 180 30 4

1 row selected.

SQL> show parameters control_files;

NAME TYPE VALUE

------------ ------- ------------------------------

control_files string /u01/home/db03/ORADATA/u01/ctrl01.ctl

REDOLOGLAR VE YÖNETİMİ

Veritabanındaki tüm “commit” olmuş değişikliklerin , kurtarma yapılırken kullanılmak üzere kaydedildiği

dosyalardır. En az iki redo log grubu tanımlanır. Bu dosyaların boyu ve grup sayısı veri tabanı yaratılırken

sisteme tanımlanır. Sonradan bu tanımlar değiştirilebilmektedir. Redo log dosyalarının boyu , ideal olarak

yarım saatte bir değişecek (swich) şeklinde ayarlanmalıdır. Redo log dosyalarının çok küçük olması ,

sistemde beklemelere neden olur. Çok büyük olmasa da veri tabanı açılırken yapılan otomatik kurtarma

işleminin çok uzun sürmesine yol açar ve aktif redo log dosyalarının silinmesi yada bozulması durumunda

da daha fazla veri kaybı olmasına neden olur. Redo log dosyalarının boyunun iyi ayarlanamaması

Oracle’ın dezavantajlarına bir örnek oluşturmaktadır.

Sistemin güvenliği açısından her gruptaki redo log’u iki kopya olarak veri tabanı farklı disketlerde yaratmak

gerekir. Redo log’lar kesinlikle raid disk üzerine konulmamalıdır. Çünkü redo log dosyaları üzerine sürekli

yazma yapılmaktadır ve raid diskler yazma işleminin yavaşlatır.

Redo log dosyaları bir döngü içersindedir. Bir gruptaki redo log dolduğunda otomatik olarak diğer gruba

geçer ve işlem bu şekilde devam eder.

Eğer veri tabanı arşiv modda ise bu dolan redo log dosyasının bir kopyası arşiv.log olarak kopyalanır ve

kurtarma amaçlı saklanır.

Veriye yapılan tüm değişiklik işlemlerini tutmakla yükümlüdür.Datafile’lara (bir şekilde) değişen bilgi

yazılamadığı durumlarda redo loglardan bu işlemler görülebilir ve yapılan işlemin kaybı önlenir.

Bu dosyalarında çoğullanma imkanı vardır.Farklı diskler üzerinde 2 ya da daha fazla kopyası tutulabilir.

Bu dosyanın amacı özetle sistem ya da donanım kaynaklı(harddisk göçmesi vs.) olası hatalarda

datafile’lara kalıcı şekilde yazılamayan bilgileri kurtarmaktır.Örneğin bir elektrik kesintisinde henuz

datafile’lara yazılmayan ve memory de bulunan bilgiler kaybedilir.Sistem tekrar ayağa kalktığında Oracle

ilk önce redo log lara bakar.Kalıcı olarak datafile’a yazılamayan bilgi olduğunu görür ve yarım kalan işlemi

sonlandırır.Bu sayede veritabanı elektrik kesintisi olmadan evvelki konuma gelinmiş olur.

Redo log file dolduğu zaman LGWR işlemcisi yeni bir gruba yazdırır.

Redologlar Gruplar ve grupların memberları şeklinde çalışma gösterir.Örneğin 3 adet redo grubumuz

olsun,her birinin 2 şer tane member’ı olsun.Çalışma mantığı olarak oracle bu 3 gruba birden

yazmaz.Birinin işi bittiğinde diğerine geçer,ama bir gruptaki meberların her birine yazılır.

Database yaratılırken verilen maxlogfiles parametresi maximum kaç tane redolog olacağının bilgisini verir.

Bir redolog ne zaman diğerine(Diğer redolog) geçer,

1-)Log Switch geldiğinde,

2-)Checkpoint anında,

3-)Transactionlar için redolog dolduğunda

FAST_START_MTTR_TARGET parametresi ayarlanarak switch süresi saniye süresinden belirlenir.

REDOLOGLARIN ÇOĞALTILMASI

Aşağıdaki sorgu ile database’e yeni bir redolog grubu ekleme imkanı bulmaktayız.

SQL> ALTER DATABASE ADD LOGFILE GROUP 4

(‘D:\oracle\oradata\newdb\REDO04_a.LOG', 'D:\oracle\oradata\newdb\REDO04_b.LOG')

SIZE 100M;

Aşağıdaki Sql de mevcut bir gruba yenibir member ekleme fırsatı bulabilmekteyiz.

SQL> ALTER DATABASE ADD LOGFILE MEMBER

'$HOME/ORADATA/u04/log1c.rdo' TO GROUP 1,

Mevcut bir grubu devre dışı bırakmak istiyorsakta aşağıdaki sorguyu kullanmalıyız.

SQL> ALTER DATABASE DROP LOGFILE GROUP 3;

Bir gruptaki member’ı devre dışı bırakmak istersekte,

SQL> ALTER DATABASE DROP LOGFILE MEMBER

'$HOME/ORADATA/u04/log3c.rdo';

Bir redolog’un içeriğini temizlemek istiyorsak,

SQL> ALTER DATABASE CLEAR LOGFILE

'$HOME/ORADATA/u01/log2a.rdo';

Redologlarda gerçekten sistemimiz için çok öenmlidir.Bu yüzden bunlarıda farklı disklerde tutup güvenliği

sağlamak çok öenmlidir.

En son olarakta redologlar hakkında bilgi toplamak için data dictionary viewlarından yararlanıyoruz.

SQL> select * from v$logfile; Logfiller hakkında bilgi alırız.

SQL> select * from v$log_history; Control filelar üzerinde log fileların bilgilerini alırız.

SQL> select * from v$log; Logfiller hakkında bilgi alırız.

SQL> SELECT group#, sequence#, bytes, members, status

FROM v$log;

GROUP# SEQUENCE# BYTES MEMBERS STATUS

--------- ---------- -------- --------- ---------

1 688 1048576 1 CURRENT

2 689 1048576 1 INACTIVE

2 rows selected.

SQL> SELECT member FROM V$LOGFILE;

MEMBER

-------------------------------------

/u01/home/db03/ORADATA/u03/log02a.rdo

/u01/home/db03/ORADATA/u03/log01a.rdo

ARŞİV REDOLOG FİLES

Database eğer arşiv modundaysa redolog dosyaları düzenli olarak arşivlenir ve arşiv dosyası olarak

saklanır.

Daha sonra geçmişe dönük bir krutama yada data almak istediğimizde bu arşiv dosyaları kullanılmaktadır.

Database’İn arşiv yada noarchive olup olmadığını anlamak için,

SQL > select log_mode from v$database;

LOGMODE

--------------------------------------

ARCHİVELOG

Bir database’i arşiv moduna almak için çeşitli yöntemler vardır.Ama bilinmesi gerekn parametre

LOG_ARCHIVE_START parametresinin TRUE olmasıdır.

Arcn : ARCH görevi aslinda seçimlik bir arka plan görevi olmasina ragmen bir çok sistem için özellikle

tavsiye edilir. Eger bu görev çalistiriliyorsa veritabani ARCHIVELOG kipinde çalisiyor demektir. Bu

seçenek;

tablespace ‘lerin çevrim-içi (on-line) yedeklenmesine

medya failure ‘dan çevrim-içi kurtarmaya ,

günlük kütüklerinin otomatik olarak arsivlenmesine izin verir.

ARCH görevi, günlük kütüklerinin kopyalarini, yerleri daha önce belirlenmis disk ya da teyp birimleri

üzerine çikarir.

SQL> SELECT archiver

FROM v$instance;

ARCHIVE

---------

STOPPED

1 row selected.