Oracle Dataguard Kurulumu (19c)

Bu yazıda Oracle'ın yüksek erişilebilirlik ve felaket kurtarma çözümü olan Dataguard teknolojisinden bahsederken, RMAN Duplicate yöntemi ile fiziksel Dataguard kurulumu yapacağız.

Dataguard Nedir?

Dataguard, beklenmeyen veritabanı hataları ve felaket anlarında veri kaybını ve kesinti süresini en aza indirmek için geliştirilmiş bekleme (standby) sunucusu olarak tanımlanabilir. Dataguard, fiziksel ve mantıksal olarak ikiye ayrılır. Mantıksal (logical) Dataguard, birincil veritabanından gelen logların SQL cümlecikleri şeklinde işlenmesidir. Fiziksel Dataguard ise logların kurtarma (recovery) mantığı ile blok blok işlenmesi neticesinde birincil veritabanı ile bire bir aynı kopyasının oluşturulmasıdır.

Eğer Dataguard sunucusunu felaket anında birincil veritabanının yerine hızlıca geçebilecek maksatla kullanacaksak sunucu özellikleri birincil veritabanının yükünü kaldırabilecek düzeyde olmalıdır. Birincil veritabanına herhangi bir sebeble erişimi kaybettiysek veya felaket yaşanmış ve sistem sürdürülebilirliğini devam ettirmek gerekiyor ise Failover dediğimiz işlem ile bekleme sunucusu ve birincil sunucu arasındaki bağ koparılır. Gerekli entegrasyonlar yapıldıktan sonra bu sunucu birincil sunucu olarak hizmet vermeye devam eder. Bekleme sunucusunun olası felaket senaryolarında işlerliğini ve sağlığını test edebilmek amacıyla belli periyotlarda Switchover dediğimiz rol değiştirme işlemi uygulanır. Bu uygulamada birincil sunucu ve bekleme sunucusu rol değiştirerek birbirlerinin yerine geçerler. Öte yandan Dataguard kullanma amacımız veri güvenliği, yedekleme ise nispeten daha düşük sistem özellikleri ile kullanmamız mümkündür.

Oracle Dataguard 3 farklı modda kullanılabilir:

• Maksimum Koruma

• Maksimum Kullanılabilirlik

• Maksimum Performans (Varsayılan)

Bu modları ve Switchover & Failover uygulamalarını gelecek yazılarda detaylı ele alacağız. Şimdi adım adım kuruluma geçelim.

Envanter

Kurulum yapacağım envanterin bilgisini iki sunucu için aşağıdaki gibi paylaşıyorum. Elimizde Single Instance birincil veritabanı ve veritabanı yazılımı kurulmuş bir Dataguard sunucusu olmalıdır.

Birincil (Primary) Veritabanı Sunucusu

"Oracle 19c Single Instance Veritabanı Kurulumu" yazısından faydalanarak kurabilirsiniz.

Hostname: data4tech.localdomain

IP: 192.168.11.128

İşletim Sistemi (OS): Oracle Linux 7.8

Veritabanı Versiyonu: 19.3.0.0

Grid: YOK

DB_NAME: orcl

DB_UNIQUE_NAME: orcl

SID: orcl

İkincil & Bekleme (Secondary & Standby) Veritabanı Sunucusu

"Oracle 19c Single Instance Veritabanı Kurulumu" yazısından faydalanarak kurabilirsiniz. Bu yazının 4. aşamasına kadar ilerlenip, veritabanı oluşturulmamış olmalıdır.

Hostname: data4techdg.localdomain

IP: 192.168.11.130

İşletim Sistemi (OS): Oracle Linux 7.8

Veritabanı Versiyonu: 19.3.0.0

Grid: YOK

DB_NAME: orcl

DB_UNIQUE_NAME: orcldg

SID: orcldg

1- Birincil Veritabanı Sunucusunda Yapılacak Konfigürasyonlar

Hosts dosyasına bekleme sunucusunun bilgileri eklenir.

# vi /etc/hosts

Dataguard kurabilmemiz için birincil veritabanının "Archivelog" modunda ve "Force Logging" olması gerekir. Log modunu kontrol ediyoruz.

SQL> select log_mode from v$database;

Eğer aktif değilse Archivelog modunu aktif edebilmek için veritabanını "Mount" moda alıyoruz.

SQL> shutdown immediate;
SQL> startup mount;

Archivelog modunu aktif edip veritabanını tekrar açıyoruz ve "force logging" yapıyoruz.

SQL> alter database archivelog;
SQL> alter database open;
SQL> select log_mode from v$database;
SQL> alter database force logging;

Dataguard konfigürasyonu için birincil tarafta gerekli veritabanı parametreleri set edilir.

SQL> alter system set log_archive_config='DG_CONFIG=(orcl,orcldg)';
SQL> alter system set log_archive_dest_2='SERVICE=orcldg LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcldg';
SQL> alter system set log_archive_dest_state_2=enable;

Gerekli parametreler ayarlandıktan sonra veritabanı kapatılıp tekrar açılır.

SQL> alter system set log_archive_format='%t_%s_%r.arc' scope=spfile;
SQL> alter system set log_archive_max_processes=30;
SQL> alter system set fal_server='orcldg' scope=both;
SQL> alter system set fal_client='orcl' scope=both;
SQL> alter system set standby_file_management=auto scope=both;
SQL> shutdown immediate;
SQL> startup;

Redolog dosyalarımızın bulunduğu dizin, boyut, grup gibi bilgileri bulabileceğimiz view'ler aşağıdaki gibidir. Görüldüğü gibi standby redolog'ları henüz oluşturulmamış.

SQL> select * from v$log;
SQL> select * from v$standby_log;
SQL> select * from v$logfile;

Standby Redolog dosyalarını birincil redolog dosyaları ile aynı dizine, aynı boyutta ve bir adet fazla sayıda olmak üzere oluşturuyoruz. Standby redolog'ların birincil tarafta oluşturulması şart değildir fakat olası bir Switchover işleminde aksaklık yaşanmaması için eklenmelidir.

SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/u01/app/oracle/oradata/ORCL/standby_redo01.log') SIZE 209715200;
SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/u01/app/oracle/oradata/ORCL/standby_redo02.log') SIZE 209715200;
SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/u01/app/oracle/oradata/ORCL/standby_redo03.log') SIZE 209715200;
SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/u01/app/oracle/oradata/ORCL/standby_redo04.log') SIZE 209715200;

Standby Redolog'larının eklendiğini görelim.

SQL> select * from v$logfile;

"tnsnames.ora" dosyasına Dataguard bilgileri eklenir.

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

LISTENER_ORCL =
  (ADDRESS = (PROTOCOL = TCP)(HOST = data4tech.localdomain)(PORT = 1521))


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

ORCLDG =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = data4techdg.localdomain)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcldg)
    )
  )

2- Bekleme (Standby) Veritabanı Sunucusunda Yapılacak Konfigürasyonlar

Hosts dosyasına iki sunucunun bilgileri eklenir.

# vi /etc/hosts

"tnsnames.ora" dosyası hazırlanır.

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

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

ORCLDG =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = data4techdg.localdomain)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcldg)
    )
  )

"listener.ora" dosyası hazırlanır.

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

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

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = orcldg)
      (ORACLE_HOME = /u01/app/oracle/product/19/db)
      (SID_NAME = orcldg)
    )
  )

Listener başlatılır, 'orcldg' servisinin durumu UNKNOWN olması normaldir.

$ lsnrctl start

Dataguard tarafında Audit dosyalarının çıkacağı dizin oluşturulur. Password dosyası birincil taraftan buraya SID'e uygun şekilde kopyalanır. Ve "init" dosyası hazırlanır. Bu dosya sadece bir instance'ı ayağa kaldırmak için kullanılacağı için yeteri kadar parametre giriyoruz.

$ mkdir -p /u01/app/oracle/admin/orcldg/adump
$ scp oracle@data4tech:$ORACLE_HOME/dbs/orapworcl /u01/app/oracle/product/19/db/dbs/orapworcldg
$ vi $ORACLE_HOME/dbs/initorcldg.ora

db_name='orcl'
db_unique_name='orcldg'
db_block_size=8192

Duplicate script'i hazırlanır. RMAN için vereceğimiz bu script birincil veya ikincil sunucudan verilebilir, ben ikincil taraftan vereceğim.

$ vi duplicate.sh

run{
allocate channel prmy1 type disk;
allocate channel prmy2 type disk;
allocate auxiliary channel stby1 type disk;
allocate auxiliary channel stby2 type disk;
duplicate target database for standby from active database dorecover NOFILENAMECHECK
spfile
 parameter_value_convert 'ORCL','ORCLDG'
 set audit_file_dest='/u01/app/oracle/admin/orcldg/adump'
 set db_unique_name='orcldg'
 set log_archive_max_processes='10'
 set fal_server='orcl'
 set standby_file_management='AUTO'
 set log_archive_config='DG_CONFIG=(orcl,orcldg)'
 set log_archive_dest_2='SERVICE=orcl LGWR ASYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl'
 set db_file_name_convert='/u01/app/oracle/oradata/ORCL', '/u01/app/oracle/oradata/ORCLDG'
 set log_file_name_convert='/u01/app/oracle/oradata/ORCL', '/u01/app/oracle/oradata/ORCLDG'
;
}

SQLPlus'a bağlanılarak Instance Nomount modda açılır.

$ sqlplus / as sysdba
SQL> startup nomount;

3- Duplicate Öncesi Kontroller ve Sonrasında Yapılacaklar

Böylece her iki sunucumuz da duplicate işlemine hazır duruma gelmiş oldu. Sırada karşılıklı bağlantı ve tnsping testlerinin yapılarak, duplicate scripti'nin çalıştırılması var.

İkincil sunucumuzda tnsping testlerini hem kendine hem karşı tarafa atmak suretiyle gerçekleştiriyoruz.

$ tnsping orcl
$ tnsping orcldg

İkincil sunucumuzda hem kendine hem karşıya bağlantı testlerini yapıyoruz. <PAROLA> yazdığım kısımda siz kendi SYS kullanıcınızın şifresini yazmalısınız.

$ sqlplus /nolog
SQL> connect sys/<PAROLA>@orcldg as sysdba

Eğer yukarıdaki gibi ORA-12528 hatası alırsak aşağıdaki Workaround'u uygulayarak geçebiliriz. Hatanın çözümü için iki sunucuda da tnsnames.ora dosyasına (UR = A) satırları eklenir.

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

...
(UR = A)
...

Tekrar bağlantı testimize dönersek...

$ sqlplus /nolog
SQL> connect sys/<PAROLA>@orcldg as sysdba
Connected.
SQL> exit
$
$ sqlplus /nolog
SQL> connect sys/<PAROLA>@orcl as sysdba
Connected.
SQL> exit

Birincil tarafta tnsping testleri yapılır.

$ tnsping orcl
$ tnsping orcldg

Birincil tarafta bağlantı testleri yapılır.

$ sqlplus /nolog
SQL> connect sys/<PAROLA>@orcl as sysdba
Connected.
SQL> exit
$
$ sqlplus /nolog
SQL> connect sys/<PAROLA>@orcldg as sysdba
Connected.
SQL> exit

Gerekli testleri başarılı şekilde yaptıktan sonra duplicate script'ini ikincil veritabanı üzerinden başlatacağız.

Dikkat: Duplicate.sh esnasında herhangi bir hata ile karşılaşırsak problemi çözdükten sonra ikincil tarafta instance 'shutdown abort' komutu ile kapatılır, oluşan spfile ve eğer bir kısmı oluştu ise datafile'lar silinir. Tekrar Nomount moda alındıktan sonra duplicate.sh verilir.

Script nohup ile verilir ve tail komutu ile log dosyasından çıktısı takip edilir.

$ nohup rman target sys/<PAROLA>@orcl auxiliary sys/<PAROLA>@orcldg < duplicate.sh > duplicate.log &
$
$ tail -f duplicate.log

Duplicate işlemi başarılı olarak tamamlandıktan sonra veritabanı "Read Only" modda açılır ve kurtarma (recovery) işlemi başlatılarak logların eş zamanlı olarak ikincil tarafta işlenmesi sağlanır. Gecikme sürelerini aşağıdaki sorgu ile gözlemleyebilirsiniz.

$ sqlplus / as sysdba
SQL> alter database open read only;
SQL> alter database recover managed standby database using current logfile disconnect from session;
SQL> set lines 200 pages 200
SQL> select name, value, time_computed from v$dataguard_stats where name like '%lag';

Artık gerçek zamanlı çalışan bir Dataguard sunucumuz hazır hale geldi.

"v$managed_standby" View'i bize Dataguard'a dair önemli ipuçları verecektir. MRP logları işleyen process'tir. RFS ise arşivlenen logları gönderen process'tir. Thread, gönderilen dosyanın hangi instance'dan geldiğini söyler eğer RAC kullanıyorsak node sayısı kadar Thread görebiliriz. Block kolonu üzerinde çalışılan block numarasıdır, sequence dosya sırasıdır.

SQL> select process,status,thread#,sequence#,block#,blocks from v$managed_standby order by 1;

Burada ne gibi çıkarımlar yapabiliriz?

• RFS'in gönderdiği block ile MRP'nin işlediği blockun aynı sequence'de olduğunu görüyoruz demek ki bu veritabanında bir gecikme yaşanmıyor ve MRP'nin durumu çalıştığını gösteriyor.

• RFS, MRP'den daha ileriyse ve MRP "APPLYING_LOG" durumunda ise ikincil tarafta işleme yetişemiyor bu durumda paralel kullanılabilir.

• MRP, RFS'ten daha ileriyse Network'e bağlı gönderimde yavaşlık olduğunu anlayabiliriz.

• RFS çalışır durumda fakat MRP, "WAIT_FOR_GAP" veya "WAIT_FOR_LOG" durumunda ise MRP'nin işlemesi gereken Archivelog'u bulamadığını anlarız. Bu paketler gönderim esnasında bozulmaya uğramış veya farklı sebeplerle silinmiş olabilir. Bu durumda ilgili archivelog'lar tespit edilip elle ikincil tarafa gönderilebilir.

Archivelog'ların işlenme durumunu takip etmek için "v$archived_log" view'inden faydalanabiliriz.

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

Şimdi Dataguard'ın işleyişini görebilmek için basit bir uygulama yapalım. Birincil veritabanında bir tablo oluşturulur, içerisine 1 kayıt eklenip commit edilir.

$ sqlplus / as sysdba
SQL> create table hr.deneme (id number, name varchar2(20));
SQL> insert into hr.deneme values (1, 'alperen');
SQL> commit;

İkincil tarafta bu tabloyu ve içerisindeki 1 kaydı görebiliriz. Fakat herhangi bir DML işlemi yapılmaya çalışıldığında "Read Only" modda olduğu için hata alınacaktır.

$ sqlplus / as sysdba
SQL> select * from hr.deneme;

Uzun vadede archivelog'ların birikmesine bağlı problemler yaşamamak için her iki tarafta bazı RMAN konfigürasyonları yapmak gerekir.

Birincil veritabanında tüm bekleme (standby) sunucularına gönderilmiş ve iki kopyası tutulan archivelog'ların gereksiz (obsolete) durumuna gelmesi için aşağıdaki konfigürasyon yapılır.

$ rman target /
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY BACKED UP 2 TIMES TO DISK;

İkincil veritabanında tüm bekleme (standby) sunucularına işlenmiş archivelog'ların gereksiz (obsolete) durumuna gelmesi için aşağıdaki konfigürasyon yapılır.

$ rman target /
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;

4EK- İkincil Sunucuda FRA Alanı Oluşturulması ve Yönetilmesi

Ayrı bir diske veya belirlenen dizine "FRA" dosyası oluşturulur.

$ cd /u01
$ mkdir FRA

Belirlenen "FRA" alanının boyutu ve dizini ikincil veritabanında set edilir. Daha sonra birincil veritabanında loglar switch edilir. Tekrar "FRA" alanı içerisinde ilgili tarihe ait dizine girildiğinde gelen archivelog'ları görebileceğiz.

İkincil Sunucu:

$ sqlplus / as sysdba
SQL> alter system set db_recovery_file_dest_size=5G;
SQL> alter system set db_recovery_file_dest='/u01/FRA';

Birincil Sunucu:

$sqlplus / as sysdba
SQL> alter system switch logfile;
SQL> r
SQL> r

İkincil Sunucu:

$ ll -lrth /u01/FRA/ORCLDG/archivelog/2021_12_13

"FRA" alanının dağılımını görebilmek ve doğru yönetebilmek için "v$recovery_area_usage" view'inden faydalanabiliriz.

$ sqlplus / as sysdba
SQL> select * from v$recovery_area_usage;

Yukarıda görüldüğü gibi Archivelog'lar FRA'nın %0.24'ünü oluşturuyor ve toplam dosya sayısı 3'tür. Uyguladığımız RMAN silme politikasına göre obsolete durumuna düşen archivelog'ların yüzdesini "PERCENT_SPACE_RECLAIMABLE" kolonu altında görebiliriz. Obsolete olan archivelog'lar alanda daralma yaşandığı zaman otomatik olarak silinecektir. Bu alanın doğru yönetilmesi Dataguard'ın durmaması veya kapanmaması açısından önemlidir.

Kullanılan alanın dolması ve geri kazanılabilir (reclaimable) alan olmaması yeni archivelog'ların gelememesine bağlı gecikme ile sonuçlanacaktır. Bu durumda "FRA" için verilen alanın boyutunu artırabiliriz.

Öte yandan kullanılan alan %80 iken geri kazanılabilir alan %60 ise bir problem olmadığını söyleyebiliriz. Bu durumda kullanılan archivelog'ların alanı %20 olarak düşünülebilir.

---

Gelecek yazılarımızda görüşmek üzere, sağlıcakla kalın...