Anasayfa > Data Guard, RMAN Backup and Recovery > Primary/Standby Log GAP Oluştuğunda ve Primary Üzerinde Arşivler Silinmişse Ne Yapılmalı?

Primary/Standby Log GAP Oluştuğunda ve Primary Üzerinde Arşivler Silinmişse Ne Yapılmalı?

Merhaba Arkadaşlar,

Primary/Standby arasında log aralığı (GAP) oluştuğunda ve Primary veritabanı üzerinde arşiv log dosyalarının bir bölümünü yanlışlıkla sildiğimiz bir durumda ne yapmamız gerektiğini yazacağım. Elimizde silinen arşiv dosyalarının yedeğinin olmadığını düşünelim. Normalde biz dba ler böyle bir duruma müsaade etmemeliyiz ama böyle bir durum başımıza gelebilir. Bu durumda yapmamız gereken primary ve standby veritabanlarının şu anki SCN numaralarını öğrenmektir. Hadi adım adım birlikte yapalım.

1- Primary üzerinde aşağıdaki sorgu ile o anki SCN numarasını öğrenelim.

SQL> select current_scn from v$database;

CURRENT_SCN

———–

1289504966

2- Standby üzerinde aşağıdaki sorgu ile o anki SCN numarasını öğrenelim.

SQL> select current_scn from v$database;

CURRENT_SCN

———–

1289359962

scn_to_timestamp(SCN_NUMBER) fonksiyonunu kullanarak Primary/Standby arasında ne kadarlık bir zaman farkı olduğunuda öğrenebilmekteyiz.

3- Standby veritabanında apply işlemi durdurulur.

SQL> alter database recover managed standby database cancel;

4– Standby veritabanı kapatılır.

SQL> shutdown immediate;

5- Primary veritabanı üzerinde standby veritabanının son SCN numarasından itibaren incremental yedek alalım. Ve aldığımız yedeği standby sunucusuna kopyalayalım.

RMAN> backup incremental from scn 1289359962 database;

# scp /backup_ISTANBUL/dun52q66_1_1 oracle@192.168.2.3:/oracle/ora11g

6- Primary veritabanında yeni bir standby control dosyası oluşturalım. Ve bu dosyası standby veritabanımızın bulunduğu sunucuya kopyalayalım.

SQL> alter database create standby controlfile as ‘/oracle/ora11g/standby.ctl’;

# scp /oracle/ora11g/standby.ctl oracle@192.168.2.3:/oracle/ora11g

7- Standby veritabanımızı NOMOUNT durumunda açıp, control dosyalarımızın yerini öğrenelim.

SQL> startup nomount

SQL> show parameter control_files

8- Control dosyalarını primary sunucudan kopyaladığımız standby control dosyası ile ezelim.

# cp /oracle/ora11g/standby.ctl /oracle/ora11g/ISTANBUL/data1/control01.ctl

# cp /oracle/ora11g/standby.ctl /oracle/ora11g/ISTANBUL/data2/control02.ctl

9- Standby veritabanımızı MOUNT durumuna getirelim.

SQL> alter database mount standby database;

10- Standby sunucuda RMAN ‘e bağlanalım. Ve primary üzerinden aldığımız incremental yedeği catalog komutuyla RMAN ‘e register edelim.

# rman target /

RMAN> catalog start with ‘/oracle/ora11g’;

Emin olup olmadığımzı soracaktır. Yes diyerek devam edebiliriz.

11- Artık standby veritabanımızı kurtarabiliriz. Incremental yedek olduğu için recover işlemini başlatalım.

RMAN> recover database;

Incremental yedek recover işlemi tamamlandığında veritabanı bir sonraki arşiv dosyasını arayacaktır. Ve kurtarma işlemi gerekli arşiv dosyasını bulamadığını belirten ORA-00334 hatası ile sonlanır. Bu durumda endişeye kapılmamıza gerek yoktur. ORA-00334  hatası ile belirtilen arşiv primary veritabanında biz incremental yedek aldıktan sonra oluşturulan veya oluşacak olan arşiv dosyasıdır. Artık standby veritabanımızda RMAN den çıkıp apply işlemini başlatabiliriz.

SQL> alter database recover managed standby database disconnect from session;

Primary/Standby arasındaki log aralığını RMAN incremental yedek ile çok rahat çözebildik. Böyle bir durum ile karşılaştığımızda Standby veritabanının yeniden kurulumu en son düşüneceğimiz bir iş olmalı. Çünkü zaman bizim için çok değerli.

Talip Hakan Öztürk

  1. Gokhan Karagozlu
    16/04/2012, 6:14 am

    Cok faydalı bir yazı olmus. “İçerdiği mesajlar da cok anlamlı ” . Cok büyük hacimli bir veritabanını yeniden kurmak sıkıntılı olabilir. Rman incremental ile cok iyi bir çözüm olmus

  2. Gökhan Çelik
    28/04/2013, 12:06 pm

    Merhaba Talip Hakan Bey,
    Standby ile Primary arasında oluşan büyük farkı kapamak için
    incremental backup from scn ( standby.) ile aldığımı backup’ı
    Standby makinesine yolladım ve rman ile catalog’a ekledim fakat
    ‘recovery database noredo’ dediğimde hiç birşey yapmadan recovery finished diyor.. Bütün bahsetmiş olduğunuz adımları uygulamama rağmen..

    control file olarak Primary’de backup aldıktan sonra standby için yarattığım control file backupini kullanıyorum…

    Standby’da control file dosyasını recover dan önce mi sonra mı güncellememiz gerekiyor?
    Bu control file dosyasının belirli bir yaratılma zamanı var mı ? Backup aldıktan hemen sonra ya da primary tarafında yeni yarattığım standby control file dosyası kullanılabilir mi?

    • 21/05/2013, 10:36 pm

      Merhaba,
      Recover işleminden önce güncellemeniz gerekiyor.

  3. 27/12/2015, 1:29 pm

    elinize sağlık çok güzel ve faydalı bir yazı olmuş

  1. No trackbacks yet.

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Log Out / Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Log Out / Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Log Out / Değiştir )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Log Out / Değiştir )

Connecting to %s

%d blogcu bunu beğendi: