Oracle 11g R2 (11.2.0.2) RAC mimarisinde Data Guard kurulumu ve yönetimi

Bu yazıda Oracle 11g R2 RAC mimarisini hem primary hemde standby veritabanı olarak kullanarak, cluster çapında Data Guard yapılandırmasını ve yönetim tekniklerini inceleyeceğiz. Aslında bu incelemeyi migration testleri kapsamında 2010 Temmuz ayında Hollanda’da datacenterımızda yapmıştım, bu sebeple o zamanki test sonuç analiz notlarımı bulup harmanlayarak bu yazıyı hazırladım. Ancak unutmadan belirtmek isterim, Swingbench adlı stres testi aracı ile 1,000 kadar sanal kullanıcıya oturum açtırıp eşzamanlı hem primary siteden INSERT-UPDATE işlemleri  yapıp hemde standby siteden SELECT  sorgularını sorunsuz yapabildiğimi söyleyebilirim ve bu sürede cluster CPU, bellek ve I/O performanslarıda oldukça iyiydi.

Bu inceleme için o tarihte kullandığım fiziksel kaynaklar; 4 adet Sun SPARC Enterprise M3000 Server ve 1 adet Sun Storage 6180 Array ünitesinden oluşmaktadır. Sunucularda, Oracle Enterprise Linux 5.4 ve Oracle 11.2 Grid Infrastructure yazılımı kurulu ve Oracle depolama sistemi olarak Oracle ASM kullanılmaktadır.

RAC kullanılacak olan primary ve standby sitelerindeki sunuculara Oracle 11gR2 GI ve RDBMS yazılımlarının kurulmuş olmalıdır. Primary sitede ayrıca bir RAC veritabanının hizmet veriyor olması gerekmektedir. Daha önce yayınlanan Oracle 11g R2 RAC kurulum adlı yazıyı referans alarak clusterware kurulumunu 2 farklı sitede ve 2 ayrı yapıda aşağıdaki mimaride gerçekleştiriyoruz.

Benim yukardaki sistemimde;

LINUX1_RACPRIM à RAC1 adlı instance içermektedir

LINUX2_RACPRIM à RAC2 adlı instance içermektedir

-----------------------------------------------------------------------------------

Primary site içerisinde RAC adlı cluster primary veritabanını bulunur ve SCAN adresi rac-scan olmuştur. DATA ve DGSTDBY adlı ASM diskgruplar mevcuttur.

LINUX1_RACSTD à RACSTD1 adlı instance içerecektir.

LINUX2_RACSTD à RACSTD2 adlı instance içerecektir.

----------------------------------------------------------------------------------------------

Standby site içerisinde RACSTD adlı cluster standby veritabanını bulunacaktır ve SCAN adresi racstd-scan olacaktır. DATA adlı disk grubu önceden mevcuttur.

Önce isterseniz RAC ve Dataguard ne anlama gelmekte ve her ikisi birlikte kullanıldığında ne gibi avantajlar sağlanmaktadır.

“Oracle RAC” küme mimarisi içerisinde yer alan birden fazla sunucunun, ortak disk katmanında bulunan tek bir veritabanına erişmesini sağlayan bir çözümdür. Birden fazla sunucu olduğu için yüksek seviyede devamlılık sağlanmaktadır. Birden fazla sunucunun aktif olarak veri tabanına erişmesi sayesinde, sunuculardan birinin çökmesi durumunda o sunucu üzerinde bulunan yük, küme içerisindeki diğer sunuculara otomatik olarak aktarılır ve kullanıcılar çalışmalarına devam eder. Ayrıca artan iş taleplerinden dolayı, daha fazla işlemci gücüne ihtiyaç duyulduğunda kullanıcıların bağlantısı kesilmeden kümeye yeni sunucuların eklenmesi mümkün olmaktadır. Bunun yanında Oracle 11g R2 itibariyle server pools adını verdiğimiz yapı ile en uygun işyükü hesaplanmakta ve işyükünün yetersiz kaldığı durumlarda ilgili havuza ek düğümler ile işyükü dengesi optimal seviyelerde sağlanmaktadır.

Oracle Data Guard, kurumsal veriler için sunulan en etkin ve kapsamlı veri devamlılığı koruma ve afet yönetimi çözümlerinden biridir. Oracle Data Guard, kurumsal verileri afet, hata ve kesintilerden korumak için bir veya daha fazla yedek veritabanının yaratılmasını, yönetimini ve takibini sağlayan yönetim, takip ve otomasyon yazılım altyapısıdır. Data Guard, bu yedek veritabanlarını ana veritabanının tutarlı kopyaları olarak tutar. Yedek veritabanları, ana veritabanından binlerce kilometre uzakta bir afet merkezinde olabileceği gibi, aynı şehir, kampüs hatta aynı odada bulunabilir. Ana veritabanının planlı ya da planlanmamış bir sebeple ulaşılamaz hale gelmesi durumunda, Data Guard, yedek veritabanlarından birini ana veritabanı olarak aktif hale getirerek ulaşılamama süresini en aza indirir ve veri kaybını önler. İstenildiği takdirde yedek veritabanı okuma amaçlı olarak da hizmet verebilmektedir.

Sonuçta, RAC teknolojisinin çoklu düğüm yapısı sayesinde devamlılık sağlama avantajını, Data Guard teknolojisinin veri devamlılığını felaket anlarında bile en üst seviyede koruma avantajı ile kaynaştırarak, en üst seviyede erişilebilirlik ve koruma performansı sağlanmaktadır.

Unutmadan tekrar belirtmek isterim, standby sitedeki RAC düğümlerde sadece Oracle 11g R2 Grid Infrastructure ve Oracle 11g R2 veritabanı yazılımı yüklüdür ve herhangi bir şekilde veritabanı kurulmamıştır.

Bu yazıda 4 düğümlü RAC mimarisinde, primary sitedeki 2 düğüm primary veritabanı read/write işlemlerine cevap verecek, standby sitedeki 2 düğüm ise standby veritabanı olarak read-only olarak istemcilere raporlama hizmeti sunacaktır. Herhangi bir failover durumunda ise aşağıdaki gibi roller değişecektir.

Bu yazıda OEM kullanmadan sqlplus, RMAN ve Data Guard Broker(dgmgrl) kullanarak standby RAC veritabanı oluşturacağız ve kurulum sonrasında çeşitli senaryolar uygulayarak yöneteceğiz. Bu yazı içerisinde dataguard standby veritabanını oluştururken genel yaklaşım adımları aşağıdaki gibi olacaktır:

• Primary veritabanında “force logging” özelliğinin etkinleştirilmesi
• Primary veritabanında ASM içinde saklı ve OCR ile  kayıt olmuş spfile kullanıldığından emin olacağız.
• Primary veritabanında standby redo log dosyalarını oluşturuyoruz.
• RAC için her instance içinde redo taşımasını yapılandırıyoruz.
• Grid Infrastructure listenerlar içerisinde hem primary hemde standby sitelerde Oracle NET yapılandırması ve RDBMS tnsnames girişlerinin eklenmesi.
• Standby sunucular için password dosyalarının oluşturulması ve ignorecase=y parametresi ekleyerek case sensitive olmayan password dosyası oluşturulması.
• Standby sitesinde pfile dosyasının ve DIAG dizinlerinin oluşturulması.
• RMAN ile primary RAC veritabanının standby RAC veritabanı olarak klonlama işlemi.Klonlama süresince RAC veritabanı işlevselliğini sürdürecekse cluster_database=FALSE değeri atanmalıdır.
• Primary veritabanında ASM içinde saklı ve OCR ile  kayıt olmuş spfile kullanıldığından emin olacağız.
• Standby veritabanını OCR içinde kayıt etme.
• DG Broker kurulumu.
• Data Guard yapılandırılmasının yapılması.

RAC veritabanının klonlanması aşamasında aşağıdaki bilgilere dikkat edilmesi gerekmektedir:

• Klonlama süresince cluster_database parametre değerini FALSE olarak atayın.
• ASM içinde paylaşımlı spfile dosyasına işaret eden bir pfile oluşturun.
• RAC veritabanlarını OCR ye kayıt edin.
• ASM içinde bulunacak ve her iki sitede instanceler arasında paylaşılacak Data Guard Broker yapılandırma dosyalarını oluşturun.
• Hem primary hemde standby veritabanını RAC cluster içinde tutun. Dataguard kurulumundan sonra switchover, failover işlemleri gerçekleştirerek rol değişimlerinin sağlanabildiğinden emin olmanızı tavsiye ederim.

Oracle 11g R2 RAC düğümlerinde Data Guard Yapılandırması

Primary veritabanı olarak kullanılacak olan RAC adlı kaynak veritabanı yapılandırılmış ve hizmete hazırdır. Bu bölümde fiziksel standby veritabanı oluşturulacak ve Data Guard Broker yapılandırılacaktır.

Önce isterseniz primary sitedeki RAC veritabanı konfigürasyonunu inceleyelim.

[oracle@linux1_racprim] $ srvctl config database -d rac

Database unique name: rac

Database name: rac

Oracle home: /u01/app/oracle/product/11.2.0/db_10

Oracle user: oracle

Spfile: + DATA/RAC/spfilerac.ora

Domain:

Start options: open

Stop options: immediate

Database role: PRIMARY

Management policy: AUTOMATIC

Server pools: rac

Database instances: rac1,rac2

Disk Groups: DATA, DGSTDBY

Mount point paths:

Services:

Type: RAC

Database is administrator managed

[oracle@ linux1_racprim] $ srvctl status database -d rac

Instance rac1 is running on node linux1_racprim

Instance rac2 is running on node linux2_racprim

1. Primary RAC veritabanında “force logging” özelliği etkinleştiriliyor.Böylece NOLOGGING takısını kullanarak yapılabilecek işlemlerin önüne geçiyoruz. Aksi durumda redo dosyasını bypass geçen NOLOGGING işlemleri sonucunda standby sunucularda blok bozulmaları oluşabilecek ve redo uygulaması böyle durumlarda durabilecektir.

 SQL> alter database force logging;

2. Standby sitede standby redo log dosyaları oluşturuluyor.  Primary RAC  veritabanında üç adet redo log dosyası olduğundan dolayı standby sitedede bir fazla , yani dört adet standby log dosyası oluşturuyoruz. Benim senaryomda kullandığım dosya yapısı Oracle Managed File(OMF) ve ASM olduğundan, isterseniz standby sunucuda OMF yi etkinleştirelim ve standby log dosyalarını saklayacak olan ASM diskgrubunu oluşturalım. Standby sitedeki  bir düğüm üzerinden aşağıdaki şekilde ASM diskleri oluşturun. /etc/rc.local içinde bu yeni diskleri eklemeyi ve sahiplik ile erişim izinlerini oracle kullanıcısına atamayı unutmayın.

[root@linux1_racstand] # service oracleasm createdisk STDBY01 /dev/sdm1

[root@linux1_racstand] # service oracleasm createdisk STDBY02 /dev/sdn1

[root@linux1_racstand] # service oracleasm scandisks

Ardından, diğer düğümdede bu yeni disklerin tanınması için taramayı başlatın.

[root@linux2_racstand] # service oracleasm scandisks

Daha sonra standby sitedeki herhangi bir düğümden(sadece bir tanesinden) DGSTDBY adındaki standby log dosyalarının tutulacağı ASM diskgrubunu oluşturuyoruz. Bu işlemler öncesinde ORACLE_SID parametresinin ASM instance’ını gösterdiğinden emin olun. Ayrıca db_create_file_dest parametresinin tüm standby düğümlerde ‘+DGSTDBY’ yi işaret ettiğinden emin olun.

[oracle@linux1_racstand] $ set ORACLE_SID=+ASM1

[oracle@linux1_racstand] $ sqlplus / as sysdba

SQL> CREATE DISKGROUP DGSTDBY

NORMAL REDUNDANCY

FAILGROUP controller1 DISK

'/dev/sdm1',

'/dev/sdn1’

ATTRIBUTE 'compatible.asm' = '11.2', 'compatible.rdbms' = '11.2',

'sector_size'='4096';

SQL> EXIT

[oracle@linux1_racstand] $ set ORACLE_SID=RAC1

[oracle@linux1_racstand] $ sqlplus / as sysdba

SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST=’+ DGSTDBY’ SCOPE=SPFILE;

İkinci düğümdede db_create_file_dest dizinini değiştiriyoruz.

[oracle@linux2_racstand] $ set ORACLE_SID=RAC2

[oracle@linux2_racstand] $ sqlplus / as sysdba

SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST=’+DGSTDBY’ SCOPE=SPFILE;

3. Standby düğümleri yeniden başlattıktan sonra standby sitedeki düğümlerden birisinde ASM instance’ına oturum açarak gerekli ASM dizinleri oluşturun.

[oracle@linux1_racstand] $ set ORACLE_SID=+ASM1

[oracle@linux1_racstand] $ asmcmd

ASMCMD> cd DATA

ASMCMD> mkdir RACSTD

ASMCMD> cd DGSTDBY

ASMCMD> mkdir RACSTD

4. Standby instanceleri restart ettikten sonra bir düğümden standby log dosyalarını oluşturuyoruz. Bu standby log dosyaları paylaşımlı disk alanında saklanacak ve cluster içindeki tüm standby düğümler tarafından erişilebilecektir. Standby log dosyalarının büyüklüğü primary redo log dosyaları ile aynı büyüklükte olmalıdır.

SQL> alter database add standby logfile thread 1 group 4 size 104857600;

SQL> alter database add standby logfile thread 1 group 5 size 104857600;

SQL> alter database add standby logfile thread 1 group 6 size 104857600;

SQL> alter database add standby logfile thread 1 group 7 size 104857600;

5. Primary veritabanı üzerindeki her instance için redo taşımasını standby veritabanına doğru yapılandırın.Bu işlemi primary sitede sadece bir düğümde yapmak yeterlidir.

SQL> alter system set log_archive_config=’dg_config=(rac,racstd)’ sid=’*’ scope=both;

SQL> alter system set log_archive_dest_2=’service=racstd SYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=racstd’ sid=’*’ scope=both;

6. Hem primary, hemde standby için SCAN listener kayıtlarını yapıyoruz ve Data Guard Broker ile uyumlu çalışması için tnsnames dosyasında gerekli eklentileri yapıyoruz. Oracle 11.2 sürümünden itibaren SCAN listener cluster içinde VIP listenerler yerine listener.ora dosyası içerisinde yer almaktadır ve tüm düğümler için ayrı ayrı ADDRESS yerine, tek bir SCAN address yeterli gelmektedir. Primary ve standb sitede farklı 2 clusterware olduğundan dolayı 2 farklı SCAN adresi vardır, rac-scan ve racstd-scan olmak üzere.rac-scan SCAN adresi primary site düğümlerini, racstd-scan SCAN adresi ise standby site düğümlerini işaret etmektedir.

Aşağıdaki girişi primary sitedeki düğümlerin tnsnames.ora dosyalarının içerisine ekliyoruz ve ardından standby sitedeki tüm düğümlere bu tnsnames.ora dosyasını kopyalıyoruz. Bu arada, sqlnet.ora dosyasınıda standby düğümlere kopyalamakta fayda var.

RAC =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = rac)

)

)

RACSTD =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = racstd-scan)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = racstd)

)

)

Tüm düğümlerdeki listener.ora dosyası nı aşağıdaki gibi değiştiriyoruz ve ardından tüm düğümlerde listenerleri yeniden yüklüyoruz(reload).

ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER_SCAN1 = ON
 
LISTENER =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = LISTENER))
)
ADR_BASE_LISTENER = /u01/app/oracle
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER = ON
LISTENER_SCAN1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = LISTENER_SCAN1))
)

SID_LIST_LISTENER =(

SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = rac)

(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)

(SID_NAME = rac)

)

(SID_DESC =

(GLOBAL_DBNAME = racstd)

(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)

(SID_NAME = racstd)

)

(SID_DESC =

(GLOBAL_DBNAME =rac_DGMGRL)

(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)

(SID_NAME = rac)

)

(SID_DESC =

(GLOBAL_DBNAME = racstd_DGMGRL)

(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)

(SID_NAME = racstd)

)

)

SID_LIST_LISTENER_SCAN1 =(

SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = rac)

(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)

(SID_NAME = rac)

)

(SID_DESC =

(GLOBAL_DBNAME = racstd)

(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)

(SID_NAME = racstd)

)

(SID_DESC =

(GLOBAL_DBNAME =rac_DGMGRL)

(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)

(SID_NAME = rac)

)

(SID_DESC =

(GLOBAL_DBNAME = racstd_DGMGRL)

(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)

(SID_NAME = racstd)

)

)
ADR_BASE_LISTENER_SCAN1 = /u01/app/oracle

7. Standby için oracle password dosyaları oluşturun. Oracle RAC ortamında dataguard yapılandırmasında karşılaşılan ORA-16191 hatasını almamak için  ignorecase=y takısını ekleyin. Standby tekli instance gibi oluşturulacak ve ardından RAC etkinleştirilecektir. Bu sebeple 3 tane password dosyası oluşturuyoruz. Biri RAC veritabanı için, biri birinci RAC düğümdeki instance için, diğeri ise ikinci RAC düğümündeki instance içindir.

orapwd file=orapwracstd entries=100 password=password1 ignorecase=y

orapwd file=orapwracstd1 entries=100 password=password1 ignorecase=y

orapwd file=orapwracstd2 entries=100 password=password1 ignorecase=y

8. Standby sitedeki tüm düğümlerdeki stanby veritabanında kullanılmak üzere $ORACLE_HOME/dbs dizini altında initracstd.ora adında bir pfile dosyası oluşturuyoruz ve bu boş dosyanın içine aşağıdaki değerleri giriyoruz.

*.cluster_database=FALSE

*.db_name=’racstd’

9. Standby sitede $ORACLE_BASE/admin/racstd/adump dizinini oluşturun.

[root@linux1_racstand] # mkdir $ORACLE_BASE/admin/racstd

[root@linux1_racstand] # mkdir $ORACLE_BASE/admin/racstd/adump

[root@linux1_racstand] # chown oracle:oinstall $ORACLE_BASE/admin/racstd

[root@linux1_racstand] # chown oracle:oinstall $ORACLE_BASE/admin/racstd/adump

[root@linux1_racstand] # chmod –R 775 $ORACLE_BASE/admin/racstd/adump

10. Oracle password dosyalarını kullanarak primary ve standby servislerine bağlantının tnsnames.ora dosyası üzerinden sağlandığından emin olun.

[root@linux1_racprim] # sqlplus sys/password1@rac as sysdba

[root@linux1_racprim] # sqlplus sys/password1@racstd as sysdba

11. Standby sitede bir düğümde veritabanını NOMOUNT modda açıyoruz.

[oracle@linux1_racstand] $ set ORACLE_SID=racstd

[oracle@linux1_racstand] $ sqlplus / as sysdba

SQL> startup nomount using pfile=’$ORACLE_HOME/dbs/initracstd.ora’;

12. RMAN scriptini kullanarak aktif olarak çalışan primary veritabanından standby RAC veritabanı oluşturulacaktır. Bu amaçla bazı parametrelerin standby veritabanını destekleyecek şekilde değiştirilmesi gerekmektedir. Bu scripti çalıştırmadan önce standby sitedeki standby RAC veritabanını NOMOUNT modda  başlatıyoruz.

[oracle@linux1_rac] $ rman target / auxiliary system/password1@racstd nocatalog

run {

allocate channel rac type disk;

allocate channel rac1 type disk;

allocate auxiliary channel racstd type disk;

duplicate target database for standby

from active database

DORECOVER

spfile

parameter_value_convert ‘rac’,’racstd’

set db_unique_name=’racstd’

set db_file_name_convert=’+DATA/RAC’,’+DATA/RACSTD’

set log_file_name_convert=’+ DGSTDBY/RAC’,’+ DGSTDBY/RACSTD’

set fal_client=’racstd’

set fal_server=’rac’

set standby_file_management=’AUTO’

set log_archive_config=’dg_config=(rac,racstd)’

set log_archive_dest_2=’service=rac SYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=rac’;}

Yukardaki işlem sonunda, klonlanan veritabanı standby veritabanı olarak, RAC adlı tüm dizinler yerini RACSTD’ye bırakacaktır. Primary sunucu rolünü standby veritabanında belirtmek için FAL_SERVER parametresine primary veritabanını yazıyoruz. Bunun yanında, eşzamanlı redo taşıması olacak, yani primary veritabanında bir redo dosyasından diğer redo dosyasına yazmaya geçiş olduğunda(switch) en son yazılmış redo log dosyasının içeriği, anında standby veritabanında ilgili standby log dosyası olarak yazılmaya başlanacaktır(redo shipping).

13. Oluşturduğumuz standby veritabanını(RACSTD) ve standby instanceleri(RACSTD1 ve RACSTD2) OCR içerisine aşağıdaki gibi kayıt ediyoruz . Standby sitedeki herhangi bir düğümden bu işlem yapılmalıdır.

[oracle@linux1_racstand] $ srvctl add database -d RACSTD –o /u01/app/oracle/product/11.2.0/db_1 -s mount -r physical_standby -c RAC

[oracle@linux1_racstand] $ srvctl add instance -d RACSTD -i RACSTD1 -n linux1_racstand

[oracle@linux1_racstand] $ srvctl add instance -d RACSTD  -i RACSTD2 -n linux2_racstand

14. Standby RAC veritabanını çalıştırarak yapılandırmanın doğruluğunu kontrol ediyoruz.

[oracle@linux1_racstand] $ srvctl status database -d RACSTD
Instance racstd1 is not running on node LINUX1_RACSTAND
Instance racstd2 is not running on node LINUX2_RACSTAND

[oracle@linux1_racstand] $ srvctl start database -d RACSTD

[oracle@linux1_racstand] $ srvctl status database -d RACSTD
Instance racstd1 is running on node LINUX1_RACSTAND
Instance racstd2 is running on node LINUX2_RACSTAND

15. Standby veritabanı için ASM dosya yapısı içerisinde bir spfile oluşturacağız, ardından bu spfile değişikliğini standby RAC veritabanında etkinleştireceğiz.

SQL> ALTER SYSTEM SET CLUSTER_DATABASE=’TRUE’ SCOPE=BOTH;

SQL> CREATE SPFILE=’+DATA/RACSTD/SPFILERACSTD.ORA’ FROM MEMORY;

[oracle@linux1_racstand] $ srvctl modify database -d racstd -p ‘+DATA/RACSTD/SPFILERACSTD.ORA’

[oracle@linux1_racstand] $ srvctl config database -d racstd

Database unique name: racstd

Database name:

Oracle home: /u01/app/oracle/product/11.2.0/db_1

Oracle user: oracle

Spfile: +DATA/RACSTD/spfileracstd.ora

Domain:

Start options: mount

Stop options: immediate

Database role: PRIMARY

Management policy: AUTOMATIC

Server pools: racstd

Database instances: racstd1,racstd2

Disk Groups: DATA,DGSTDBY

Mount point paths:

Services:

Type: RAC

Database is administrator managed

16. Standby RAC veritabanını mevcut log dosyasından redo taşıması yapacak şekilde geri yükleme durumunda başlatın.Standby RAC düğümlerin sadece birinde bu işlemi yapın.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

17. Standby RAC veritabanına primary RAC veritabanından redo taşımasının ve uygulamasının başarılı şekilde çalıştığını test edin.Aşağıdaki sorguyu hem primary hemde standby sitedeki birer düğümde çalıştırın ve sonuçların birbiri ile aynı olduğunu teyit edin. Bu durumda redo taşıma hizmetleri sorunsuz olarak çalışmaktadır.

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME

FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

SQL> select PROTECTION_MODE, PROTECTION_LEVEL, OPEN_MODE, DATABASE_ROLE from v$database;

PROTECTION_MODE           PROTECTION_LEVEL          OPEN_MODE DATABASE_ROLE

——————– ——————– ——————– —————-

MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE MOUNTED PHYSICAL STANDBY

SQL> select * from v$archive_gap;

no rows selected

18. Data Guard Broker kurulumunu tamamlıyoruz. Hem primary, hemde standby RAC veritabanlarında düğümlerin her birinde aşağıdaki komutları çalıştırıyoruz.

Primary veritabanı için;

SQL> alter system set dg_broker_config_file1=’+ DGSTDBY/rac/dr1rac.dat’ scope=both sid=’*';

SQL> alter system set dg_broker_config_file2=’+ DGSTDBY/rac/dr2rac.dat’ scope=both sid=’*';

SQL> alter system set dg_broker_start=true scope=both sid=’*';

Standby veritabanı için ise;

SQL> alter system set dg_broker_config_file1=’ +DGSTDBY/racstd/dr1racstd.dat’  scope=both sid=’*';

SQL> alter system set dg_broker_config_file2=’ +DGSTDBY/racstd/dr2racstd.dat’  scope=both sid=’*';

SQL> alter system set dg_broker_start=true scope=both sid=’*';

19. Data Guard Yapılandırmasını oluşturuyoruz. dgmgrl komutunu kullanarak önce primary veritabanını tanımlıyoruz, arkasından standby veritabanını tanımlıyoruz ve konfigürasyonu etkinleştiriyoruz.

DGMGRL> connect /

Connected.

DGMGRL> create configuration “DataGuard” as primary database is “rac” connect identifier is rac;

Configuration “DataGuard” created with primary database “rac”

DGMGRL> add database “racstd” as connect identifier is racstd;

Database “racstd” added

DGMGRL> enable configuration;

Enabled.

DGMGRL> show configuration;

Configuration – DataGuard 

Protection Mode: MaxPerformance

Databases:

rac – Primary database

racstd – Physical standby database (disabled)

Fast-Start Failover: DISABLED 

Configuration Status:

SUCCESS

  

DGMGRL> show configuration verbose;

Configuration – DataGuard

Protection Mode: MaxPerformance

Databases:

rac – Primary database

racstd – Physical standby database (disabled)

Properties:

FastStartFailoverThreshold = ’30′

OperationTimeout = ’30′

FastStartFailoverLagLimit = ’30′

CommunicationTimeout = ’180′

FastStartFailoverAutoReinstate = ‘TRUE’

FastStartFailoverPmyShutdown = ‘TRUE’

BystandersFollowRoleChange = ‘ALL’

Fast-Start Failover: DISABLED

Configuration Status:

SUCCESS

DGMGRL> show database “rac”;

Database – rac

Role: PRIMARY

Intended State: TRANSPORT-ON

Instance(s):

rac1

rac2

Database Status:

SUCCESS

DGMGRL> show database “racstd”;

Database – racstd

Role: PHYSICAL STANDBY

Intended State: APPLY-ON

Transport Lag: 0 seconds

Apply Lag: 0 seconds

Real Time Query: OFF

Instance(s):

racstd1  (apply instance)

racstd2

Database Status:

SUCCESS

19. Hem primary RAC veritabanında hemde standby RAC veritabanında Flashback Database özelliklerini etkinleştiyoruz.

Primary veritabanındaki herhangi bir düğümde;

SQL> alter database flashback on;

Database altered.

Standby veritabanındaki herhangi bir düğümde;

DGMGRL> edit database “racstd” set state=’apply-off’;

Succeeded.

SQL> alter database flashback on;

Database altered.

DGMGRL> edit database “racstd” set state=’apply-on’;

Succeeded.

20. Fast Start Failover özelliğini etkinleştiriyoruz. Böylece primary RAC veritabanı veri dosyalarının bir kısmı erişilemez olduğunda veya kontrol dosyalarından bazıları bozulduğunda veya blok bozulması meydana geldiğinde, otomatik olarak standby veritabanı READ-WRITE işlemlerine açılacak ve primary RAC veritabanı rolüne dönecektir.

DGMGRL> show fast_start failover;

Fast-Start Failover: DISABLED

Threshold: 30 seconds

Target: (none)

Observer: (none)

Lag Limit: 30 seconds

Shutdown Primary: TRUE

Auto-reinstate: TRUE

Configurable Failover Conditions

Health Conditions:

Corrupted Controlfile YES

Corrupted Dictionary YES

Inaccessible Logfile NO

Stuck Archiver NO

Datafile Offline YES

Oracle Error Conditions:

(none)

DGMGRL> enable fast_start failover;

Enabled.

DGMGRL> show fast_start failover;

Fast-Start Failover: ENABLED

Threshold: 30 seconds

Target: racstd

Observer: (none)

Lag Limit: 30 seconds

Shutdown Primary: TRUE

Auto-reinstate: TRUE

Configurable Failover Conditions

Health Conditions:

Corrupted Controlfile YES

Corrupted Dictionary YES

Inaccessible Logfile NO

Stuck Archiver NO

Datafile Offline YES

Oracle Error Conditions:

(none)

Data Guard yapılandırma testleri

Data Guard yapılandırmasının başarıyla tamamlanmasından sonra uygulamanın düzgün çalışıp çalışmadığını test yapmak amacıyla switchover ve failover işlemleri yapıyorum. Bu testlere geçmeden önce kısaca switchover ve failover işleminin ne anlama geldiğini kısaca açıklayayım.

Switchover: Primary veritabanın rolünü standby sunucuya olağan durumlarda devretme olayına switchover denir. Genellikle primary veritabanında işletim sistemi güncellemesi veya donanım yükseltmesi gibi planlanan kesintiler olacağı zaman meydana gelir. Switchover esnasında herhangi bir veri kaybı yaşanmaz. Switchover sonrasında her veritabanı yeni rolünde görev yapmaya başlar.

Failover: Dataguard ortamında failover primary veritabanının erişilemez olduğu durumlarda kullanılır. Belirli bir sure zarfında servisi geri yükleme imkanı olmaz.

Switchover işleminin yapılması:

DGMGRL> switchover to racstd;

DGMGRL> show configuration;

Configuration – DataGuard

Protection Mode: MaxPerformance

Databases:

racstd – Primary database

rac – (*) Physical standby database

Fast-Start Failover: ENABLED

Configuration Status:

SUCCESS

Koruma modunun Data Guard ortamında değiştirilmesi:

DGMGRL> edit configuration set PROTECTION MODE AS MaxAvailability;

Succeeded.

DGMGRL> show configuration;

Configuration – DataGuard

Protection Mode: MaxAvailability

Databases:

rac – Primary database

racstd – Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:

SUCCESS

DGMGRL> edit configuration set PROTECTION MODE AS MaxProtection;

Succeeded.

DGMGRL> show configuration;

Configuration – DataGuard

Protection Mode: MaxProtection

Databases:

rac – Primary database

racstd – Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:

SUCCESS

SQL> select NAME, DATABASE_ROLE, DATAGUARD_BROKER, PROTECTION_MODE,PROTECTION_LEVEL from v$database;

NAME DATABASE_ROLE DATAGUAR PROTECTION_MODE PROTECTION_LEVEL

——— —————- ——– ——————– ——————–

TST PRIMARY ENABLED MAXIMUM PROTECTION MAXIMUM PROTECTION

Oracle 11.2.0.2 sürümünden itibaren dgmgrl komut satırı içerisinden SQL cümleleri çalıştırılabilmektedir. Aşağıda bununla ilgili bir kaç örnek bulunmaktadır.

[oracle@raclinux1 ~]$ dgmgrl

DGMGRL for Linux: Version 11.2.0.2.0 – 64bit Production

Copyright (c) 2000, 2009, Oracle. All rights reserved.

Welcome to DGMGRL, type “help” for information.

DGMGRL> connect /

Connected.

DGMGRL> sql “alter system archive log current”;

Succeeded.

DGMGRL> sql “alter system switch logfile”;

Succeeded.

DGMGRL> sql “alter system archive log current”;

Succeeded.

Failover işlemi ile primary ve standby rollerin değiş tokuşu:

DGMGRL> connect sys/password1@racstd

Connected.

DGMGRL> failover to racstd;

Performing failover NOW, please wait…

Failover succeeded, new primary is “racstd”