Pages

4 Şubat 2011 Cuma

Standby veritabanında bazı data dosyalarına redo uygulamasının durması

Eğer primary veritabanı üzerinde FORCE LOGGING etkin değilse, kullanıcıların NOLOGGING takısını kullanarak yapacakları girişler standby sunucuda ilgili tablonun veya tablolaların tutulduğu veri dosyalarına taşınmayacaktır. Bu durumdada standby üzerinde bu veri dosyalarında blok bozulmaları meydana gelecektir. Fiziksel standby veritabanındaki veri dosyalarının bir kısmının log transferini yapamadığı durumlarda bu veri dosyalarını en son SCN ye güncelleme ve kesintisiz loglamaya devam etmesini sağlamak için aşağıdaki adımları uygulayabiliriz. Tabii bu olay ile karşılaşmamak için eğer primary veritabanında FORCE LOGGING etkin değilse etkinleştirilmelidir.

  1. Öncelikle standby üzerindeki hangi veri dosyalarının redo uygulamasında eksik kaldığını tespit etmemiz gerekecektir. Bunu bulmak için aşağıdaki örnekte görüldüğü üzere V$DATAFILE görünümüne sorgu çekmemiz gerekmektedir.
SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE
        2> WHERE FIRST_NONLOGGED_SCN > 0;

FILE#              FIRST_NONLOGGED_SCN
----------         ------------------------------------
   3                   145957
   4                   150164

  1. Standby üzerinde redo uygulamasını durduruyoruz.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

  1. Standby üzerinde redo uygulamasında eksik kalan veri dosyalarını offline duruma getiriyoruz. Bu sebeple, artalan yedeği uygularken bu redo verilerinin bozuk blokları es geçmesinin önüne geçiyoruz.
SQL> ALTER DATABASE DATAFILE 3 OFFLINE FOR DROP;
SQL> ALTER DATABASE DATAFILE 4 OFFLINE FOR DROP;

  1. Standby üzerinde redo uygulamasını başlatıyoruz.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
     2> USING CURRENT LOGFILE DISCONNECT;

  1. Primary veritabanında RMAN uygulamasına oturum açıp standby üzerinde redo uygulamasında geri kalmış her bir veri dosyasının ayrı ayrı artalan yedeğini alıyoruz.
RMAN> BACKUP INCREMENTAL FROM SCN 145957 DATAFILE 3 FORMAT '/tmp/standby_%U' TAG 'FOR STANDBY';
RMAN> BACKUP INCREMENTAL FROM SCN 150164 DATAFILE 4 FORMAT '/tmp/standby_%U' TAG 'FOR STANDBY';

  1. Tüm alınan artalan yedek setlerini primary üzerinden standby sunucudaki geçici bir dizine kopyalıyoruz.
SCP /tmp/standby_* linux2:/tmp

  1. Fiziksel standby sunucuda RMAN uygulamasını başlatıp artalan yedek parçalarını katalogluyoruz.
RMAN> CATALOG START WITH '/tmp/standby_';

  1. Standby üzerinde redo uygulamasını durduruyoruz.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

  1. Standby üzerinde bu veri dosyalarını online hale getiriyoruz.
SQL> ALTER DATABASE DATAFILE 3 ONLINE;
SQL> ALTER DATABASE DATAFILE 4 ONLINE;

  1. Fiziksel standby sunucuda RMAN uygulamasından artalan yedek setlerini veritabanına redo uygulamasını etkinsizleştirerek uyguluyoruz.
RMAN> RECOVER DATAFILE 3, 4 NOREDO;

  1. Standby üzerinde V$DATAFILE görünümüne sorgu çekerek loglanmamış herhangi bir veri dosyasının olup olmadığını kontrol ediyoruz. Eğer hiçbir satır dönmezse sorun yok demektir.
SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE
     2> WHERE FIRST_NONLOGGED_SCN > 0;

  1. Standby üzerinden artalan yedekleri hem RMAN uygulaması üzerinden hemde işletim sistemi üzerinden kaldırıyoruz.
RMAN> DELETE BACKUP TAG 'FOR STANDBY';
rm /tmp/standby_*

  1. Standby üzerinde redo uygulamasını tekrar başlatıyoruz.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

1 yorum:

  1. Sizin blogu gezerken bu postunuzu okudum, guzel olmus. Ellerinize saglik.

    Oracle Data Guard uzerine ben de bazi konulari ele alib video tutoriallar duzletmisdim .

    Sonuncu videonun konusu - Why force logging on primary database.
    http://www.mahir-quluzade.com/2012/05/oracle-data-guard-11g-why-force-logging.html

    Saygilarimla
    Mahir M. Quluzade

    YanıtlaSil