Archive

Archive for the ‘Data Guard’ Category

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ı?

11/04/2012 4 yorum

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İ

09/07/2011 2 yorum

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

26/06/2011 8 yorum

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

DATA GUARD Hakkında kısa kısa merak ettiklerimiz

Merhaba Arkadaşlar,

Bu makalemde Oracle ın felaket kurtarma (disaster recovery) çözümü olan Data Guard temel terminolojisi hakkında kısa kısa bilgi vereceğim.

Öncelikle Felaket(Disaster) kelimesini anlamaya çalışalım. Televizyon, radio, gazete v.s. medya aracılığı ile dünyanın bir çok yerinde bazı felaketlerin meydana geldiğini hepimiz görmekteyiz. Endonezyadaki tsunami, Amerikadaki kasırga ve hortumlar, yakın geçmişte yaşadığımız 1999 depremi bunlardan bazılarıdır. İşte bu gibi olaylara felaket (disaster), diğer bir söylemle afet diyoruz. Doğal afetler sonucu veri merkezimizi (datacenter) kaybedecek olursak, bunun bize olan bedeli eminim ki çok ağır olacaktır. Verilerimiz bizim için çok değerlidir hatta şirketimizin hazinesidir diyebiliriz. Sadece doğal afetler değil, anlık elektrik kesintisi, disk arızaları ve kullanıcı hataları gibi olaylarda verilerimizi kaybetmeye sebebiyet verebilmektedir.

Bizler veri yöneticileri olarak tüm bu felaketler oluşmadan gerekli aksiyonları almakla yükümlüyüz. Gerekli aksiyonları alırken de göz önünde bulundurmamız gereken önemli bileşenler vardır. Bu bileşenler;

RPO (Recovery Point Objective) – Ne kadar veri kaybetmeyi göze alabilirsiniz?

RTO (Recovery Time Objective) – Veri erişimi olmadan kaç dakika ayakta durabilirsiniz ?

Bu sorulara vereceğimiz mantıklık cevaplara göre hızlıca yedek sistemimizi kuruyor olmalıyız. Sistemimizi sadece kurmakla yetinmeyip, canlı verilerimizle yedek sistemimizi besmeli ve bu beslemeyide sıkı takip ediyor olmalıyız.

Şimdi ORACLE ın bu konudaki güzel çözümü Data Guard ı tanıyalım.

Data Guard ORACLE ın felaket kurtarma (disaster recovery) çözümüdür. Canlı (production) veritabanınızı felaketlerden korur, üzerindeki iş yükünü azaltır ve daha efektif kullanılmasını sağlar. Teknoloji,  ilk olarak Oracle 7 ile manuel standby veritabanı oluştururarak kullanılmaya başlandı. Oracle 8i ile Data Guard olarak karşımıza çıktı. Geçmişten günümüze Data Guard a gelen özellikeleri inceleyecek olursak; 

 ORACLE 8i

 Read-Only Standby Veritabanı

 Managed recovery

 Redo Log dosyalarını Uzak(Remote) arşivlenmesi

 ORALCE 9i

 “Zero Data Loss” Entegrasyonu

 Data Guard Broker ve Data Guard Manager GUI

 Swithcover ve Failover işlemleri

 Otomatik senkronizasyon

 Logical Standby Veritabanı

 Maximum Protection

 ORACLE 10g

 Real-Time Apply

 RAC için güçlendirilmiş destek

 Fast-Start Failover

 Asenkron redo transferi

 Data Guard switchover karşı Flashback Database

 ORACLE 11g

 Active Standby Veritabanı(Active Data Guard)

 Snapshot Standby

 Heterojen platform desteği (Production –Linux, Standby – Windows)

 Özellikleri ile zaman içinde gelişerek bugünkü halini almıştır. Bugün 11g ile sağladığı özellikler bakımından DBA lerin vazgeçemediği bir sistemdir.

 DATA GUARD 11g PROCESS MİMARİSİ SENKRON REDO TRANSFERİ (SYNC)-SIFIR VERİ KAYBI (ZERO DATA LOSS)

İşlem akışı kısaca;

1 – Kullanıcı bir transaction başlatır. Bu transaction redo buffer a yazılır. Kullanıcı transaction ı commit ettiğinde LGWR process Redo Log dosyaya yazar

2 –  LNS (LogWriter Network Service) commitlenmiş redoyu RFS (Remote File Service) bildirir. RFS standby redo log dosyaya yazar. Physical standby kullanıyorsak MRP (Managed Recovery Process) standby veritabanına apply eder. Logical Standby kullanıyorsak bu işlemi LSP (Logical Standby Process) yapar.

3 – RFS verinin başarılı işlendiği bilgisini LNS e gönderir. LNS bu bilgiyi LGWR a aktarır. Son olarak kullanıcıya başlatmış olduğu işlemin (transaction) commit edildiği bilgisi gönderilir.

Senkron redo transferi ile veri transferi garanti altına alınır. Ama bir dezavatajı vardır. canlı veritabanı (Primary) ile yedek veritabanı (Standby) arasında bir network kesintisi oluşursa veya bir şekilde Primary veritabanı standby veritabanına erişemezse, primary veritabanı standby veritabanı cevap verene kadar hang olur. Yani hizmet veremez duruma düşer. Böyle bir durum oluşmaması için “NET_TIMEOUT” parametresi kullanılması bence en mantıklı olanıdır. Bu parametre ile timeout süresi belirleyebiliriz. Kesinti durumunda primary timeout süresi kadar bekler ve bu süre dolduğunda hizmet vermeye devam eder. Data Guard 10g de bu parametre varsayılan 180 sn iken, Data Guard 11g de varsayılan 30 sndir.

DATA GUARD 11g PROCESS MİMARİSİ ASENKRON REDO TRANSFERİ (ASYNC)

Asenkron redo transferinde işlem akışı;

1 – Kullanıcı bir işlem (transaction) başlatır. Bu transaction redo buffer a yazılır. Kullanıcı transaction ı commit ettiğinde LGWR process Redo Log dosyaya yazar.

2 – LNS (LogWriter Network Service) commit edilmiş redoyu RFS (Remote File Service) bildirir. RFS standby redo log dosyaya yazar. Physical standby kullanıyorsak MRP (Managed Recovery Process) standby veritabanına apply eder. Logical Standby kullanıyorsak bu işlemi LSP (Logical Standby Process) yapar.

3 – Redo Buffer bir şekilde recycle edilirse LNS otomatik olarak redo log dosyalarını okur ve redoları buradan göndermeye başlar.

RFS verinin başarılı işlendiği (commit) hakkında LNS e geri bildirimde bulunmaz.

En çok kullanılan process mimarisidir. Asenkron redo transferi sıfır veri kaybını garanti altına almaz. Sistem en az veri kaybı ile kurtarılabilir durumdadır.

DATA GUARD KORUMAN(PROTECTION) MODLARI

3 koruma (protection) modu vardır. Aşağıdaki tablo ile özetleyebiliriz.

Mode Veri kaybı riski Transfer şekli Primary durumu
Maximum Protection Sıfır veri kaybı – İki taraflı koruma SYNC Verinin ulaştığı bilgisi beklenir,cevap gelmezse primary hang olur
Maximum Availability Sıfır veri kaybı – Tek taraflı koruma SYNC Verinin ulaştığı bilgisi beklenir,cevap gelmezse primary timeout parametresi kadar bekler. (NET_TIMEOUT)
Maximum Performance En az veri kaybı ASYNC primary hiçbirzaman verinin ulaştığına dair bilgi beklemez

 PHYSICAL STANDBY – REDO APPLY

Physical Standby Database, canlı (primary) veritabanının blok-blok  kopyasıdır. Değişiklikleri uygulamak için Veritabanı Kurtarma Fonksiyonunu kullanır. Redo Apply aktifken, raporlama ve sorgu için read-only modda açılabilir(Active Data Guard -11g ile gelen bir özellik). Canlı (Primary) veritabanına ekstra yük bindirmemek için backup işlemlerinde kullanılabilir. Read-Write modda açılabilmesi için veritabanını flashbacklog modu açık olmalıdır. Flashbacklog aktif edildikten sonra restore point oluşturularak read-write modda açılabilir. Ve tekrar restore pointe geri dönülerek standby olarak çalışması sağlanabilmektedir. Yukarıda açıklamış olduğum modlardan istenilen bir tanesi ile redo transferi yapılabilir.  Bir sonraki yazacağım makalede RMAN ile aktif veritabanı üzerinden physical standby veritabanı kurulumunu detaylı olarak sizlere anlatıyor olacağım.

İsteğe bağlı olarak primary veritabanından standby veritabanına taşınan redo kayıtları gecikmeli olarak stanby veritabanına uygulanabilir. Mesela standby veritabanımızın 2 saat arkadan gelmesini sağlayabiliriz. Böylelikle canlı (primary) veritabanımızda 2 saat içinde meydana gelebilecek kullanıcı hatalarını standby veritabanımızdan çok hızlı bir şekilde kurtarabiliriz. Gecikmeli apply aktif edildiğinde real-time apply doğal olarak devre dışı kalacaktır. Real-time apply aşağıdaki gibi aktif edilebilir.

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

Redolar yukarıdaki şekilde olduğu gibi direk standby redo log dosyasından okunarak MRP veya LSP prosesine bildirilir. Gecikmeli apply ise aşağıdaki gibi aktif edilebilir. Ve redolar arşiv log dosyalarından okunarak MRP veya LSP prosesine bildirilir.

SQL> alter database recover managed standby database delay 10;

 SNAPSHOT STANDBY(11g)

Read-write modda açılabilen ve tekrar physical standby veritabanına dönüştürülebilinen standby veritabanıdır. 11g ile aramıza katılmıştır ve oldukça kulanışlıdır. Snapshot standby aktif edildiğinde redo apply durdurulur ve arşiv log olarak yedeklenir. Physical standby a geri dönüldüğünde apply kaldığı yerden arşiv log dosyalarını apply ederek devam eder. Read-write modda açılarak test, patch, v.s gibi işlemler test edilebilir.

 LOGICAL STANDBY – SQL APPLY

 Logical Standby veritabanı  açık, aktif ve bağımsız olan bir veritabanıdır. Canlı (Primary) veritabanı ile aynı mantıksal bilgilere (row) sahiptir. Redo verileri SQL olarak apply edilirken raporlama amaçlıda kullanılabilir. Veritabanı read-write modda açık olabilir. Primary veritabanından replica olan tablolarda değişikliklere izin vermez. Logical standby veritabanının bazı kısıtlamaları vardır. LONG, LONG RAW, BFILE, ROWID, kullanıcı tanımlı tippler (user-defined types) veri tipli tablolar üzerinde yapılan işlemler apply edilememektedir. Desteklenmeyen tabloları görmek için aşağıdaki sorguları çalıştırabilirsiniz.

 select * from DBA_LOGSTDBY_UNSUPPORTED;

 select * from LOGSTDBY_UNSUPPORTED_TABLES;

 ACTIVE DATA GUARD (11g)

11g ile gelen bu özellik sayesinde redo apply edilirken standby veritabanı read-only modda açık olabilmektedir (Read-Only with Apply). Bundan dolayı Active Standby Veritabanı adı verilmiştir. Active data guard ın bize sağladığı avantajlar açısından bakacak olursak; Real-time raporlama (redo apply devam ederken), yedek alma gibi işlemlerimizi active standby veritabanı üzerinden yapabilir durumdayız. Böylelikle Canlı(production) veritabanımız üzerindeki raporlama,yedek alma gibi işlem yükünü azaltmış olacağız. Canlı veritabanımız müşterilerimize daha efektif olarak hizmet verecektir.

11g R2 ile gelen diğer bir güzelliğide sizlerle paylaşmadan yapamayacağım 🙂 g R2 öncesine kadar canlı (primary) veritabanımızın aynı anda maksimum 9 standby veritabanı olabilmekteydi. Bu rakam 11g R2 ile 32 ye çıkarılmıştır. Yukarıdaki şeklimize göre canlı veritabanımız 4 standby veritabanına real-time redo apply edebilmekte ve aynı anda rapor kullanıcılarımız real-time raporlama yapabilmektedirler. 

SWITCHOVER  & FAILOVER

Son olarak  Switchover ve Failover terimlerinden kısaca bahsetmek istiyorum. Switchover, planlı role değişimidir.  Yani canlı (primary) veritabanının standby olarak, standby veritabanının ise primary olarak hizmet vermesidir. Tekrar yeni bir veritabanı kurulumu gerektirmez. OS ve hardware bakımı, standby veritabanının çalışabilirliğini test etmek için kullanılabilir. Failover ise manuel olarak SQL ile veya basit bir GUI arayüzüyle (Data Guard Broker, Enterprise Manager) aktifleşebilen, canlı (Primary) veritabanının plansız bozulmasıdır. Böyle bir durumda standby veritabanının yeniden oluşturulması gerekir. Switchover için yapılması gereken işlem adımlarını ilerleyen makalelerimde sizlere anlatıyor olacağım.

 Resimler için kullandığım kaynaklar:

http://download.oracle.com/docs/cd/E11882_01/server.112/e17022/toc.htm

Oracle Data Guard 11g Handbook – Charles Kim

Talip Hakan Öztürk

%d blogcu bunu beğendi: