Primary Olarak Aktif Edilmiş Standby Veritabanını, Flashback ile Geri Alma

Merhaba Arkadaşlar,

Primary veritabanımız ulaşılamaz duruma geldiğinde standby veritabanımızı primary olarak aktif edip hayatımıza devam etmek isteyebiliriz. Bu durumda mutlaka flashback database özelliğini enable yapıp yola devam etmek büyük fayda sağlayabilir.

Örneğin tam standby veritabanını primary olarak aktif ettiniz ve bu esnada da önceki primary veritabanındaki problem çözüldü ve açıldı. Yönetimde önceki primary veritabanı ile devam etme kararı aldığını varsayalım. Bu durumda aktif ettiğimiz standby veritabanını eski haline yani standby veritabanına geri çevirmemiz lazım. Bunun için flashback database özelliğini kullanacağız.

Önce aktif edilen standby veritabanında aşağıdaki sorgu ile standby ‘ın aktif edilme anındaki SCN numarasını öğrenelim;

SQL> SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;

Aktif edilen standby veritabanını kapatıp mount modunda açalım. Ve yukarıdaki gibi öğrendiğimiz SCN numarasına flashback yapalım.

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> FLASHBACK DATABASE TO SCN standby_became_primary_scn;

Aşağıdaki komutla primary olarak aktif edilen standby veritabanı tekrar standby veritabanına çevirelim.

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

Redo transferini başlatmak için aşağıdaki kontrolleri yapalım.

Arşiv gönderilme hedefinin son durumuna aşağıdaki gibi bakalım.

SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;

Bu arşiv hedefi enable değilse, aşağıdaki gibi enable yapalım.

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE;

Redo ‘nun başarılı iletilip iletilmediğinden emin olduktan sonra, Standby veritabanında redo apply işlemini aşağıdaki gibi başlatabiliriz.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

Redo apply işlemi role geçişi esnasında oluşan redoya geldiğinde durabilir. Bu durumda paniklemeye gerek yok. Redo apply işlemini, standby ‘ın primary olarak aktif edilme anını geçene kadar bir kaç kere başlatmak gerekebilir.

Reklamlar

TROUG High Availability SIG 2016 – Galatasaray Üniversitesi Etkinliğinde Buluşalım!

he16-1

Detaylı bilgi ve kayıt için ;

High Availability SIG Meeting 2016

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

PHYSICAL STANDBY VERİTABANI SWITCHOVER & FAILOVER İŞLEMLERİ

SWITCHOVER:
 
Daha önce yazmış olduğum makalede RMAN ile aktif veritabanı üzerinden standby veritabanı kurulumunu örnek bir senaryo üzerinde incelemiştik. Bu yazımda, önceki makalemdeki senaryo üzerinden switchover nasıl yapıldığını anlatacağım.
 
Kısaca switchover, planlı rol değişimidir. Yani, canlı (primary) veritabanının standby rolüne, yedek (standby) veritabanının ise canlı (primary) rolüne geçmesidir. Yedek veritabanımızın çalışabilirliğini test etmek, canlı (primary) veritabanımızda bakım işleri yapmak, v.s gibi işler için switchover yapıyor olabiliriz. Switchover işlemi Enterprise manager, Data Guard Broker gibi GUI arayüzüyle yapılabildiği gibi sqlplus üzerinden de manuel yapılabilmektedir. Bu makalemde sqlplus üzerinden manuel switch yöntemini kullanacağım. İlerleyen yazılarımda Data Guard Broker, Enterprise manager üzerinden nasıl yapacağımızı da paylaşacağım. Aşağıda her işlem adımından önce komutları hangi sunucu üzerinde çalıştıracağımızı [sunucu] ismiyle sizlere hatırlatacağım.
 
1.   [istanbul] Canlı (primary) veritabanımızda tüm loglarımızın taşınması için logfile switch yapıyorum.

SQL>alter system switch logfile;

2.   [istanbul] Switchover yapmadan önce veritabanımızın switchover durumunu görelim.

SQL>select switchover_status from v$database;

“TO_STANDBY” şeklinde çıktı almamız gerekiyor.
3.   [istanbul] Şimdi canlı (primary) veritabanımızı standby veritabanı olarak switch edelim.

SQL>alter database commit to switchover to physical standby with session shutdown;

SQL>shutdown immediate;

SQL>startup nomount;

SQL>alter database mount standby database;

4.   [istanbul] Log larımızı apply için veritabanımızı bekletmemiz gerekiyor. Çünkü [baku] standby veritabanımızı henüz primary olarak set etmedik.

SQL>alter system set log_archive_dest_state_2=defer;

5.   [Baku] Standby veritabanımızı primary olarak switch edebiliriz. Switch etmeden önce switchover durumumuzu görelim.

SQL>select switchover_status from v$database;

“TO_PRIMARY” şeklinde çıktı almamız gerekiyor.

SQL>alter database commit to switchover to primary;

SQL>shutdown immediate;

SQL>startup;

Artık [Istanbul] sunucusu standby veritabanı, [Baku] sunucusu ise primary veritabanlarımızı barındırmaktadır.
6.   [Istanbul] Standby veritabanımızda real-time redo log appy işlemini başlatabiliriz.

SQL>recover managed standby database using current logfile disconnect;

Son olarak veritabanımızı “Read Only with Apply” olarak açalım. Böylelikle rapor kullanıcılarımız redo apply esnasında sorgulama yapabileceklerdir.

SQL>recover managed standby database cancel;

SQL>alter database open;

SQL>recover managed standby database using current logfile disconnect;

FAILOVER:
Kısaca failover, canlı (primary) veritabanının bozulması durumunda yede (standby) veritabanının primary olarak aktif edilmesidir. Geri dönüşü yoktur. Aktif edildiğinde, standby veritabanı yeniden oluşturmalıdır. Failover durumunda yapılması gerekenler:
(Önemli hatırlatma: Istanbul primary sunucu, Baku ise standby sunucudur)
1.   [Istanbul] Eğer primary veritabanına ulaşılabilir durumda ve çalışıyorsa, redo buffer standby veritabanına gönderilmesi sağlanır ve son arşivler oluşturulur.

SQL> alter system flush redo to standby_db_name;

SQL>alter system archive log current;

Hata alınmaz ise 5. Adım ile devam edebilirsiniz. Bu durumda sıfır veri kaybı ile sistem açılabilir. Hata alırsanız, en az veri kaybı ile sistemimizi açabilmek için 2. Adım ile devam ediyoruz.
2.   [Baku] Standby veritabanımızda aşağıdaki sorguyu çalıştırarak apply edilen son arşiv sıra numarasını redo thread numarsına göre öğrenmemiz gerekiyor.

SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;

3.   [Istanbul’dan Baku’ye] Eğer arşiv loglara ulaşılabiliyorsa, copyalanmamış logları standby veritabanına kopyala. Kopyalama işleminden sonra arşiv log dosyaları standby veritabanına aşağıdaki gibi register edilmelidir. Bu işlem her thread için uygulanmalıdır.

SQL> alter database register physical logfile '/oracle/ora11g/dbs/arch/ TALIP_991834413_1_102.arc ';

4.   [Baku] Standby veritabanında redo gap olup olmadığı kontrol edilmelidir. Varsa ilgili arşiv log dosyaları primary sunucudan standby sunucuya kopyalanıp register edilmelidir.

SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

SQL> alter database register physical logfile '/oracle/ora11g/dbs/arch/ TALIP_991834413_1_101.arc ';

Yukarıdaki sorgu sonucu sıfır dönene kadar 4. Adımdaki log taşıma ve register etme işlemi yapılmalıdır.
5.   [Baku] Standby veritabanında redo apply işlemi durdurulur.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

6.   [Baku] Primary den kopyaladığımız bütün arşivlerin apply edilmesi sona erdirilir.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

Hata alacak olursanız, apply edilmemiş redolarınız var demektir. 2 ve 4. Adımları tekrar gözden geçirmek gerekecektir. Yinede redo kaybını göze alıp devam etmek isterseniz;

SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;

Bu durumda veritabanınızı 8. Adımdaki gibi direk açabilirsiniz. Hata almazsanız 7. Adımla devam edebilirsiniz.
7.   [Baku] Standby veritabanı, primary veritabanı olarak switch edilir.

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

8.   [Baku] Veritabanı açılır.

SQL> ALTER DATABASE OPEN;

Failover ile Standby veritabanı primary olarak açıldığında mutlaka full yedek alınmalıdır. Ve en kısa sürede yeni bir sunucuyu standby veritabanı olarak konfigüre etmeniz gerekir. Unutmayın verilerimiz bizim için çok kıymetlidir 🙂

Talip Hakan Öztürk

RMAN ile Aktif Veritabanı Üzerinden Standby Veritabanı Kurulumu

Merhaba Arkadaşlar,

Bu makalemde RMAN kullanarak aktif veritabanı üzerinden physical standby veritabanı kurulumu için gerekli işlem adımlarını yazacağım. Physical Standby veritabanı kurulumu için birkaç yöntem mevcuttur. Bunlar; Cold yedek kullanarak (veritabanı kapalı iken veri dosyalarının manuel kopyalanması), RMAN ile primary (ana veritabanımız) veritabanı yedeğini alıp standby (yedek veritabanımız) veritabanına geri dönülmesi yöntemleridir. Aşağıda anlatacağım yöntem ise primary veritabanı aktifken RMAN üzerinden standby veritabanı oluşturulmasıdır.

İsterseniz önce senaryomuzu belirleyelim. Biz bir banka kuruyoruz. Bankamız Türkiye ve Azerbaycan’da faaliyet gösterecek 🙂 Bankamızın genel müdürlüğü İstanbul’da olsun. Olağan üstü durum merkezimiz ise Bakü’de olsun. İstanbul’da çalışacak ana veritabanımızın (primary,production) yedeğini olağan üstü durum merkezimiz olan Bakü’de oluşturmamız isteniyor. Bakü’deki yöneticilerimiz tüm raporlamalarını Bakü’de ki standby veritabanımız üzerinden real-time yapıyor olacaklar. Veritabanlarımız 11g R2 ve işletim sistemi olarak Oracle Enterprise Linux 5 üzerinde çalışıyor olacak. Anlaşılması kolay olsun diye sunucu isimlerimi İstanbul (primary) ve Bakü (standby) olarak verdim. Istanbul sunucusunda bulunan veritabanı adımı TALIP olarak set edeceğim. Baküde ki ise TALIPDR olsun.  Aşağıda her işlem adımından önce komutları hangi sunucu üzerinde çalıştıracağımızı [sunucu] ismiyle size hatırlatacağım. Bir hatırlatma daha yapmak istiyorum. Çalıştırdığımız komutlar linux üzerinde ise “$” ile, sqlplus üzerinde ise “SQL>” ile, rman üzerinde ise “RMAN>” olarak başlayacaktır.

Kısaca yapımız;

Sunucu adı IP Veritabanı adı Rolü
Istanbul 192.168.2.101 TALIP Primary
Baku 192.168.2.102 TALIPDR Standby

 1-   Daha önce yazdığım https://taliphakanozturk.wordpress.com/2010/12/12/oracle-enterprise-linux-5-kurulumu/   makaleme göre iki sunucuya Oracle Enterprise Linux kurulumu yapıyorum. Kurulum esnasında sunucu isimlerimi Istanbul ve Baku olarak, iplerimi ise yukarıdaki tabloya göre set ediyorum.

 2-   Yine daha önce yazdığım https://taliphakanozturk.wordpress.com/2010/12/21/oracle-database-11g-r2-kurulumu-icin-enterprise-linux-uzerinde-yapilmasi-gerekenler/ makaleme göre iki sunucu için kernel parametrelerimi set ediyorum.

 3-   https://taliphakanozturk.wordpress.com/2011/01/01/oracle-database-11g-r2-kurulumu/ makaleme göre Istanbul(primary) sunucumda oracle 11g r2 veritabanı kurulumunu yapıyorum. 16. Adımda “Global Database Name” ve “SID” olarak “TALIP” adını veriyorum.

4-   https://taliphakanozturk.wordpress.com/2011/01/01/oracle-database-11g-r2-kurulumu/ Bakü (standby) sunucumda makalemin 5. adımına kadar aynen takip ediyorum. 5. Adımda “Install database software only” seçeneğini seçerek sadece software kurulumunu gerçekleştiriyorum. Veritabanı oluşturmuyorum. RMAN ile sonradan standby veritabanı oluşturacağız.

 5-   Istanbul (primary) veritabanımız arşiv modda olmalıdır. Arşiv modda değilse aşağıdaki gibi arşiv moda geçirmeliyiz.

Önce primary veritabanımızın(Istanbul) arşiv modda olup olmadığını aşağıdaki gibi kontrol edelim;

 select log_mode from v$database;

Eğer değilse (NOARCHIVELOG) ozaman aşağıdaki işlem adımları ile veritabanımızı arşiv moda geçirmemiz gerekiyor. Zaten biz bankayız 🙂 7/24 hizmet veriyoruz ve veritabanımız kesin arşiv modda olması gerekir :).

SQL>shutdown immediate;

SQL>startup mount;

SQL>alter database archivelog;

SQL>alter database open;

 6-   [Istanbul] primary veritabanımda bulunan oracle password dosyamı karşı sunucuya (Baku) ftp yada scp linux komutlarıyla kopyalıyorum. Baku sunucusunda veritabanına login olurken gerekecektir.

$scp orapwTALIP oracle@192.168.2.102:/oracle/ora11g/dbs/orapwTALIPDR

7-   [Baku] standby veritabanı sucumda adump klasörümü aşağıdaki gibi varsayılan yerinde oluşturuyorum. Çünkü veritabanı açılışta bu klasörü arayacaktır ve bulamazsa hata verir.

$mkdir $ORACLE_BASE/admin/$ORACLE_SID/adump

8-   [Baku] Standby veritabanı parametre dosyamı oluşturuyorum. ($ORACLE_HOME/dbs  altında olacak) ve dosya içine sadece veritabanı adını yazıyorum. Gerisini RMAN zaten oluşturacak J

 $vi $ORACLE_HOME/dbs/initTALIPDR.ora

Vi editör ile dosyamı açıyorum. “a” tuşuna basarak ekleme (insert) moduna geçiriyorum ve aşağıdaki satırı ekleyiyorum. Sonra “Escape” tuşuna basıyorum “wq” yazarak dosyamı kaydediyorum.

db_name='TALIPDR'

9-   [Baku ]Listener dosyamı aşağıdaki gibi açıp set ediyorum.

 $vi $ORACLE_HOME/network/admin/listener.ora

Vi editör ile dosyamı açıyorum. “a” tuşuna basarak ekleme (insert) moduna geçiriyorum ve aşağıdaki satırları ekleyiyorum. Sonra “Escape” tuşuna basıyorum “wq” yazarak dosyamı kaydediyorum. 4. Adımda Baku sunucusu üzerinde oracle software kurulumu yaparken ORACLE_HOME olarak verdiğiniz dizini aynen aşağıdaki ORACLE_HOME yazan yere yazmanız gerekmektedir. Ben “/oracle/ora11g” verdiğim için bu şekilde yazdım.

LISTENER =
   (DESCRIPTION_LIST =
        (DESCRIPTION =
        (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
        (ADDRESS = (PROTOCOL = TCP)(HOST = baku)(PORT = 1521))
        )  
 )

SID_LIST_LISTENER =
  (SID_LIST =
        (SID_DESC =
        (GLOBAL_DBNAME = TALIPDR)
        (SID_NAME = TALIPDR)
        (ORACLE_HOME = /oracle/ora11g)
        )
   )

 10- [Baku] Listener ımızı aşağıdaki gibi stop start ediyoruz. Böylelikle TALIPDR (henüz oluşturmadık) dinlemesini sağlıyoruz.

$lsnrctl stop
$lsnrctl start

11- [Istanbul ve Baku ikisinde de yapılacak] İki sunucumda da tnsnames.ora dosyamı aşağıdaki gibi set ediyorum.

$ vi $ORACLE_HOME/network/admin/tnsnames.ora

Vi editör ile dosyamı açıyorum. “a” tuşuna basarak ekleme moduna geçiriyorum ve aşağıdaki satırları ekleyiyorum. Sonra “Escape” tuşu “wq” yazarak dosyamı kaydediyorum.

TALIP =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = istanbul)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = TALIP)
    )
  )

TALIPDR =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = baku)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = TALIPDR)
    )
  )

 12-[Istanbul] Primary veritabanımda bulunan redo log dosya sayısı kadar standby log dosyası oluşturmamız gerekiyor. Default olarak 3 redo log dosyamız oluşmuştu. 3 tane standby log dosyası oluşturuyorum. Bu dosyalar RMAN ile standby(Baku) veritabanımıza da taşınacak. Primary de oluşturmamın sebebi ileride switchover ile rol değiştirirsem, yani Istanbul yedek veritabanı sunucusu Baku ise ana veritabanı sunucusu olursa Istanbulda tekrar oluşturma zahmetinde kalmamış oluruz. (Switchover için gerekli işlem adımlarını  bir sonraki makalemde yazacağım)

SQL>alter database add standby logfile '/oracle/ora11g/data_TALIP/srl01.log' size 10M;

SQL>alter database add standby logfile '/oracle/ora11g/data_TALIP/srl02.log' size 10M;

SQL>alter database add standby logfile '/oracle/ora11g/data_TALIP/srl03.log' size 10M;

13-[Baku] Şimdi Baku sunucumuzda bulunacak olan TALIPDR veritabanımızı “nomount” modda açıyoruz.

 SQL> startup nomount;

 14-[Istanbul] Artık yavaş yavaş Standby veritabanımız oluşturmaya başlayabiliriz. Önce RMAN scriptimizi hazırlayalım.

 $vi /oracle/ora11g/dataguard

Vi editör ile dosyamı açıyorum. “a” tuşuna basarak ekleme moduna geçiriyorum ve aşağıdaki satırları ekleyiyorum. Sonra “Escape” tuşu “wq” yazarak dosyamı kaydediyorum.

 run {
         allocate channel prmy1 type disk;
         allocate channel prmy2 type disk;
         allocate channel prmy3 type disk;
         allocate channel prmy4 type disk;
         allocate auxiliary channel stby type disk;
duplicate target database for standby from active database nofilenamecheck
         spfile
             parameter_value_convert 'TALIP','TALIPDR'
                  set db_file_name_convert='/TALIP/','/TALIPDR/'
                   set log_file_name_convert='/TALIP/','/TALIPDR/'
                   set db_unique_name='TALIPDR'
                   set control_files='/oracle/ora11g/data_TALIP/TALIPDR.ctl'
                   set log_archive_max_processes='5'
                   set fal_client='TALIPDR'
                   set fal_server='TALIP'
                   set standby_file_management='AUTO'
                   set log_archive_config='dg_config=(TALIP,TALIPDR)'
                   set log_archive_dest_1='service=TALIP LGWR ASYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=TALIP' ;
         sql channel prmy1 "alter system set log_archive_config=''dg_config=(TALIP,TALIPDR)''";
         sql channel prmy1 "alter system set log_archive_dest_2=''service=TALIPDR LGWR ASYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=TALIPDR''";
         sql channel prmy1 "alter system set log_archive_max_processes=5";
         sql channel prmy1 "alter system set fal_client=TALIP";
         sql channel prmy1 "alter system set fal_server=TALIPDR";
         sql channel prmy1 "alter system set standby_file_management=AUTO";
         sql channel prmy1 "alter system set log_archive_dest_state_1=enable";
         sql channel prmy1 "alter system archive log current";
         sql channel stby "alter database recover managed standby database using current logfile disconnect";
}

 15-[Istanbul] Ve geriye scriptimizi çalıştırmak kalıyor.

RMAN target sys/oracle@talip auxiliary sys/oracle@talipdr

RMAN>@dataguard

RMAN gerisini halledecektir:)

16-[Istanbul ve Baku] Son olarak iki sunucumuzun durumunu aşağıdaki sorgular ile öğrenebiliriz.

Instance ların durumunu görmek için;

SQL>select status from v$instance

Switchover durumunu ve veritabanımızın hangi rolde olduğunu görmek için;

SQL>select switchover_status,database_role from v$database;

[Baku] sunucumuzda arşivlerin apply edilip edilmediğini görmek için;

select sequence#, first_time, next_time, applied
from v$archived_log
order by sequence#;

11g ile gelen önemli özelliklerden biride arşiv apply edilirken standby veritabanımızın read-only modda açılabilir olmasıdır. Bunuda aşağıdaki gibi test edebiliriz

1-   [Baku] Recovery işlemi iptal edilir.

SQL>alter database recover managed standby database cancel;

2-   [Baku] veritabanı açılır.

SQL>alter database open read only;

3-   [Baku] Veritabanı modumuzu kontrol edelim.

SQL>select open_mode from v$database;

4-   [Baku] Tekrar apply başlatıyorum

SQL>alter database recover managed standby database using current logfile disconnect;

 5-   [Baku] Tekrar veritabanı modumuzu kontrol edelim.

SQL>select open_mode from v$database;

“READ ONLY WITH APPLY” olarak sonucu görebiliriz.

Artık canlı çalışan bir veritabanımız (Istanbul) ve bunun yedeği (Baku) standby veritabanımız hazırdır. İlerleyen makalelerimde switchover ve failover durumlarında ne yapacağımızı yazacağım.

Talip Hakan Öztürk