Oracle Database 11g – Data Recovery Advisor (DRA)

 

Oracle veritabanının 11g versiyonu ile aramıza katılan bir danışman olan “Data Recovery Advisor”dan biraz bahsetmek istiyorum. Her ne kadar 10g ile aramıza katılan “Flashback” teknolojisi kadar etkili olmasa da ciddi kullanım kolaylığı bulunmaktadır. Aslında adından da anlaşılacağı gibi bu eklentiye ben danışman diyorum ve ama verinin kaybını önlemek ve yedekleme operasyona ait objeleri kontrol ederek, size çözümler listelemek, tavsiyelerde bulunmak ve bu tavsiyeleri gelen istek üzerine uygulamak. Sorabilirsiniz, bu gerçekten müthiş bir özellik ancak Oracle 11g’den sonra piyasaya süreceği DRA için çok daha iyi özellikler geliştiriyor. Şu anda DRA, RAC ortamlarda ve fiziksel bekleme veritabanı (physical standby database) için kullanılamıyor. Ben kullanabildiğimiz taraflarından ve tam olarak aslında ne olduğundan bahsetmek istiyorum.

Data Recovery Advisor

DRA, veritabanındaki kararlı ve sürekli olan veri dosyası ve veri başarısızlıklarını tanımlamada, bu tanımlamalar için düzeltme tavsiyelerinde bulunmada ve en önemlisi bu tavsiyeleri çalıştırmada kullanılan bir Oracle aracıdır. Aramıza 11g versiyonu ile katılmıştır ve 10g ve öncesi versiyonlarda bulunmamaktadır. Amacı veritabanı yöneticisinin işlerini hafifletmek, hatayı çok daha hızlı tespit etmek ve gidermek ve aynı zamanda güvenilir bir şekilde veritabanını yeniden servise açabilmek.

Veritabanının bir başka arayüzü bulunmaktadır ve adına “Health Monitor” denmektedir. Sağlık izlemesinin yapılabilmesi için bir de “checker” bulunmaktadır ve amacı HM’e veritabanı ve veritabanı bileşenleri ile ilgili verileri sağlamaktır. Bu yapıya “Data Integrity Check” yani veri sağlamlık kontrolü denmektedir ve reaktif veya proaktif olarak çalıştırılabilen bir operasyondur. DIC aşamasında sınıfta kalan objeler raporlanır ve veritabanı yöneticisinin ilgisine sunulur. Veritabanı için ölümcül olan durumlar “Critical” başlığı altında toplanır ve SYSTEM ve UNDO tablespace’ine ait datafile’ların uçması veya bozulması durumunda gösterilir. Hatırlayınız, SYSTEM veya UNDO tablespace’ine ait bir datafile yok olmuşsa bu ciddi bir durumdur ve ilgili datafile restore edilmeden veritabanını açamazsınız.

Enterprise Manager’daki DRA ekranı;

DRA ile Çalışmak

Öncelikle “başarız” ve “hatalı” gibi tanımların ne olduğunu ifade etmekte fayda var. Başarısız veya hatalı bir Oracle veritabanı datafile’ı, Oracle tarafından erişilemeyen, okunamayan veya yazılamayan veritabanı objesidir. Bu durumda olan datafile’lar “checker”ın oltasına takılır ve bize raporlanır. Eğer bir hata algılanırsa bu veritabanının ilgili yeri olan “Automatic Diagnostic Repository” içerisinde biriktirilir ve saklanır. DRA ise ADR’den aldığı bilgiler ışında bir rapor hazırlar. Bir hata, “Critical, High, Low” olarak sınıflandırılır.

DRA’nın sunduğu tamir operasyonları arasında;

1) Blok tamiri
2) Datafile tamiri
3) Flashback Database operasyonu

DRA’ya bu operasyonların script’lerini ürettirebilir ve kendiniz elle de ilgili tamir script’lerini koşabilirsiniz. Bunu yapmak istemezseniz DRA’ya da tavsiye ettiği tamir operasyonunu otomatik olarak yaptırabilirsiniz. DRA bu operasyonun sonunda size veritabanının açmak isteyip istemediğinizi soracaktır (open modu).

Oracle’ın Tavsiye Ettiği Kurtarma Stratejilerini Uygulamak

1) Enterprise Manager ekranında “Availability” alanına gidiyoruz.

2) “Manage” kısmında yer alan “Perform Recovery” tuşuna tıklıyoruz.

Karşımıza Perform Recovery ekranı geliyor ve burada iki adet alt bölüm bulunuyor. “Oracle Advised Recovery” veya “User Directed Recovery”.

3) Ekran görüntüsünden de anlaşılacağı üzere 1 tane “high” sınıfında problemimiz bulunuyor. “Advise and Recover” tuşuna tıklayarak devam etmeden önce aklımızda bulundurmamız gereken konu, 1 adet datafile’ın şu anda kapalı (offline) olduğu ve erişiminin bulunmadığı.

4) “Advise and Recover” tuşuna tıklayarak devam ediyoruz.

5) Öncelik sırası listesinde “ALL” seçimini yapıyoruz ve “GO” diyoruz. Bunu yaptığınız zaman DRA size bütün başarısızlıkları gösterecektir.

6) “Data Failures” kısmına gidiyoruz. Hatayı buluyoruz ve seçiyoruz, ardından da “Advise” diyoruz.

Karşımıza “Recovery Advisor” sayfası geliyor ve hatanın düzeltilmesi için bize bir RMAN script’i gösteriyor. Bu script’i inceledikten sonra devam ediyoruz (bazen eski oyun ve yazılımları kurmak gibi gelebilir, hani derler ya “hocam sadece next next next diyorsun, tamam. Evet aslında biraz öyle

7) “Continue” yani devam diyoruz ve aşağıdaki ekrandayız;

Ekran görüntüsünde bir datafile blok kurtarma işlemi yapılacağını görebilirsiniz. Artık script sizde olduğuna göre dilerseniz RMAN’e gidip, gerekli işlemi yapabilirsiniz. Bu arada bunları yazarken aklıma geldi. “Media Recovery” yapabilmek için veritabanınız archivelog modda olmalıdır. Aksi halde bu işlemleri unutabilirsiniz ve bir önceki yedeğe dönerek, bütün veritabanının datafile’larını yeniden yüklemeye hazır olabilirsiniz.

8) “Submit Recovery Job” tuşuna tıklıyoruz ve bekleyip neler olduğunu görüyoruz. Ardından neyin, ne zaman ve nasıl çalıştırılması gerektiği ile ilgili bir bilgi ekranı geliyor.

9) “View Results” tuşuna tıklayarak neler olduğunu ve Oracle’ın bizim için hangi işlemi yaptığını görebiliyoruz.

RMAN Komut Satırı ile Data Recovery Advisor

Recovery Manager aracılığı ile DRA kullanmak istiyorsanız kullanabileceğiniz komutlar aşağıdadır;

LIST FAILURE
ADVISE FAILURE
REPAIR FAILURE
CHANGE FAILURE

Hemen bir not eklemek istiyorum. LIST ve ADVISE komutlarını çalıştırmadan, kurnazlık yapıp REPAIR FAILURE komutunu göndermeye çalışırsanız hatayı alırsınız. Görmediğiniz bir şeyi tamir etmesi de zor olacaktır. Bu sebepten dolayı sırasıyla gitmek zorundasınız. (LIST –> ADVISE –> REPAIR).

Hatanın Sınıflandırılması, Önceliği ve Gruplandırılması

Hata, yani “failure” ile ilgili biraz yukarıda bahsetmiştim. Daha da detaylı açıklamak isterim. Her hatanın bir sınıfı vardır ve bu sınıf “Open” veya “Closed” olarak tanımlanmaktadır. OPEN konumundayken hata açıktır ve ilgi beklemektedir. CLOSED olduğu zaman tamir uygulanmıştır ve işler yoluna girmiştir. Her LIST FAILURE komutu ile birlikte DRA bütün OPEN durumunda olan hatalı yeniden doğrular ve eğer hala açık ise OPEN olarak bırakır veya CLOSED yani kapalı konumuna getirir. Bunu denemenin en iyi yolu OPEN statüsü değişmeyen bir hatayı düzelttikten sonra yeniden LIST FAILURE komutu göndermek ve sonraki durumunu incelemektir. Alınacak aksiyonu eğer elle çalıştırma yöntemi ile yerine getirdiyseniz CHANGE FAILURE komutu ile OPEN durumda olan bir hatayı CLOSED durumuna geçirebilirsiniz. Bu şekilde RMAN, DRA ve Oracle ne yaptığınızdan haberdar olur (elle silinmiş archivelog’ların crosscheck komutu ile yeniden doğrulatılması gibi).

Hatanın önceliği ile ilgili olarak ise 3 adet opsiyon bulunmaktadır. Bunlar; CRITICAL, HIGH ve LOW. DRA yalnızca kritik ve yüksek önceliğe sahip hatalar için tavsiyelerde bulunmaktadır. Critical olarak adlandırılmış hatalar ciddi hatalardır demiştik ve acil önlem alınması gerekir zira bütün veritabanını etkilemektedir. High öncelik olarak görmediğiniz ve veritabanınızın kapanmasına veya tamamen çalışmamasına neden olan bir problemin önceliğini LOW yaparak DRA’nın kafasının daha fazla karışmasını engelleyebilirsiniz. Dolayısıyla LIST FAILURE komutu da yalnızca CRITICAL ve HIGH önceliğe sahip hataları gösterecektir. LOW konumuna çektiğiniz hata eğer hala düzelmemiş ise LIST FAILURE komutu bu durumu OPEN olarak değerlendirmeye de devam edecektir.

DRA varsayılan ve otomatik olarak bir gruplama yaparak listeleme gerçekleştirmektedir. Örneğin birden fazla blok hatası bulunan bir durumda LIST FAILURE çıktısı büyümeyecek ve bütün alakalı hataları gruplayarak gösterecektir. Oracle burada LIST FAILURE çıktısının kısıtlanması üzerinde çalışmıştır. Bunun nedenini şöyle düşünebilirsiniz; 112′ye yapılan aramaların çok ciddi bir oranı (yanılmıyorsam %40 kadar) yanlış, eksik veya keyfi aramalardan oluşmaktaymış. Bu da geri kalan yüzdenin düzeyli hizmet almasını ve gerçekten acil olan durumun gözden kaçırılmasına neden olabilmektedir. Bu durumu DRA için de düşünebilirsiniz dersem yanlış bir ifadede bulunmuş olmam. LIST FAILURE bizim için altın değerindedir çünkü bize nerede, ne hatanın olduğunu göstermektedir. Bunun da bir öncelik sırası ve ilgi önceliği olması gerekmektedir.

RMAN> LIST FAILURE;

List of Database Failures
=========================

Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
142 HIGH OPEN 22-JAN-11 One or more non-system datafiles
are missing
101 HIGH OPEN 22-JAN-11 Datafile 25: ‘/disk1/oradata/prod/example01.dbf’ contains one or more corrupt blocks

CHANGE FAILURE komutu ile sınıfını değiştiriyoruz.

RMAN> CHANGE FAILURE 101 PRIORITY LOW;

List of Database Failures
=========================

Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
101 HIGH OPEN 22-JAN-11 Datafile 25: ‘/disk1/oradata/prod/example01.dbf’ contains one or more corrupt blocks

Do you really want to change the above failures (enter YES or NO)? YES
changed 1 failures to LOW priority

Değişikliği görebilmek için yeniden LIST komutunu gönderiyoruz;

RMAN> LIST FAILURE ALL;

List of Database Failures
=========================

Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
142 HIGH OPEN 22-JAN-11 One or more non-system datafiles
are missing
101 LOW OPEN 22-JAN-11 Datafile 25: ‘/disk1/oradata/prod/example01.dbf’ contains one or more corrupt blocks

Manuel Aksiyonlar ve Otomatik Tamir Opsiyonları

ADVISE FAILURE komutu bize hem elle yapılabilecek veya otomatik olarak RMAN’e devredilecek opsiyonları listelemektedir. ADVISE FAILURE komutunu çalıştırabilmek için önce LIST FAILURE komutunu çalıştırmamız gerekmektedir. Bir önemli hatırlatma, eğer LIST FAILURE komutunu çalıştırdığınız zaman ile ADVISE FAILURE komutunu çalıştırdığınız zaman aralığı arasında yeni bir hata oluşmuş ise, LIST FAILURE komutundan sonra çalıştırdığınız ADVISE FAILURE komutu hata verecektir. Buna dikkat ediniz.

DRA’nın bütün kontrol dosyalarını kaybettiğimiz durumlarda da müdahale etme şansı vardır ancak elle yapılması gereken durumu iletmektedir. Bir örnek olarak CREATE CONTROLFILE ifadesi gibi. Bunun tavsiyesini verir ama uygulamaz yani REPAIR FAILURE ile kontrol dosyası yarattıramazsınız.

DRA’nın bunları yaparken elinde mutlaka bir yedek ve eğer media recovery yapılacaksa da gerekli archivelog’ların bulunması gerekir. DRA bir hatayı tamir etmeden önce hangi yedeği ve hangi archivelog’ları kullanacağını bilecektir. Biz bu dosyaları DRA’ya sağlayamıyorsak ne yazık ki herhangi bir kurtarma veya tamir operasyonu yerine getirilemez. Sonuçta DRA’nın yaptıkları sihirli değil, yalnızca veritabanı yöneticisinin zaten yapacağı işlerde çıraklık yapmak. Usta yine veritabanı yöneticisi.

Konsolide Hata Tamirleri

Mümkün olan durumlarda DRA bize birden fazla aşamadan oluşan bir kurtarma ve tamir opsiyon listesi sunabilir. Buna konsolide tamir listesi denir. Kimi zaman bu çok geçerli olmayabilir çünkü aradaki bir aşama sınıfta kalırsa, diğer aşamalarda etkilenir (herhangi bir yedeğin yerinde bulunamaması gibi). Örnek tamir script’i aşağıdadır;

# restore and recover datafile
sql ‘alter database datafile 22 offline’;
restore datafile 22;
recover datafile 22;
sql ‘alter database datafile 22 online’;

Yukarıdaki script’in DRA tarafından çalıştırılmasını istiyorsanız REPAIR FAILURE koşmalısınız veya kopyalayıp siz de yapabilirsiniz. CHANGE FAILURE komutunu koşmayı unutmayınız!

Yukarıdaki script’in ne yapmak istediğini açıklamak istiyorum. İlk önce bu operasyonun veritabanının durumu ile bir ilgili bulunmuyor. Yani herhangi bir açma veya kapatma işlemi yapmıyoruz, direkt olarak yedeği ve archivelog’ları kullanarak datafile’ı kendine getiriyoruz. İlk önce ilgili datafile’ı (22 numaralı) kapalı konumuna getiriyoruz ve olası erişimleri engelliyoruz. Ardından “restore” yani yedekten datafile’ı çıkartma operasyonunu yerine getiriyoruz. Yedekten çıkan datafile’ın blok başlığında kayıtlı SCN ile kontrol dosyasındaki SCN uyumlu olmadığı için “recover” komutunu göndererek archivelog’lardan bu datafile için neler olduğu bilgisini rica ediyoruz. Media recovery de tamamlandıktan sonra artık 22 numaralı datafile açılmaya ve yeniden erişilip kullanılmaya hazır konumuna taşındı.

Desteklenen Veritabanı Konfigürasyonları

Daha önce de bahsettiğim gibi DRA yalnızca tek instance üzerinde çalışmaktadır ve RAC desteklenmemektedir.

Data Guard ortamlarında ise DRA aşağıdaki operasyonları yerine getiremez;

a) Fiziksek yedek veritabanından transfer edilen datafile’ların ana veritabanındaki hataları gidermek için kullanılması.
b) Fiziksel yedek veritabanındaki hataları teşhis etme ve tamir etme operasyonları.

Ancak, ana veritabanı ruhunu teslim etmiş ise DRA fiziksel bekleme veritabanına “failover” operasyonunu gerçekleştirmek için tavsiyede bulunabilir. Failover gerçekleştikten sonra DRA ile çökmüş ana veritabanını yeniden düzenleyebilirsiniz. “Failover”dan kastetmek istediğimiz ana veritabanı yerine fiziksel yedeğin kullanılması durumudur.

Hataların Listelenmesi

RMAN> LIST FAILURE;

List of Database Failures
=========================

Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
142 HIGH OPEN 22-JAN-11 One or more non-system datafiles are missing
101 HIGH OPEN 22-JAN-11 Datafile 1: ‘/disk1/oradata/prod/system01.dbf’ contains one or more corrupt blocks
DETAIL komutunu da kullanabiliyoruz;
RMAN> LIST FAILURE 101 DETAIL;

List of Database Failures
=========================

Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
101 HIGH OPEN 22-JAN-11 Datafile 1: ‘/disk1/oradata/prod/system01.dbf’ contains one or more corrupt blocks
List of child failures for parent failure ID 101
Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
104 HIGH OPEN 22-JAN-11 Block 56416 in datafile 1: ‘/disk1/oradata/prod/system01.dbf’ is media corrupt
Impact: Object BLKTEST owned by SYS might be unavailable

Bir diğer LIST FAILURE komutları ise;

LIST FAILURE LOW;
LIST FAILURE CLOSED;
LIST FAILURE EXCLUDE FAILURE 142;

Tamir Opsiyonuna Karar Verilmesi

Recover Manager’a bağlanıp, LIST FAILURE komutunu gönderdikten sonra ADVISE FAILURE komutu ile tamir opsiyonlarını görebilir ve bir karar verebiliriz;

RMAN> ADVISE FAILURE;

List of Database Failures
=========================

Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
142 HIGH OPEN 22-JAN-11 One or more non-system datafiles
are missing
101 HIGH OPEN 22-JAN-11 Datafile 1: ‘/disk1/oradata/prod/system01.dbf’ contains one or more corrupt blocks

analyzing automatic repair options; this may take some time
using channel ORA_DISK_1
analyzing automatic repair options complete

Mandatory Manual Actions
========================
no manual actions available

Optional Manual Actions
=======================
1. If file /disk1/oradata/prod/users01.dbf was unintentionally renamed or moved, restore it

Automated Repair Options
========================
Option Repair Description
—— ——————
1 Restore and recover datafile 22; Perform block media recovery of
block 56416 in file 1
Strategy: The repair includes complete media recovery with no data loss
Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_660500184.hm

Alt raporlarını incelemek istersek;

RMAN> ADVISE FAILURE 101;

List of Database Failures
=========================

Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
101 HIGH OPEN 22-JAN-11 Datafile 1: ‘/disk1/oradata/prod/system01.dbf’ contains one or more corrupt blocks

analyzing automatic repair options; this may take some time
using channel ORA_DISK_1
analyzing automatic repair options complete

Mandatory Manual Actions
========================
no manual actions available

Optional Manual Actions
=======================
no manual actions available

Automated Repair Options
========================
Option Repair Description
—— ——————
1 Perform block media recovery of block 56416 in file 1
Strategy: The repair includes complete media recovery with no data loss
Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_708819503.hm

Hataların Tamir Edilmesi

Recovery Manager’a bağlandıkta sonra LIST ve ADVISE komutlarını çalıştırdık ve karşımıza çıkan sonuçları gördük. Şimdi ise bu hataların tamir edilmesi aşamasındayız.

RMAN> REPAIR FAILURE;

Strategy: The repair includes complete media recovery with no data loss
Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_475549922.hm
contents of repair script:
# restore and recover datafile
sql ‘alter database datafile 22 offline’;
restore datafile 22;
recover datafile 22;
sql ‘alter database datafile 22 online’;
# block media recovery
recover datafile 1 block 56416;

Do you really want to execute the above repair (enter YES or NO)? YES
executing repair script

sql statement: alter database datafile 22 offline

Starting restore at 22-JAN-11
using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00022 to /disk1/oradata/prod/users01.dbf
channel ORA_DISK_1: reading from backup piece /disk2/PROD/backupset/2011_01_22/o1_mf_nnndf_TAG20110122_32fjzd3z_.bkp
channel ORA_DISK_1: piece handle=/disk2/PROD/backupset/2011_01_22/o1_mf_nnndf_TAG20110122_32fjzd3z_.bkp tag=TAG20110122
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
Finished restore at 22-JAN-11

Starting recover at 22-JAN-11
using channel ORA_DISK_1

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

Finished recover at 22-JAN-11

sql statement: alter database datafile 22 online

Starting recover at 22-JAN-11
using channel ORA_DISK_1
searching flashback logs for block images until SCN 429690
finished flashback log search, restored 1 blocks

starting media recovery
media recovery complete, elapsed time: 00:00:03

Finished recover at 22-JAN-11
repair failure complete

Data Recovery Advisor’ın 11g ile aramıza katılmış olması belki 11g tercih etmenin bir nedeni olmayabilir fakat bir veritabanı yöneticisinin işlerini gerçekten kolaylaştırdığı bir gerçek. Hatanın ya da hataların nerede olduğunu çok hızlı bir şekilde anlamak ve aksiyon alabilmek için bir sağ kol gibi düşünebilirsiniz.

Yorum Yapabilmek İçin Üye Girişi Yapmanız Gerekmektedir.

oracle database 11g data recovery advisor dra