Yedek Bilgilerini Görme

Alınan yedekleri data dictionary view’leri ile sorgulayarak öğrenebileceğimiz gibi LIST ve REPORT komutu ile RMAN üzerindede rapolayabiliriz.

1.List Komutu

RMAN ile alınan yedekler özel bir formatta saklanır. RMAN ile oluşturulan dosyaların ismine bakarak, hangi tarihe neye istinâden yedek alındığını bulmak biraz güç olabiliyor. Bunun için aşağıdaki komutları kullanmak uygun olacaktır.

  • Alınan yedeklerin tam olarak içeriğini görmek:
RMAN> LIST BACKUP;
  • Alınan yedeklerin özet bilgisini görmek:
RMAN> LIST BACKUP SUMMARY;
  • Image copy olarak alınan yedekleri aşağıdaki gibi görebiliriz.
RMAN> LIST COPY;
  • Sadece archivelog yedeklerini aşağıdaki gibi görebiliriz.
RMAN> LIST ARCHIVELOG ALL;
  • Belirli bir datafile yedeklerini listeleyebiliriz.
RMAN> LIST BACKUP OF DATAFILE 3;
  • Hangi dosyanın hangi yedek parçası (backup piece) içinde olduğunu görmek:
RMAN> LIST BACKUP OF DATABASE;
  • Bir önceki komutu belirli bir tarih aralığında girerek kullanmak:
RMAN> LIST BACKUP OF DATABASE BETWEEN '01-ARP-2008' AND '28-JUN-2008';
  • Alınan yedeklerin taşıdığı dosyaları görmek:
RMAN> LIST BACKUP BY FILE;

2.Report Komutu

Report komutu belirli kriterler göre rapor bilgisi sunar.Örnegin database’imizdeki bütün datafile’leri aşağıdaki gibi görebiliriz.

RMAN> REPORT SCHEMA;
  • Silinebilir yedekleri aşağıdaki gibi listeliyebiliriz.
RMAN> REPORT OBSOLETE;
  • Retention Policy(yedek alma) kuralımıza göre yedek gerekip gerekmediğini aşağıdaki gibi raporlayabiliriz.
RMAN> REPORT NEED BACKUP;

3.Data Dictionary Görüntüleri

V$RMAN_BACKUP_JOB_DETAILS DBA_RECOVERABLE_SCRIPT_BLOCKS
V$BACKUP DBA_RECOVERABLE_SCRIPT_ERRORS
V$BACKUP_ARCHIVELOG_DETAILS DBA_RECOVERABLE_SCRIPT_PARAMS
V$BACKUP_CONTROLFILE_DETAILS GV_$INSTANCE_RECOVERY
V$BACKUP_COPY_DETAILS GV_$RECOVER_FILE
V$BACKUP_DATAFILE GV_$RECOVERY_FILE_STATUS
V$BACKUP_DATAFILE_DETAILS GV_$RECOVERY_LOG
V$BACKUP_FILES GV_$RECOVERY_PROGRESS
V$BACKUP_PIECE GV_$RECOVERY_STATUS
V$BACKUP_PIECE_DETAILS V_$FLASH_RECOVERY_AREA_USAGE
V$BACKUP_SET V_$INSTANCE_RECOVERY
V$BACKUP_SET_DETAILS V_$RECOVER_FILE
V$RMAN_OUTPUT V_$RECOVERY_FILE_DEST
DBA_HIST_INSTANCE_RECOVERY V_$RECOVERY_FILE_STATUS
DBA_RECOVERABLE_SCRIPT V_$RECOVERY_LOG
V_$RECOVERY_PROGRESS V_$RECOVERY_STATUS

Alınan Yedeklerin Saglamlıgını Kontrol Etme

Aldığınız yedeklerin kontrolünü yapmak akıllıca bir yöntem olacaktır. Yedek aldığınızı düşünüp, aldığınız yedeklerin bozuk olduğu gerçeği ile karşılaşmak bir kriz anında büyük sıkıntılara sebep olacaktır. RMAN bu konuda oldukça güzel bir özellik sunuyor.

Yedekten dönmeden, sadece yedek dosyalarının yapısı incelenerek, yedek dönme işleminin başarılı olup olamayacağı RMAN tarafından bulunabilir.Bunu data file,archivelog dosyaları,control dosyası,spfile ve yedek dosyalarımızı kontrol ederek işlemin başarılı olup olmayacagını söyler.

RMAN> VALIDATE DATABASE;

Sadece control file’lımızın sağlamlığı kontrol etmek için.

RMAN> VALIDATE CURRENT CONTROLFILE;

Archivelog dosyalarımızı kontrol etmek için ;

RMAN> VALIDATE ARCHIVELOG ALL;

Hepsini kontrol etmek için

RMAN> VALIDATE DATABASE INCLUDE CURRENT CONTROLFILE PLUS ARCHIVELOG;

Datafile  varlığını veya bozulmuş blokların olup olmadığını  aşağıdaki gibi öğrenebiliriz.

RMAN> BACKUP VALIDATE DATABASE;

Yedek dosyalarımızı kontrol edebiliriz.

RMAN>RESTORE VALIDATE DATABASE;

Eğer daha farklı bir backupset’i kontrol etmek isterseniz, aşağıdaki gibi etiket (TAG) parametresinden yararlanabilirsiniz:

RMAN> RESTORE DATABASE VALIDATE FROM TAG='CCEBI_YEDEK_2008_06_20';

YEDEKTEN DÖNME İŞLEMLERİ

Bu bölümde almış olduğumuz yedekten dönme işlemine bakacağız. Başlamadan önce bir uyarıda bulunmak gerekiyor: Eğer hangi yedekten dönülmesi gerektiğini belirtmezseniz, son alınan yedek işleme konur.

Veritabanımızı kapatırken (shutdown) database buffer cache’de bulunan bütün dirty bloklar data file’lere yazılır.Ve her datafile’ın header’ı sistemin o anki SCN numarası ile işaretlenr.Aynı zamanda aynı SCN numarası control dosyasında da güncellenir.Veritabanımızı açarken(startup), Oracle data file header’indeki SCN numarası ile control dosyasındaki SCN numarası karşılaştırılır.Eger her şey yolunda ise ve SCN numaraları aynı ise veritabanı problemsiz açılır.Aynı değilse hata verir.Bu durumlarda kurtarma(recovery yapmamız gerekmektedir)

a.Data Recovery Advisor(Veri Kurtarma Danışmanı)

Oracle 11g ile gelen bu araç veri kurtarma konusunda bizim işimizi çok kolaylaştımıştır.Bu aracın 3 modu vardır;bozulmaları listeleme,düzeltmek için öneri sunma ve düzeltmek için gerekli komutu çalıştırma.Örnegin;

rman target /

Aşağıdaki komut ile bozulmaları görebiliriz

RMAN>list failure;

İstersek Failure ID numarası ile belirtilen bozulmanın detayını ögrenebiliriz.

RMAN>list failure 142 detail;

Şimdi ne yapacağımız konusundan RMAN’den danışmanlık hizmeti alalım.

RMAN>advise failure;

Bize bir öneride bulundu.Çıktının en sonunda önerdigi scripti bulabiliriz.İşletim sistemi üzerinden bu scriptin içerigine bakabiliriz.

cat /u01/app/oracle/diag/rdbms/db11g/DB11G/hm/reco_62454.hm;

Bu scriptin içerigini RMAN üzerinden de aşagıdaki gibi görebiliriz.

RMAN>repair failure preview;

Ve artık RMAN’a bu scripti gerçekleştirerek kurtarmasını söyleyebiliriz.

RMAN>repair failure;

b. Complete Recovery(Tamamlı Kurtarma)

Complete recovery veritabanımızın veya datafile’mızın bozulma öncesi son commit edilen işleme kadar bütün işlemlerin kurtarılmasıdır.Complete recovery yapabilmemiz için aşağıdaki şartlar sağlanmalıdır.

  • Veritabanımız ARCHIVELOG modunda olmalıdır.
  • Veritabanımızın tam yedeği alınmalıdır.
  • Son tam-yedekten sonra alınmış artan yedeklerimiz olabilir.Ama mutlaka level 0 veya level 1 yedekten sonra üretilen Arşiv log dosyalarımız olmalıdır.
  • Online redo log dosyalarımız ulaşılabilir durumda olmalıdır.

Veritabanımızda complete recovery operasyonu gerçekleştirebilmek için gerekli olan bütün yedek dosyaları aşağıdaki komutla öğrenebiliriz.

RMAN> RESTORE DATABASE PREVIEW;
RMAN> RESTORE DATABASE PREVIEW SUMMARY;

Veritabanımızda complete  recovery gerçekleştirebilmek için alınan yedeği aşağıdaki gibi doğrulayabiliriz.

RMAN> RESTORE DATABASE VALIDATE HEADER;

b.1.Tüm Veritabanının Kurtarılması

Tüm veritabanını kaybettiğimizde kullanmamız gereken yöntem.

b.1.1.Control Dosyamız Varsa

Veritabanımız MOUNT modda açılır.

RMAN> SHUTDOWN ABORT;
RMAN> STARTUP MOUNT;
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN;

Dikkat edilmesi gereken bu komutları çalıştırdığınız takdirde, alınan son yedeğe göre recover edileceğidir.FROM TAG parametresini ekleyip, başka yedeklerin kullanılmasını da sağlayabilirsiniz.

v.1.2.Control Dosyamızı da Kaybetmişsek

Veritabanımız NOMOUNT modda açılır.

RMAN> SHUTDOWN ABORT;
RMAN> STARTUP NOMOUNT;
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;
RMAN> ALTER DATABASE MOUNT;
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN;

b.2.Tablespace ve Data File Kurtarma

Her zaman full recover gerekmez. Bazı durumlarda, datafile ya da tablespace bozulur. Bu disk üzerindeki fiziksel bir hasardan gerçekleşebilir ya da dikkatsiz bir kullanıcıs datafile’a zarar verebilir.

Bu gibi durumlarda database’i kapatmadan, ya da mount mode’a çekmeden ilgili tablespace veya datafile’ları recover edebilirsiniz. İşlemi gerçekleştirmek için dikkat edilmesi gereken en önemli konu, ilgili datafile ya da tablespace’lerin offline mode’da olmasıdır. Dilerseniz, database’i tamamen kapatıp, mount mode’a alıp, bu işlemleri yine gerçekleştirebilirsiniz. Ancak buna gerek yok. SYSTEM Tablespa e’i hariç, bütün tablespace’ler offline mode’a çekilerek işlem yapılabilir.

Örnek 1-Tablespace Kurtarma :

Kurtarılacak tablespace kullanım dışı bırakılır

RMAN> sql ‘alter tablespace users offline immediate’;

Tablespace yedekten geri dönülür

RMAN> RESTORE TABLESPACE USERS;

Kurtarma işlemi gerçekleştirilir

RMAN> RECOVER TABLESPACE USERS;

Tablespace tekrar kullanıma alınır

RMAN> sql ‘alter tablespace users online’;

Örnek 2-Tablespace Kurtarma :

RMAN> SHUTDOWN IMMEDIATE;
RMAN> STARTUP MOUNT;
RMAN> RESTORE TABLESPACE USERS;
RMAN> RECOVER TABLESPACE USERS;
RMAN> ALTER DATABASE OPEN;

NOT : Temporary tablespace’in yedeği alınmadığı için recovery yapılmaz.Oracle 10g ile birlikte veritabanı açılırken temporary tablespace’i kontrol eder ve yoksa otomatik olarak oluşturur.

Örnek 3-Datafile Kurtarma :

Kurtarılacak datafile kullanım dışı bırakılır

RMAN> sql ‘alter database datafile 2 offline’;

Data file yedekten geri dönülür

RMAN> RESTORE DATAFILE 2;

Kurtarma işlemi gerçekleştirilir

RMAN> RECOVER DATAFILE 2;

Tablespace tekrar kullanıma alınır

RMAN> sql ‘alter database datafile 2 online’;

Örnek 4- Datafile Kurtarma :

RMAN> SHUTDOWN IMMEDIATE;
RMAN> STARTUP MOUNT;
RMAN> RESTORE DATAFILE ‘/u01/app/oracle/oradata/ORCL/users01.dbf’;
RMAN> RECOVER DATAFILE ‘/u01/app/oracle/oradata/ORCL/users01.dbf’;
RMAN> ALTER DATABASE OPEN;

b.3.Arşiv Dosyalarını Yedekten Dönme

Benzer şekilde arşiv dosyalarının recover işlemi söz konusu ise birçok seçenek göz önüne getirilebilir.

SCN – System Change Number’a belirli aralıktaki arşiv dosyalarını dönme:

RMAN> RESTORE ARCHIVELOG SCN BETWEEN 26716797844 and 26716798848;

Yedeklenmiş bütün arşiv dosyalarını dönme:

RMAN> RESTORE ARCHIVELOG ALL;

30 günden yeni 7 günden eski arşiv dosyalarının yedeğini dönme:

RMAN> RESTORE ARCHIVELOG FROM TIME 'SYSDATE-30' UNTIL TIME 'SYSDATE-7';

b.4.CONTROL FILE’i Yedekten Dönme

RMAN üzerinden control file’in yedeğini almışsanız aşağıdaki gibi control file’i restore edebilirsiniz. Tabii bunun için database’in nomount mode’da açılmış olması gerekir:

RMAN> STARTUP NOMOUNT;
RMAN> RESTORE CONTROLFILE FROM '/data2/cf_1SF32433.rman';
RMAN> ALTER DATABASE MOUNT;

c.Incomplete Recovery(Tamamsız Kurtarma)

Complete recovery’in tersine son COMMIT edilmiş yere kadar kurtarma işlemi yapılmaz geçmişteki bir zamana dönülür.

c.1.Time-Based Recovery(Zaman Tabanlı Kurtarma)

Belirtilen zamana kadar commit edilmiş tüm veriler kurtarılır.

RMAN> STARTUP MOUNT;
RMAN> RESTORE DATABASE UNTIL TIME "TO_DATE('2013-03-19 16:45','YYYY-MM-DD HH24:MI')";
RMAN> RECOVER DATABASE UNTIL TIME "TO_DATE('2013-03-19 16:45','YYYY-MM-DD HH24:MI')";
RMAN> ALTER DATABASE OPEN RESETLOGS;

Until Time’i kullanırken aşağıdaki durumlara dikkat etmeniz gerekiyor:

1. Until Time ile veritabanını döndüreceğiniz zaman, yedek tarihinden sonra olmalı. Örneğin 16.30’da yedeği aldıysanız, 15.30’a dönemezsiniz. Mutlaka 16.30’dan sonraki bir zaman belirtilmeli.

2. Until Time ile dönüş yapabilmek için arşiv dosyalarının mevcut olması gerekmektedir. Until Time ile recover yapacaksanız, önce arşiv dosyalarının olduğundan ve doğru konumda bulunduğundan emin olun.

c.2.SN-Based Recovery(SCN Tabanlı Kurtarma)

Veritabanımızı kurtarmak istediğimiz zamanının SCN numarasını biliyorsak UNTIL SCN numarasını kullanarak geçmiş bir ana dönebiliriz.

RMAN> STARTUP MOUNT;
RMAN> RESTORE DATABASE UNTIL SCN 2555685;
RMAN> RECOVER DATABASE UNTIL SCN 2555685;
RMAN> ALTER DATABASE OPEN RESETLOGS;

c.3.Sequence-Based Recovery

UNTIL SEQUENCE kullanarak istediğimiz sıradaki Archivelog dosyasına kadar recovery yapabiliriz.

RMAN> STARTUP MOUNT;
RMAN> RESTORE DATABASE UNTIL SEQUENCE 58;
RMAN> RECOVER DATABASE UNTIL SEQUENCE 58;
RMAN> ALTER DATABASE OPEN RESETLOGS;

c.4. Restore Point Recovery(Geri Yükleme Noktası ile Kurtarma)

Flashback Database özelliği aktif ise restore point(geri yükleme noktası) oluşturabiliriz.Aşagıdaki gibi SQL*Plus üzerindede oluşturabiliriz.

SQL> CREATE RESTORE POINT after_dbca;

Oluşturdugumuz geri yükleme noktasına aşağıdaki gibi dönebiliriz.(Varolan geri yükleme noktalarını V$RESTORE_POINT ile görebiliriz)

RMAN> STARTUP MOUNT;
RMAN> RESTORE DATABASE UNTIL RESTORE POINT after_dbca;
RMAN> RECOVER DATABASE UNTIL RESTORE POINT after_dbca;
RMAN> ALTER DATABASE OPEN RESETLOGS;

Yararlı olması Dilegiyle …
Yazar : Mustafa Bektaş Tepe
Oracle World

Kaynaklar ; 
www.taliphakanozturk.wordpress.com(Oracle Database 11g R2 İleri Veritabanı Yönetimi)
www.cagataycebi.com
www.uguroracle.blogspot.com
Robert Freeman ve Matthew Hart ”Oracle RMAN 11g Backup and Recovery”

RMAN 1
RMAN 2
RMAN 3

Loading