Kayıp bir datafile kurtarmak.

Örnek olarak datafile dosyalarımızdan birisini sileceğim. Ve daha önce almış olduğum bir full backuptan restore ederek datafile dosyalarının nasıl kurtarıldığını görebileceğiz.

Database ait tüm datafile görmek için v$datafile dinamik view' den sorgulayabiliriz.

SQL> Select name from v$datafile;

NAME

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

/export/home/oracle/datafile/system01.dbf

/export/home/oracle/datafile/undotbs01.dbf

/export/home/oracle/datafile/sysaux01.dbf

/export/home/oracle/datafile/users01.dbf

/export/home/oracle/datafile/example01.dbf

/export/home/oracle/datafile/deneme01.dbf

Dosyayı siliyorum.

$ rm /export/home/oracle/datafile/deneme01.dbf

Şimdi RMAN’ a bağlanıyorum .

$ rman target /

RMAN> report schema;

Report of database schema

List of Permanent Datafiles

===========================

File Size(MB) Tablespace RB segs Datafile Name

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

1 500 SYSTEM *** /export/home/oracle/datafile/system01.dbf

2 35 UNDOTBS1 *** /export/home/oracle/datafile/undotbs01.dbf

3 250 SYSAUX *** /export/home/oracle/datafile/sysaux01.dbf

4 5 USERS *** /export/home/oracle/datafile/users01.dbf

5 100 EXAMPLE *** /export/home/oracle/datafile/example01.dbf

6 100 DENEME *** /export/home/oracle/datafile/deneme01.dbf

Var olan backupsetten deneme01.dbf dosyasını yüklemek için restore komutunu kullanıyoruz.

RMAN> restore datafile 6;

Starting restore at 09/08/2011

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=154 devtype=DISK

channel ORA_DISK_1: starting datafile backupset restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

restoring datafile 00006 to /export/home/oracle/datafile/deneme01.dbf

channel ORA_DISK_1: reading from backup piece /export/home/oracle/FRA/ORA10GR2/b ackupset/2011_08_09/o1_mf_nnndf_TAG20110809T011841_740r61n9_.bkp

channel ORA_DISK_1: restored backup piece 1

piece handle=/export/home/oracle/FRA/ORA10GR2/backupset/2011_08_09/o1_mf_nnndf_T AG20110809T011841_740r61n9_.bkp tag=TAG20110809T011841

channel ORA_DISK_1: restore complete, elapsed time: 00:00:15

Finished restore at 09/08/2011

Şimdi burada 6 numaralı datafile sadece backup anındaki durumunu kopyalıyoruz. Backup tan sonraki değişikliği ise Recover komutuyla gerçekleştiririz.

Recover komutu ise kullandığımız backup dosyasından sonra yapılan değişiklikleri datafile eşitlemek için kullanılan komuttur. Yani log (archive) dosyalarını yada incremental backupları işletme komutudur.(bende fazla bir değişiklik olmadığından kısa sürdü)

RMAN> recover datafile 6;

Starting recover at 09/08/2011

using channel ORA_DISK_1

starting media recovery

media recovery complete, elapsed time: 00:00:01

Finished recover at 09/08/2011

Böylece artık deneme01.dbf dosyası yerinde ve son commite kadar olan değişikliğini de içermektedir.

System Global Area (SGA) Nedir?

System Global Area denilen veritabanımızın Instance' da yer alan ve içinde shared Pool, large Pool, Database Buffer Cache, Java Pool, Stream Pool ve database ile bu yapılarla arka planda faaliyet gösteren SMON, PMON, CKPT,DBWRn, LGWR gibi back ground proces' lerden oluşan Memory' deki ayrılmış bölgedir.



Database Instance iki bölümden oluşur. Birisi SGA, diğeri ise PGA(program global area). PGA konusuna ayrı bir konu alarak ele alacağımdan şimdilik SGA ile ilgili bilgiler vermek istiyorum. Database Instance'nın Memory'e yüklenmesi Veritabanının çalışmasındaki ilk safhadır.Yani Database ilk açılışında başlangıç parametrelerine göre açılacaktır. Ve bu açılışta bu değerler memory' de instance oluşturacaktır.

Önemli sayacağımız konulardan bir tanesi de SGA' nın yönetimidir. SGA_TARGET initilization parametresine verilen değerle SGA' nin Memory de ne kadar yer allocate(ayrılacağını) edeceğini belirlemiş oluruz. Örneğin SGA_TARGET=2G dersek memory'de 2GB lik bir hafızayı SGA ve bileşenleri için ayırmış olacağız. Diğer bir husus, SGA bileşenleri nasıl yönetilecek? otomatik mi yoksa manuel mi? yani Large Pool yada shared Pool un memorydeki boyutu nasıl olacak. işte buna bizim karar vermemiz gerekiyor.Automatic Shared Memory Management (ASMM) şayet SGA için aktif edilirse SGA_TARGET parametresine bir değer verilir. SGA bileşenleri database çalışma esnasında ihtiyaca göre paylaşımlı olarak bu değeri kullanırlar.Direct I/O işlemleri ve Backup işlemi belleğin Large Pool bileşeninde gerçekleşeceğinden işlemin daha hızlı gerçekleşmesi için daha fazla belleğe ihtiyaç duyacağından diğer bileşenlerde daha az işlem yapılıyorsa o bileşenlerden belleğin bir kısmı alınıp large pool' a o anlık dahil edilir.
SGA_TARGET parametresini 2GB vermişsek ve ASMM enabled ise de SGA bileşenlerini sorguladığımızda şayet bu bileşenler için bir alt değer set etmemişsek, değerleri 0 sıfır görülecektir.
Temel olarak SGA bileşenlerini inceleyecek olursak;
Shared Pool:içerisinde Library cache,Data dictionary cache vardır.
Library Cache, SQL statementlerin Execution planları ve yol haritaları bulunur.Execution planlar, optimizer tarafından toplanan istatistiklere göre oluşturulur. Sorgu sonucunun daha hızlı çalışması için kullanılır.Database performansını ciddi ölçüde etkiler.
Data Dictionary cache ise o anda alınan SQL statement için yetki, rol, erişim izni, hangi indexi kullanacak gibi dataların kontrol edildiği yerdir.
Bu bileşenin bellek miktarını SHARED_POOL_SIZE parametresiyle belli edebiliriz.
Database Buffer Cache: çalışacak SQL statement yada statementler şayet bu bellek bloklarında yok ise datafile de okunarak buraya getirilerek çalıştırılır. İçerisinde SQL statementlerinin çalıştırılma sıklığına göre takip eden bir LRU algoritması vardır. İsteğe görede SQL statementini sakla diyebilirsiniz.DB_BUFFER_CACHE_SIZE parametresiyle bellek alanı verebiliriz yada öğrenebiliriz.
Java Pool : java paketlerini bulundurur. JAVA_POOL_SIZE parametresi ile değer verebiliriz yada öğrenebiliriz.
Large Pool : I/O işlemlerinin , Backup-Recovery işlemlerinin, direct read-write işlemlerinin yapıldığı bileşendir. Örneğin elimizde çok büyük bir datanın güncellenmesi gerekiyor. Ve bu dataya baktığımızda buffer cache deki boş alandan daha fazla bir boyuta sahipse yapılan işlemler buffer cache değil, Large pool da yapılır. yani datafile direkt erişim sağlanır.
LARGE_POOL_SIZE parametresi ile bellek boyutunu öğrenebiliriz. yada belirli bir değer set edebiliriz.
Redo Log buffer cache: database de yapılan tüm değişiklikler redo log bufferda tutulur. örneğin siz bir insert işlemi yaptınız. yapılan değişiklik redolog buffer cache de tutulur. LGWR processini tetikleyen bir olay olduğunda redolog bufferi kalıcı olarak redolog dosyalarına yazılır ve redolog buffercache boşaltılır, yeni değişiklikleri yazmaya tekrar başlar.
Redo loglar database de bir recovery işleminde gerekli olan dosyalardır. Database' deki önemli olmazsa olmaz 3 dosyadan birisidir.
Stream Pool: ise streaming işlemleri için yani lokalde yada lokal dışındaki başka bir yere database replikasyonu esnasında data gönderme/alma işleminde kullanılan bileşendir.

Makaleme başlarken ilk başta database mimarisi ile ilgili temel kavramların tanıtılmasını ve anlaşılmasının iyi olacağını kanaatindeyim.Fazlada ayrıntıya girmeden temel düzeyde bırakmak istedim. Umarım yararlı olmuştur.