Oracle DataGuard 11g R2 Kurulum, Yapılandırma ve Yönetimi

OracleDataguardBu makalamezinde Oracle Veritabanı Enterprise sürüm seçeneği ve felaketten kurtarma çözümü olan Oracle DataGuard yapılandırmasını inceleyceğiz.

Oracle DataGuard Nedir ?

Oracle Data Guard , Oracle’da yüksek erişilebilirlik ve beklenmeyen sistem hataları neticesinde oluşabilecek veri kayıplarını en aza hatta sıfıra indiren oracle veritabanı ile bütünleşik bir veri koruma eklentisidir. Oracle enterprise sürümü gerektirir.Bütünleşiktir, ek kurulum gerektirmez. Veritabanı hizmeti veren birincil sisteme (Primary) ek olarak bir veya daha fazla yedek (Secondary) sistem veya sistemlerin eş zamanlı veya eş zamanlı olmayan şekilde eşleştirilmesi prensibiyle çalışır. Çalışma prensibi , birincil veritabanında oluşan arşivlenmiş geridönüş loglarının (Archived Redo Logs) ikincil veritabanına aktarılması ve bu logların iki farklı yöntemle ikincil veritabına işlenmesine dayanır. Logların ikincil veritabanına işlenmesi yöntemi eşitlemenin fiziksel (Physical) mi mantıksal (Logical) mı olduğunu belirler. bu iki farklı işletim temel farklılıklar getirir. Sistemler birbirleriyle “Oracle Net” ile haberleşirler. Sistemler aynı ortamda veya uzak mesefalerde olabilirler. Sistemlerin yerleşimleri ile ilgili bir kısıtlama yoktur.

  • Fiziksel Bekleme Veritabanı (Physical Standby Database)

Birincil veritabanın birebir kopyasının ikincil veritabanında tutulmasıdır. İkincil veritabanı birincil veritabanın birebir kopyası olarak hazırlanır, birincil veritabanında oluşan arşiv geridönüşüm loglarının ikincil veritabanına uygulanması ile eşitlik sağlanmış olur. Fiziksel Bekleme Veritabanları açık veritabanları değillerdir. Startup Mount komutu ile açılırlar. birincil veritabanından gelen loglar Veritabanı Kurtarma (Database Recover) mantığıyla ikincil veritabanına işlenir. İstenirse ikincil vertabanı salt-okunur olarak açılabilir, fakat bu süre zarfında loglar işlenmez, biriktirilir. Tekrar işleme moduna alınarak logların işlenmesine devam edilebilir. Fiziksel Bekleme Veritabanları çoğunlukla felaket durumda kurtarma(disaster recovery) amaçlı olarak kullanılırlar. Felaket durumunda birincil veritabanının yerine geçecek olan veritabanı budur. Böylece veri kaybı olmadan ve süre kaybetmeden kurtarım yapılmış olur.

  • Mantıksal Bekleme Veritabanı (Logical Standby Database)

Birincil veritabanının mantıksal olarak bir kopyasıdır, yani tablolar ve indexler gibi nesneler aynıdır fakat datafile dosyalarının düzeni farklılık gösterebilir. Birincil veritabanından gelen loglar SQL cümleciklerine çevrilerek işlenirler. Veritabanı açıktır, yani veritabanı üzerinde raporlama işlemleri yapılabilmektedir.Mantıksal veritabanına ait birtakım kısıtlamalar vardır. Bazı veri tipleri desteklenmemetedir. Ayrıca sistemdeki eşleşecek tabloların birincil anahtar indeksinin olması gerekmektedir. Oluşturulan SQL cümlecikler bu birincil anahtarlar kullanılarak işlenmektedir. Mantıksal veritabanları hem yedekleme için kullanılırlar hem de açık veritabanı oldukları için raporlama gibi işlemlerde de kullanılırlar. Böylece birincil veritabanının üzerinden yük alınarak performans artışı sağlanmış olur. Ancak bazı veri tipleri desteklememektedir. Örneğin Oracle Spatial (shape) vb. veri tiplerini desteklemez.

Oracle DataGuard 3 Farklı Seçenekte Kullanılabilir

  • Maksimum Koruma

Bu seviyede hiçbir veri kaybı olmaması sağlanır. Birincil veritabanında oluşan redo log dosyası eş zamanlı olarak en ez bir ikincil veritabanına kopyalanıp işlenemelidir. Eğer bir sorun olur da ikincil veritabanına işlenemez ise birincil veritabanı otomatik kapatılır.

  • Maksimum Kullanılabilirlik

Bu seviye de maksimum korumada olduğu gibi sıfır veri kaybı hedeflenir, fakat hata durumunda veritabanı kapatılmaz, commit işlemi yapılmaz. hata düzelene kadar maksimum performans seviyesine geçilir. böylece veritabanının devamlılığı sağlanır. Hata düzeldikten sonra tekrar maksimum kullanılabilir seviye geçilir.

  • Maksimum Performans

Bu seviye varsayılan seviyedir ve birincil veritabanın performansında azalma olmadan koruma sağlar. Birincil veritabanında işlem commit edilir ve online redo log dosyasına yazılır. Bu redo loglar eşzamansız olarak ikincil veritabanına aktarılır ve işlenir. Log dosyalarının aktarılmasında sorun olursa sorun düzeldikten sonra kalınan yerden işleme devam edilir.

  • Sistem Gereksinimleri

Sistemler aynı donanım platformlarına sahip olmalıdırlar. Örneğin 64-bit Intel işlemcili Linux sisteme sahip olabilirler. Donanımsal olarak bir kısıt yoktur. Farklı sayıda işlemci , ram disk birimlerinden oluşabilirler. Ancak burada Oracle DataGuard sunucumuz için biçtiğimiz rol önemlidir. Eğer sadece verinin bir yedeği güvenli bir ortama çıksın düşüncesi varsa donanım olarak birincil (primary) sunucumuzdan daha düşük bir donanıma sahip olabilir. Fakat Birincil (Primary) sunucum durduğunda İkincil (Standby) sunucumdan çalışma devam etsin düşüncesi varsa o zaman donanım olarak Birincil (Primary) sunucumuzun yükünü kaldırabilecek bir sunucu olmalıdır. Aksi takdirde performans sıkıntısından kullanıcılarımız çalışamaz hale gelebilir. Oracle veritabanının enterprise sürüm olması ve sürümlerinin aynı olması gerekmektedir. Standart sürümde çalışmamaktadır. Birincil veritabanının ARCHIVELOG modunda çalışması gerekmektedir. Bütün sistemlerde “COMPATIBLE” parametrelerinin aynı olması gerekmektedir.

Şimdi Oracle DataGuard yapılandırmasına geçebiliriz.

İşletim sistemi kurulumu için “Oracle Enterprise Linux Kurulumu” makalemizi kullanabilirsiniz.

Veritabanı kurulumu için tercihimize göre;

Oracle Grid Infrastructure ile Single Instance (Standalone) Veritabanı Kurulumu

Oracle Enterprise Linux İşletim Sisteminde Standalone (Single Instance) Oracle Veritabanı Kurulumu

Kurulumda birincil (primary) veritabanımız kurulu ve çalışır durumda olmalıdır. İkincil (standby) veritabanımız ise sadece “Install Database Software Only” seçeneği ile kurulmuş “netca” komutu ile “LISTENER” servisi yaratılmış ve çalışır durumda olmalıdır. Bununla ilgili adımları yukarıda bağlantılarını verdiğim veritabanı kurulum makalelerinde bulabilirsiniz. Ayrıca birincil (primary) ve  İkincil (standby) veritabanı yazılımlarının versiyonları patchset seviyeleri aynı olmalıdır.

Sunucumuzda Birincil ve İkincil veritabanlarındaki “/etc/hosts” dosyasına sunucularımızın bilgileri yazıyoruz.

# vim /etc/hosts
-- Dosyamızı açıyoruz ve sunucularımızın bilgilerini
giriyoruz.

192.168.2.121           koraykey-db1.localdomain        koraykey-db1
192.168.2.122           koraykey-db2.localdomain        koraykey-db2
  • Birincil Veritabanı (Primary Server) Yapılacak Ayarlar

1. İşletim Sistemi ve Veritabanı kurulum işlemlerimizi tamamladıktan sonra “Oracle DataGuard” kurulumuna başlayabiliriz. Öncelikle Birincil veritabanımızda yapılacak işlemleri yapıyoruz. Veritabanımızın “ArchiveLog” modunun açık olması gerekiyor eğer kapalıysa aşağıdaki işlemlerle açıyoruz.

$ sqlplus / as sysdba 

SQL*Plus: Release 11.2.0.3.0 Production on Tue Apr 16 01:57:21 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select log_mode from v$database;

LOG_MODE
------------
ARCHIVELOG

-- Eğer yukarıdaki gibi archive log modumuz açık değilse (NOARCHIVELOG) açmak için
aşağıdaki adımları izlemeliyiz.

-- Veritabanımızı tutarlı bir şekilde kapatıyoruz.

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

-- Veritabanımızı "mount" modda açıyoruz.

SQL> startup mount;
ORACLE instance started.
Total System Global Area 1068937216 bytes
Fixed Size                  2235208 bytes
Variable Size             641729720 bytes
Database Buffers          419430400 bytes
Redo Buffers                5541888 bytes
Database mounted.

-- Veritabanımızı "ARCHIVELOG" moda alıyoruz.

SQL> alter database archivelog;
Database altered.

-- Veritabanımızı açıyoruz.

SQL> alter database open;
Database altered.

-- Tekrar sorguladığımızda "ARCHIVELOG" modda olduğunu görüyoruz.

SQL> select log_mode from v$database;   
LOG_MODE
------------
ARCHIVELOG

2. Veritabanımızda geçici Tablespace’lerin haricindeki tüm aktivitelerin loglanması sağlanır. Bu komuttan sonra “NOLOGGING” olarak ayarlanmış nesnelerde loglanmaya başlanır. Böylelikle bütün aktivitelerin log dosyalarına yazılması ve ikincil veritabanlarına uygulanması sağlanmış olur.

$ sqlplus / as sysdba 

SQL*Plus: Release 11.2.0.3.0 Production on Tue Apr 16 23:00:47 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter database force logging;

Database altered.

3. Veritabanımızda “DB_NAME” ve “DB_UNIQUE_NAME” parametrelerinin isimlerini öğreniyoruz.

$ sqlplus / as sysdba 

SQL*Plus: Release 11.2.0.3.0 Production on Tue Apr 16 23:02:21 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> show parameter db_name

NAME                                 TYPE        VALUE
------------------------------------ ----------- -----
db_name                              string      orcl
SQL> show parameter db_unique_name

NAME                                 TYPE        VALUE
------------------------------------ ----------- -----
db_unique_name                       string      orcl

4. Veritabanımızda “LOG_ARCHIVE_CONFIG” parametresini ayarlıyoruz. Burda birincil veritabanımızın ismini yazıyoruz.  Burada yazacağımız isimler aşağıdaki gibi birbirinden farklı olmalıdır.

$ sqlplus / as sysdba 

SQL*Plus: Release 11.2.0.3.0 Production on Tue Apr 16 23:07:50 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter system set log_archive_config='DG_CONFIG=(ORCL,ORCL_STBY)';

System altered.

5. Veritabanımızda “remote archive log” seçeneğimizi yapılandırıyoruz. Burada kullanacağımız alan tercihimize göre değişebilir. Biz yapılandırmamızda “Fast Recovery Area” alanımızı kullanacağız.

$ sqlplus / as sysdba 

SQL*Plus: Release 11.2.0.3.0 Production on Tue Apr 16 23:16:50 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter system set log_archive_dest_2='SERVICE=orcl_stby
  2  NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) 
  3  DB_UNIQUE_NAME=ORCL_STBY';

System altered.

SQL> alter system set log_archive_dest_state_2=enable;

System altered.

6. Veritabanımızda “LOG_ARCHIVE_FORMAT”, “LOG_ARCHIVE_MAX_PROCESSES”, “REMOTE_LOGIN_PASSWORDFILE” parametrelerini aşağıdaki gibi ayarlıyoruz.

$ sqlplus / as sysdba 

SQL*Plus: Release 11.2.0.3.0 Production on Tue Apr 16 23:22:23 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter system set log_archive_format='%t_%s_%r.arc' scope=spfile;

System altered.

SQL> alter system set log_archive_max_processes=30;

System altered.

SQL> alter system set remote_login_passwordfile=exclusive scope=spfile;

System altered.

7. Yukarıdaki ayarlar ek olarak Birincil veritabanından İkincil veritabanına geçişe hazır olması için aşağıdaki parametrelerimizi ayarlıyoruz.

$ sqlplus / as sysdba 

SQL*Plus: Release 11.2.0.3.0 Production on Tue Apr 16 23:27:58 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter system set fal_server=orcl_stby;

System altered.

SQL> alter system set standby_file_management=auto;

System altered.

Bu işlemlerimizden sonra veritabanımızı yeniden başlatmalıyız.

SQL> shu immediate;
SQL> startup;

8. Veritabanımızda “tnsnames.ora” dosyamızı aşağıdaki gibi yapılandırıyoruz. Mevcut olan veritabanı bilgilerimize ikincil veritabanımızın bilgisinide yazıyoruz. Bu değişikliği her iki sunucumuzda yapıyoruz. (Birincil ve İkincil). İkincil sunucumuzda veritabanı kurulumunu “software only” yaptığımız için bu dosya mevcut olmayabilir. birincil sunucumuzdan kopyalayabiliriz veya “/u01/app/oracle/product/11.2.0.3/db/network/admin/tnsnames.ora” altında kendimiz yarataray aşağıdaki bilgileri girebiliriz.

$ vim $ORACLE_HOME/network/admin/tnsnames.ora
-- Dosyamızı açıyoruz ve aşağıdaki gibi ikincil veritabanımızı ekliyoruz.

# Generated by Oracle configuration tools.

ORCL =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = koraykey-db1.localdomain)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl)
    )
  )

ORCL_STBY =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = koraykey-db2.localdomain)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl)
    )
  )

9. Eğer Oracle DataGuard kurulumumuzu aşağıdaki elle yapılandırma seçeneği ile kuracaksak Birincil veritabanımızın “ArchiveLog” ları dahil yedeğiniz alıyoruz.

$ rman target=/

Recovery Manager: Release 11.2.0.3.0 - Production on Tue Apr 16 23:34:36 2013

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: ORCL (DBID=1340705877)

RMAN> backup database plus archivelog;

Starting backup at 16-APR-13
current log archived
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=234 device type=DISK
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=6 RECID=1 STAMP=812935104
input archived log thread=1 sequence=7 RECID=2 STAMP=812936102
channel ORA_DISK_1: starting piece 1 at 16-APR-13
channel ORA_DISK_1: finished piece 1 at 16-APR-13
piece handle=/u01/app/oracle/fast_recovery_area/ORCL/backupset
/2013_04_16/o1_mf_annnn_TAG20130416T233504_8pvfhrq5_.bkp
tag=TAG20130416T233504 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:26
Finished backup at 16-APR-13

Starting backup at 16-APR-13
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/ORCL/datafile/o1_mf_system_8pv2vzn6_.dbf
input datafile file number=00003 name=/u01/app/oracle/oradata/ORCL/datafile/o1_mf_undotbs1_8pv2ww0f_.dbf
input datafile file number=00002 name=/u01/app/oracle/oradata/ORCL/datafile/o1_mf_sysaux_8pv2whjw_.dbf
input datafile file number=00004 name=/u01/app/oracle/oradata/ORCL/datafile/o1_mf_users_8pv2x7j2_.dbf
channel ORA_DISK_1: starting piece 1 at 16-APR-13
channel ORA_DISK_1: finished piece 1 at 16-APR-13
piece handle=/u01/app/oracle/fast_recovery_area/ORCL/backupset
/2013_04_16/o1_mf_nnndf_TAG20130416T233530_8pvfjlo5_.bkp
tag=TAG20130416T233530 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:56
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 16-APR-13
channel ORA_DISK_1: finished piece 1 at 16-APR-13
piece handle=/u01/app/oracle/fast_recovery_area/ORCL/backupset
/2013_04_16/o1_mf_ncsnf_TAG20130416T233530_8pvfn77s_.bkp
tag=TAG20130416T233530 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 16-APR-13

Starting backup at 16-APR-13
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=8 RECID=3 STAMP=812936248
channel ORA_DISK_1: starting piece 1 at 16-APR-13
channel ORA_DISK_1: finished piece 1 at 16-APR-13
piece handle=/u01/app/oracle/fast_recovery_area/ORCL/backupset
/2013_04_16/o1_mf_annnn_TAG20130416T233728_8pvfn8kl_.bkp
tag=TAG20130416T233728 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 16-APR-13

10. İkincil veritabanımız için “Control File” ve PFILE” yaratıyoruz.

$ sqlplus / as sysdba 

SQL*Plus: Release 11.2.0.3.0 Production on Tue Apr 16 23:45:11 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter database create standby controlfile as '/u01/orainstall/orcl_stby.ctl';

Database altered.

SQL> create pfile='/u01/orainstall/initorcl_stby.ora' from spfile;

File created.

-- Burada yaratmış olduğumuz "initorcl_stby.ora" dosyasında ikincil
veritabanı için düzenlemeler yapıyoruz.

$ vim /u01/orainstall/initorcl_stby.ora

-- Dosyamızı açıyoruz "db_unique_name" parametremizi ekliyoruz.
Mevcut olan diğer iki parametreyide aşağıdaki gibi düzenliyoruz.

*.db_unique_name='ORCL_STBY'
*.fal_server='ORCL'
*.log_archive_dest_2='SERVICE=orcl ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ORCL'

Oracle DataGuard yapılandırmamızda ikincil sunucu tarafındaki işlemlerimizi iki başlıkta inceleyeceğiz.

A-) İkincil Veritabanı (Standby Server) Yapılacak Ayarlar (Elle Yapılandırma)

B-) İkincil Veritabanı (Standby Server) Yapılacak Ayarlar (RMAN Dublicate)

  • İkincil Veritabanı (Primary Server) Yapılacak Ayarlar (Elle Yapılandırma)

1. İkincil veritabanımızda eğer yoksa  aşağıdaki gerekli dizinlerimizi yaratıyoruz.

$ mkdir -p /u01/app/oracle/oradata/ORCL
$ cd /u01/app/oracle/oradata/ORCL
$ mkdir controlfile  datafile  onlinelog

$ mkdir -p /u01/app/oracle/fast_recovery_area/ORCL/
$ cd /u01/app/oracle/fast_recovery_area/ORCL/
$ mkdir archivelog  backupset  controlfile  onlinelog

2. Birincil veritabanında yarattığımız dosyalarımızı ikincil veritabanımıza kopyalıyoruz.

-- Aşağıdaki İşlemleri İkincil veritabanında yapıyoruz.

-- Birincil veritabanında "controlfile" dosyamızı kopyalıyoruz
$ scp oracle@koraykey-db1:/u01/orainstall/orcl_stby.ctl /u01/app/oracle/oradata/ORCL/control01.ctl
$ cp /u01/app/oracle/oradata/ORCL/control01.ctl /u01/app/oracle/fast_recovery_area/ORCL/control02.ctl

-- Archivelogs ve Backup dosyalarımızı kopyalıyoruz.
$ scp -r oracle@koraykey-db1:/u01/app/oracle/fast_recovery_area/ORCL/archivelog /u01/app/oracle/fast_recovery_area/ORCL
$ scp -r oracle@koraykey-db1:/u01/app/oracle/fast_recovery_area/ORCL/backupset /u01/app/oracle/fast_recovery_area/ORCL

-- Parametre dosyamızı kopyalıyoruz
$ scp oracle@koraykey-db1:/u01/orainstall/initorcl_stby.ora /u01/orainstall/initorcl_stby.ora

-- Password dosyamızı kopyalıyoruz
$ scp oracle@koraykey-db1:$ORACLE_HOME/dbs/orapworcl $ORACLE_HOME/dbs

3. Sunucumuzda Listener Servisimizi  yeniden başlatıyoruz.

$ lsnrctl reload

4. Sunucumuzda birincil veritabanında alıp kopyaladığımız yedeğimizden dönüyoruz.

$ rman target=/

RMAN> startup mount;
RMAN> restore database;

5. Maksimum Koruma ve Maksimum Kullanılabilirlik seviyelerinin kullanılabilmesi için Standby Redo Logların oluşturulması gerekmektedir. Maksimum performans seviyesinde zorunlu değil fakat kullanılması performans ve koruma açısından fayda sağlar. Standby Redo Log dosyaları bekleme modundanki veritabanlarında çalışırlar. Bekleme modunda çalışma için dizayn edildiklerinden online redo loglara veya arşivlenmiş loglara göre daha fazla koruma sağlarlar. Oluşturulacak olan Standby Redo Logların boyutlarının mevcut Online Redo Logların boyutlarıyla aynı olması gerekmektedir. Aşağıda bir Standby Redo Log dosyalarının oluşturulması gösterilmiştir. Standby Redo Loglar ikincil veritabanlarında çalışırlar. Birincil veritabınında oluşturulması şartı yoktur. Fakat birincil ve ikincil veritabanlarının yer değiştirilmesi (switchover) işlemlerinden sonra düzgün çalışılabilmesi için birincil veritabanında da aynı şekilde Standby Redo Logların oluşturulması yararlı olacaktır.

-- Birincil Veritabanında oluşturulması

$ sqlplus / as sysdba

SQL> alter system set standby_file_management=manual;
SQL> alter database add logfile ('/u01/app/oracle/oradata/ORCL/online_redo01.log') size 512m;
SQL> alter database add logfile ('/u01/app/oracle/oradata/ORCL/online_redo02.log') size 512m;
SQL> alter database add logfile ('/u01/app/oracle/oradata/ORCL/online_redo03.log') size 512m;
SQL> alter system set standby_file_management=auto;

-- İkincil Veritabanında oluşturulması

$ sqlplus / as sysdba
SQL> alter database add standby logfile ('/u01/app/oracle/oradata/ORCL/standby_redo01.log') size 512m;
SQL> alter database add standby logfile ('/u01/app/oracle/oradata/ORCL/standby_redo02.log') size 512m;
SQL> alter database add standby logfile ('/u01/app/oracle/oradata/ORCL/standby_redo03.log') size 512m;
SQL> alter database add standby logfile ('/u01/app/oracle/oradata/ORCL/standby_redo04.log') size 512m;
  • İkincil Veritabanı (Standby Server) Yapılacak Ayarlar (RMAN Dublicate)

1. İkincil veritabanımızda eğer yoksa  aşağıdaki gerekli dizinlerimizi yaratıyoruz.

$ mkdir -p /u01/app/oracle/oradata/ORCL
$ cd /u01/app/oracle/oradata/ORCL
$ mkdir controlfile  datafile  onlinelog

$ mkdir -p /u01/app/oracle/fast_recovery_area/ORCL/
$ cd /u01/app/oracle/fast_recovery_area/ORCL/
$ mkdir archivelog  backupset  controlfile  onlinelog

2. Birincil veritabanında yarattığımız dosyalarımızı ikincil veritabanımıza kopyalıyoruz.

-- Buradaki işlemleri ikincil veritabanımızdan yapıyoruz.

-- Birincil veritabanında "controlfile" dosyamızı kopyalıyoruz
$scp oracle@koraykey-db1:/u01/orainstall/orcl_stby.ctl /u01/app/oracle/oradata/ORCL/control01.ctl
$cp /u01/app/oracle/oradata/ORCL/control01.ctl /u01/app/oracle/fast_recovery_area/ORCL/control02.ctl

-- Parametre dosyamızı kopyalıyoruz
$ scp oracle@koraykey-db1:/u01/orainstall/initorcl_stby.ora /u01/orainstall/initorcl_stby.ora

-- Password dosyamızı kopyalıyoruz
$ scp oracle@koraykey-db1:$ORACLE_HOME/dbs/orapworcl $ORACLE_HOME/dbs

4. Sunucumuzda “dublicate” yapılandırma kullanabilmek için ikincil sunucumuzdaki “listener.ora” dosyamızda aşağıdaki gibi düzenleme yapmalıyız.

$ vim /u01/app/oracle/product/11.2.0.3/db/network/admin/listener.ora
-- Dosyamızı açarak aşağıdaki gibi yapılandırıyoruz.

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = orcl)
      (ORACLE_HOME = /u01/app/oracle/product/11.2.0.3/db)
      (SID_NAME = orcl)
    )
  )

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = koraykey-db2.localdomain)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )

ADR_BASE_LISTENER = /u01/app/oracle

5. Sunucumuzda Listener Servisimizi  yeniden başlatıyoruz.

$ lsnrctl reload

6. Sunucumuzda “dublicate” komutu ile ikincil sunucumuzda “redo log” dosyaları otomatik oluşacaktır. Bu yüzden sadece birincil veritabanında “redo log” dosyalarımızı oluşturuyoruz. Standby Redo Loglar ikincil veritabanlarında çalışırlar. Birincil veritabınında oluşturulması şartı yoktur. Fakat birincil ve ikincil veritabanlarının yer değiştirilmesi (switchover) işlemlerinden sonra düzgün çalışılabilmesi için birincil veritabanında da aynı şekilde Standby Redo Logların oluşturulması yararlı olacaktır.

$ sqlplus / as sysdba

alter database add standby logfile ('/u01/app/oracle/oradata/ORCL/standby_redo01.log') size 512m;
alter database add standby logfile ('/u01/app/oracle/oradata/ORCL/standby_redo02.log') size 512m;
alter database add standby logfile ('/u01/app/oracle/oradata/ORCL/standby_redo03.log') size 512m;
alter database add standby logfile ('/u01/app/oracle/oradata/ORCL/standby_redo04.log') size 512m;

7. İkincil veritabanımızda “Dublicate” komutunu kullanarak Oracle DataGuard yapılandırmamızı yapıyoruz.

$ sqlplus / as sysdba

SQL> startup nomount pfile='/u01/orainstall/initorcl_stby.ora';

$ rman TARGET sys/parolamiz@ORCL AUXILIARY sys/parolamiz@ORCL_STBY

DUPLICATE TARGET DATABASE
  FOR STANDBY
  FROM ACTIVE DATABASE
  DORECOVER
  SPFILE
    SET db_unique_name='orcl_stby' COMMENT 'Standby'
      SET LOG_ARCHIVE_DEST_2='SERVICE=orcl ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl'
    SET FAL_SERVER='orcl' COMMENT 'Primary'
  NOFILENAMECHECK;

8. Oracle DataGuard sunucumuzda “log” işlemeyi başlatıyoruz.

-- Aşağıdaki işlemi ikincil (standby) veritabanımızda yapıyoruz.

$ sqlplus / as sysdba 

SQL*Plus: Release 11.2.0.3.0 Production on Wed Apr 17 19:29:27 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

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

-- Eğer işlemimiz hata verirse önce aşağıdaki komutu çalıştırıp sonrasında tekrar
deniyoruz.

SQL> alter database recover managed standby database cancel;

9. Oracle DataGuard veritabanlarımızdaki “Log” işlenme durumunu inceleyecelim.

-- Birincil veritabanında son archived redo log dosyalarının
durumuna bakıyoruz.

SQL> alter session set nls_date_format='DD-MON-YYYY HH24:MI:SS';

Session altered.

SQL> select sequence#, first_time, next_time
  2  from   v$archived_log
  3  order by sequence#;

 SEQUENCE# FIRST_TIME           NEXT_TIME
---------- -------------------- --------------------
         6 17-APR-2013 11:32:15 17-APR-2013 11:43:14
         7 17-APR-2013 11:43:14 17-APR-2013 11:47:00
         8 17-APR-2013 11:47:00 17-APR-2013 11:48:38
         9 17-APR-2013 11:48:38 17-APR-2013 13:14:25
        10 17-APR-2013 13:14:25 17-APR-2013 13:14:30
        11 17-APR-2013 13:14:30 17-APR-2013 13:20:32
        12 17-APR-2013 13:20:32 17-APR-2013 13:20:33
        13 17-APR-2013 13:20:33 17-APR-2013 14:27:06
        14 17-APR-2013 14:27:06 17-APR-2013 14:27:09
        15 17-APR-2013 14:27:09 17-APR-2013 14:53:54
        16 17-APR-2013 14:53:54 17-APR-2013 14:53:57

 SEQUENCE# FIRST_TIME           NEXT_TIME
---------- -------------------- --------------------
        17 17-APR-2013 14:53:57 17-APR-2013 14:57:48
        18 17-APR-2013 14:57:48 17-APR-2013 14:57:51
        19 17-APR-2013 14:57:51 17-APR-2013 15:12:10
        20 17-APR-2013 15:12:10 17-APR-2013 15:12:14
        21 17-APR-2013 15:12:14 17-APR-2013 15:18:25
        22 17-APR-2013 15:18:25 17-APR-2013 15:18:26
        23 17-APR-2013 15:18:26 17-APR-2013 15:34:12
        24 17-APR-2013 15:34:12 17-APR-2013 15:34:13
        25 17-APR-2013 15:34:13 17-APR-2013 15:44:47
        26 17-APR-2013 15:44:47 17-APR-2013 15:44:48
        27 17-APR-2013 15:44:48 17-APR-2013 15:53:22

 SEQUENCE# FIRST_TIME           NEXT_TIME
---------- -------------------- --------------------
        28 17-APR-2013 15:53:22 17-APR-2013 15:56:15
        28 17-APR-2013 15:53:22 17-APR-2013 15:56:15
        29 17-APR-2013 15:56:15 17-APR-2013 15:57:40
        29 17-APR-2013 15:56:15 17-APR-2013 15:57:40
        30 17-APR-2013 15:57:40 17-APR-2013 15:57:45
        30 17-APR-2013 15:57:40 17-APR-2013 15:57:45
        31 17-APR-2013 16:00:00 17-APR-2013 16:01:02
        32 17-APR-2013 16:01:02 17-APR-2013 16:01:08
        33 17-APR-2013 16:01:08 17-APR-2013 16:16:40
        34 17-APR-2013 16:16:40 17-APR-2013 16:16:43
        35 17-APR-2013 16:16:43 17-APR-2013 16:24:45

-- İkincil veritabanında işlenen son archived redo log dosyalarının
durumuna bakıyoruz.

SQL> alter session set nls_date_format='DD-MON-YYYY HH24:MI:SS';

Session altered.

SQL> select sequence#, first_time, next_time, applied
  2  from   v$archived_log
  3  order by sequence#;

 SEQUENCE# FIRST_TIME           NEXT_TIME            APPLIED
---------- -------------------- -------------------- ---------
        27 17-APR-2013 15:44:48 17-APR-2013 15:53:22 YES
        28 17-APR-2013 15:53:22 17-APR-2013 15:56:15 YES
        29 17-APR-2013 15:56:15 17-APR-2013 15:57:40 YES
        30 17-APR-2013 15:57:40 17-APR-2013 15:57:45 YES
        31 17-APR-2013 16:00:00 17-APR-2013 16:01:02 YES
        31 17-APR-2013 16:00:00 17-APR-2013 16:01:02 YES
        32 17-APR-2013 16:01:02 17-APR-2013 16:01:08 YES
        32 17-APR-2013 16:01:02 17-APR-2013 16:01:08 YES
        33 17-APR-2013 16:01:08 17-APR-2013 16:16:40 YES
        33 17-APR-2013 16:01:08 17-APR-2013 16:16:40 YES
        34 17-APR-2013 16:16:40 17-APR-2013 16:16:43 YES

 SEQUENCE# FIRST_TIME           NEXT_TIME            APPLIED
---------- -------------------- -------------------- ---------
        34 17-APR-2013 16:16:40 17-APR-2013 16:16:43 YES
        35 17-APR-2013 16:16:43 17-APR-2013 16:24:45 YES
        35 17-APR-2013 16:16:43 17-APR-2013 16:24:45 YES
        36 17-APR-2013 16:24:45 17-APR-2013 16:24:49 YES
        36 17-APR-2013 16:24:45 17-APR-2013 16:24:49 YES
        37 17-APR-2013 16:25:38 17-APR-2013 16:25:48 YES
        38 17-APR-2013 16:25:48 17-APR-2013 16:25:48 YES
        39 17-APR-2013 16:25:48 17-APR-2013 16:31:19 YES
        40 17-APR-2013 16:31:19 17-APR-2013 16:32:13 YES
        41 17-APR-2013 16:32:13 17-APR-2013 16:32:19 YES
        42 17-APR-2013 16:32:56 17-APR-2013 16:33:06 YES
  • Koruma Modu

Oracle DataGuard veritabanımızdaki koruma modu varsayılan olarak “maximum performance” olarak gelmektedir. İstersek yazımızın başında bahsettiğimiz koruma modlarından kendimize uygun olanla değiştirebiliriz.

-- Hangi koruma modunda olduğunu sorguluyoruz.

SQL> SELECT protection_mode FROM v$database;
PROTECTION_MODE
--------------------
MAXIMUM PERFORMANCE

-- Maximum Availability koruma moduna geçmek için aşağıdaki komutu kullanıyoruz.

SQL> alter system set log_archive_dest_2='SERVICE=orcl_stby 
2> AFFIRM SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ORCL_STBY';
SQL> alter database set standby database to maximize availability;

-- Maximum Performance koruma moduna geçmek için aşağıdaki komutu kullanıyoruz.

SQL> alter system set log_archive_dest_2='SERVICE=orcl_stby
2> NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ORCL_STBY';
SQL> alter database set standby database to maximize performance;

-- Maximum Protection koruma moduna geçmek için aşağıdaki komutu kullanıyoruz.
SQL> alter system set log_archive_dest_2='SERVICE=orcl_stby 
2> AFFIRM SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ORCL_STBY';
SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database set standby database to maximize protection;
SQL> alter database open;
  • SwitchOver

Oracle DataGuard veritabanımızda rollerin değişimine bakalım bu yapılandırmada Birincil veritabanını İkincil, İkincil veritabanını Birincil rolüne atayacağız. (SwitchOver)

-- Birincil veritabanımızın ikincil rolüne geçişi için uygunluğunu sorguluyoruz.
"Session active" veya "to standby" olması gerekir.

SQL> select switchover_status from v$database;

SWITCHOVER_STATUS
--------------------
TO STANDBY

-- Birincil veritabanımızda rol değişimini gerçekleştiriyoruz.

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

Son olarak birincil veritabanımızı kapatıp "mount" moduna alıyoruz.

SQL> shutdown immediate;
SQL> startup mount;

-- İkincil rolünden birincil rolüne geçecek Standby sunucumuzda rol geçişi için
uygunluğunu sorguluyoruz. "Session active" veya "to primary" olması gerekir.

SQL> select switchover_status from v$database;

SWITCHOVER_STATUS
--------------------
TO PRIMARY

-- İkincil rolünden birincil rolüne geçirme işlemini gerçekleştiriyoruz.

SQL> alter database commit to switchover to primary with session shutdown;

-- İkincil rolünden birincil rolüne geçen veritabanımızı açıyoruz.

SQL> alter database open;

-- Birincil rolünden ikincil rolüne geçen yeni standby sunucumuzda "redolog"
dosyalarımızın işlenmesi için aşağıdaki komutu çalıştırıyoruz.

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

-- Birincil rolünden ikincil rolüne geçen yeni standby veritabınımızı açıyoruz.

SQL> alter database open;

-- Veritabanımızı açarken
ORA-10456: cannot open standby database; media recovery session may be in progress
hatası alırken aşağıdaki işlemleri uyguladıktan sonra açılacaktır.

SQL> alter database recover managed standby database cancel;
SQL> alter database open;
  • FailOver

Oracle DataGuard veritabanımızda Birincil (Primary) sunucumuz kullanılmaz hale geldiğinde İkincil (Standby) sunucumuzu Birincil rolüne atamalıyız. Gerekli düzeltme işlemlerinden sonra tekrar rolleri değiştirebiliriz.  (FailOver)

-- Kullanılmaz duruma gelen Birincil veritabanımız "mount" modunda açılabiliyorsa
gönderilmemiş redo log archive dosyalarımızı aşağıdaki komutla gönderiyoruz.

SQL> alter system flush redo to orcl_stby;

-- Güncel ArchiveLog dosyalarımızın durumuna bakıyoruz.

SQL> select unique thread# as thread, max(sequence#) over (partition by thread#)
2> as last from v$archived_log;

-- Eğer birincil olacak ikincil sunucumuzda olmayan ArchiveLog dosyalarımızdan
olmayanları kopyalayıp aşağıdaki komut ile kayıt edebiliriz.

-- Sorgumuz sonucu olmayan dosya görürsek.
SQL> select thread#, low_sequence#, high_sequence# from v$archive_gap;

-- Kopyaladıktan sonra kayıt edebiliriz.

SQL> alter database register physical logfile 'dosyaozellikleri';

-- Birincil olacak İkincil sunucumuzda "redo apply" işlemini durduruyoruz.

SQL> alter database recover managed standby database cancel;
SQL> alter database recover managed standby database finish;
SQL> alter database activate standby database;

-- Bu işlem sonucu hata alırsak eksik dosyaların kaydına devam etmeliyiz.

-- Eğer hatayı gideremiyorsak ve veri kaybını göze alınıp çalışmaya devam
edeceksek aşağıdaki işlemi uygulamalıyız.

SQL> alter database activate physical standby database;

-- Birincil olacak İkincil sunucumuzun rol değişimi için uygunluğunu
sorguluyoruz.

SQL> select switchover_status from v$database;

SWITCHOVER_STATUS
--------------------
TO PRIMARY

-- Bu mesajdan sonra artık rol değişimini yapabiliriz. Birincil olacak ikincil
sunucumuzda aşağıdaki işlemi uyguluyoruz.

SQL> alter database commit to switchover to primary with session shutdown;
SQL> alter database open;

-- Eğer ortamımızda başka standby sunucularımız varsa aşağıdaki işlemi uyguluyoruz.

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

-- İlk Birincil sunucumuz "orcl"i tekrar primary yapmak için önce kurulum
adımları izlenerek stanby yapılır sonrasında "switchover" işlemi ile
birincil olarak değiştirilir. Dikkat edilecek konu " LOG_ARCHIVE_DEST"
parametresini düzenlememiz gerekebilir

İkincil veritabanımız kapatılması gereken durumlarda sunucumuz açılmasından sonra aşağıdaki işlemlerin yapılması gerekir. Bu işlemlerle veritabanımız yeniden “read only with apply” rolüne getirilir.

-- İkinci veritabanımız açıldıktan sonra aşağıdaki komutu çalıştırıyoruz.

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

SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY

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

SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY WITH APPLY
  • Read Only Mode

Oracle DataGuard sunucularımızdan İkincil (Standby) olanı raporlama vb. işlemler için kullanacaksak sadece okuma “read only” modunda açabilir raporlama vb. işlemlerimizi buradan yapabiliriz.

-- İkincil sunucumuzu "read only" modunda açmak için aşağıdaki adımları
uygulayabiliriz.

SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database open read only;

-- İkincil sunucumuzu yeniden eski haline "mount mode" döndürmek için aşağıdaki
adımları uygulayabiliriz.

SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database recover managed standby database disconnect from session;
  • Active DataGuard

Oracle 11g ile birlikte gelen bir yeni özelliğimiz “Active DataGuard”dır.Bu yapıda “redo apply” işlemi yapılırken ikincil veritabanı read-only modda açık olabilmektedir “Read-Only with Apply”. Oracle “Active DataGuard”ın bize sağladığı avantajlar arasında “redo apply” devam ederken anlık raporlama, yedek alma vb. işlemlerimizi Oracle “Active Dataguard” veritabanı üzerinden yapabiliriz. Böylelikle birincil veritabanımız üzerindeki yükü azaltabiliriz. Aşağıdaki işlemleri uygulayarak “Oracle Active DataGuard” özelliğini devreye alabiliriz. Unutmamamız gereken bir konuda “Oracle Active DataGuard” özelliğini kullanmak Lisans bedeli gerektirir.

SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database open read only;
SQL> alter database recover managed standby database disconnect from session;

Bu makalemizde “Oracle DataGuard Kurulum, Yapılandırma ve Yönetimini” inceledik. Bu makalemizdeki işlemler “Oracle Enterprise Linux 6.4” işletim sistemi üzerinde denenmiştir.

Bir sonraki makalemizde görüşmek üzere…

Bu yazı Oracle kategorisine gönderilmiş ve , , , , , , , , , , , , , , , , , ile etiketlenmiş. Kalıcı bağlantıyı yer imlerinize ekleyin.