Oracle AI Database 26ai Data Guard Kurulumu
- Ömercan Çalım
- 33 dakika önce
- 7 dakikada okunur
Oracle 26ai Data Guard Kurulum Gereksinimleri
Envanter
Birincil (Primary) veritabanı ve sunucu bilgileri:
Hostname: hexdb.localdomain IP: 192.168.0.20 İşletim Sistemi (OS): Oracle Linux 9.7 Veritabanı Sürümü: 23.26.1.0.0 Grid Sürümü: 23.26.1.0.0 Grid: +ASM DB_NAME: TEST26 DB_UNIQUE_NAME: TEST26 SID: TEST26
İkincil/Bekleme (Secondary/Standby) veritabanı ve sunucu bilgileri:
İkincil veritabanı kurulumunda runInstaller.sh aracılığıyla veritabanı yazılımları yüklendikten sonra DBCA (Database Configuration Assistance) ile veritabanı oluşturulmaz!
Hostname: hexdg.localdomain IP: 192.168.0.21 İşletim Sistemi (OS): Oracle Linux 9.7 Veritabanı Sürümü: 23.26.1.0.0 Grid Sürümü: 23.26.1.0.0 Grid: +ASM DB_NAME: TEST26 DB_UNIQUE_NAME: TEST26DG SID: TEST26DG
Sanal Makine Detayları
Bu yazımızda Oracle Linux 9 işletim sistemine sahip sunucular kullansak da Oracle 26ai veritabanı OL8 işletim sistemine de kurulabilir olduğundan tercih size ait, OL8 veya OL9 işletim sistemine sahip her iki sunucumuzu da aynı donanım değerleri ile yaratacağız, donanım değerlerini aşağıda bulabilirsiniz.
Sanal makine kurulumuna hakim değilseniz VirtualBox 7.1 ile Oracle Linux 8.10 İşletim Sistemi Kurulumu dokümanına göz atabilirsiniz. Standart Oracle Linux 8 ve 9 kurulumu arasında herhangi bir fark bulunmadığından ilgili dokümanda kurulum için ihtiyaç duyacağınız bilgileri bulabilirsiniz.
Veritabanı Detayları
Oracle AI Database 26ai Enterprise Edition ve Oracle Grid Infrastructure 26ai kurulumu standart bir Oracle Database 19c ve Oracle Grid Infrastructure 19c (Oracle Restart) kurulumuna çok benzer olduğundan kurulum sırasındaki farklılıkları aşağıda bulmakla beraber genel kurulum şemasına Oracle Grid Infrastructure 19c (Oracle Restart) Kurulumu dokümanından ulaşabilirsiniz.
İki sunucumuza da gerekli kurulumları yaptıktan sonra Oracle 26ai Data Guard kurulumuna başlayabiliriz.
26ai: dnf install oracle-ai-database-preinstall-26ai -y 19c: dnf install oracle-database-preinstall-19c -y
26ai veritabanı ve Grid dosyaları: Oracle AI Database 26ai (23.26.1) - Linux x86-64 Oracle AI Database 26ai Grid Infrastructure (23.26.1) - Linux x86-64
26ai veritabanı ve Grid ortamlarının bulunacağı dizinler:
mkdir -p /u01/app/oracle mkdir -p /u01/app/oraInventory mkdir -p /u01/app/oracle/product/23.0.0/dbhome_1 mkdir -p /u01/app/oracle/product/23.0.0/grid chown -R oracle:oinstall /u01/app/oracle chown -R oracle:oinstall /u01/app/oraInventory chmod -R 775 /u01/app
26ai Grid ortam dosyası:
ORACLE_SID=+ASM; export ORACLE_SID ORACLE_BASE=/u01/app/oracle; export ORACLE_BASE ORACLE_HOME=/u01/app/oracle/product/23.0.0/grid; export ORACLE_HOME export PATH=$ORACLE_HOME/bin:$HOME/bin:$PATH umask 022 alias oh='cd $ORACLE_HOME'
26ai DB ortam dosyası:
ORACLE_HOSTNAME=$HOSTNAME; export ORACLE_HOSTNAME ORACLE_SID=TEST26; export ORACLE_SID ORACLE_UNQNAME=TEST26; export ORACLE_UNQNAME ORACLE_BASE=/u01/app/oracle; export ORACLE_BASE ORACLE_HOME=/u01/app/oracle/product/23.0.0/dbhome_1; export ORACLE_HOME export PATH=$ORACLE_HOME/bin:$HOME/bin:$PATH umask 022 alias oh='cd $ORACLE_HOME'
Oracle 19c kurulumunda gerekli olan DISPLAY ve CV_ASSUME_DISTID ortam değişkenlerini tanımlamak zorunda değilsiniz.
Ek olarak Oracle 23ai ile beraber "Container" veritabanı zorunlu kılındığından 19c kurulumundan farklı olarak zorunlu "Plugabble" veritabanı kurulumu yapılmalı.
Data Guard Kurulum Öncesi Kontrolleri
Birincil (Primary) veritabanı kaynaklarının açık olup olmadığı kontrol edilir
$ crsctl stat res -t
$ srvctl start database -d TEST26
$ srvctl start pdb -d TEST26 -pdb TEST26pdb1
Her iki sunucunun da IP ve domain bilgisi her iki sunucuda da bulunan "/etc/hosts" dosyasına yazılır.
# vim /etc/hosts
Data Guard kurulabilmesi için birincil veritabanının "Archivelog" modunda ve "Force Logging" özelliğinin aktif olması gerekir.
SQL> select log_mode from v$database;
SQL> select force_logging from v$database;
SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;
SQL> alter database force logging;
Data Guard yapılandırılması için birincil (primary) veritabanında gerekli sistem parametreleri ayarlanır ve veritabanı yeniden başlatılır.
SQL> alter system set log_archive_config='DG_CONFIG=(TEST26,TEST26DG)' scope=both;
SQL> alter system set log_archive_dest_2='SERVICE=TEST26DG LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=TEST26DG' scope=both;
SQL> alter system set log_archive_max_processes=30 scope=both;
SQL> alter system set log_archive_dest_state_2=enable scope=both;
SQL> alter system set remote_login_passwordfile=exclusive scope=spfile;
SQL> alter system set standby_file_management=auto scope=both;
SQL> alter system set fal_server='TEST26DG' scope=both;
SQL> alter system set fal_client='TEST26' scope=both;
SQL> shutdown immediate;
SQL> startup;
Veritabanındaki online redo log, standby redo log ve bunlara ait fiziksel log dosyalarının durumunu ve yapılandırmasını aşağıdaki sorgular aracılığıyla görüntüleyebiliriz.
SQL> select * from v$log;
SQL> select * from v$standby_log;
SQL> select * from v$logfile;
Göründüğü üzere Grid kurulumu yaptığımız ve dosya yönetimi olarak ASM kullandığımız için kurulum aşamasında tanımladığımız iki disk grubunda da (DATA/RECO) online redo log dosyaları bulunmaktadır. Her iki disk grubunda da Redo log bulundurmamız hem fazladan I/O yaşanmasına neden olacağından hem de ihtiyaç fazlası olduğundan Redo log gruplarını silelim ve sadece DATA disk grubunda bulunacak şekilde yeniden oluşturalım.
Redo logların silinme ve yeniden oluşturulma işleminde grupların durumlarına ve sayısına dikkat edilmesi gerekir. Aşağıda 3 adet Redo log grubumuz olduğu görünmekte, silme işleminde toplam redo log grup sayısının 2'nin altına düşeceği senaryolarda veritabanı bu işlemin yapılmasına izin vermez bu yüzden ya önceden yeni gruplar yaratmamız gerekir ya da silme ve oluşturma işlemini peşi sıra yapmamız gerekir.
SQL> ALTER DATABASE DROP LOGFILE GROUP 1;
SQL> ALTER DATABASE ADD LOGFILE GROUP 1 '+DATA' SIZE 209715200;
SQL> ALTER DATABASE DROP LOGFILE GROUP 2;
SQL> ALTER DATABASE ADD LOGFILE GROUP 2 '+DATA' SIZE 209715200;
SQL> ALTER SYSTEM SWITCH LOGFILE;
SQL> ALTER SYSTEM CHECKPOINT;
SQL> ALTER DATABASE DROP LOGFILE GROUP 3;
SQL> ALTER DATABASE ADD LOGFILE GROUP 3 '+DATA' SIZE 209715200;
Ek olarak bir redo log grubunu silme kararı verdiğimizde STATUS=INACTIVE olmasına dikkat edilmelidir. Sorgu sonucu STATUS=CURRENT olarak görünen log grubu o an kullanımdaki log dosyalarını temsil eder, "alter system switch logfile" komutu ile anlık kullanımda olan logu bir sonraki olarak güncelleyebiliriz. Sorgu sonucu STATUS=ACTIVE olarak görünen log grupları ilgili log dosyasının kullanımda olmadığını ancak veri tabanı çökmesi veya blok bazında oluşabilen hataların giderilmesi için kurtarma (crash/block recovery) amacıyla kullanılabileceğini temsil eder.
"alter system checkpoint " komutu ile yapılan bütük değişiklikler manuel olarak veri dosyalarına (data file) yazılması için tetiklenir. Bu işlem aynı zamanda STATUS=ACTIVE redo log grubunu STATUS=INACTIVE durumuna getirir.
Birincil (primary) veritabanından transfer edeceğimiz redo log verilerinin ikincil (standby) veritabanında karşılanabilmesi için standby redo log dosyaları üretilir.
Standby redo log dosyalarını birincil redo log dosyaları ile aynı disk grubunda, aynı boyutta ve bir adet fazla sayıda olmak üzere oluşturuyoruz. Standby redo log dosyalarını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 thread 1 group 11 ('+DATA') size 209715200;
SQL> alter database add standby logfile thread 1 group 12 ('+DATA') size 209715200;
SQL> alter database add standby logfile thread 1 group 13 ('+DATA') size 209715200;
SQL> alter database add standby logfile thread 1 group 14 ('+DATA') size 209715200;
Sorgumuzu yeniden çalıştırdığımızda redo log ve standby redo log dosyalarını şekildeki gibi görüntüleyebiliriz.
Her iki sunucuda da tnsnames.ora dosyası aşağıdaki bilgilerle güncellenir.
$ vim $ORACLE_HOME/network/admin/tnsnames.oraTEST26 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.20)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = TEST26)
)
)
TEST26DG =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.21)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = TEST26DG)
)
)
İkincil (Standby) veritabanında listener.ora dosyası düzenlenir.
$ . .grid
$ vim $ORACLE_HOME/network/admin/listener.oraSID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = TEST26DG)
(ORACLE_HOME = /u01/app/oracle/product/23.0.0/dbhome_1)
(SID_NAME = TEST26DG)
)
)
Dinleyici (listener) yeniden başlatılır. Yaklaşık 1 dakika kadar bekledikten veya veri tabanına bağlanıp "alter system register " komutunu çalıştırdıktan sonra ASM instance'ına ait servisler çalışmaya başlar.
$ srvctl stop listener -l LISTENER
$ srvctl start listener -l LISTENER
$ lsnrctl status LISTENER
İkincil (standby) sunucuda /tmp dizini altında pfile.ora dosyasını oluşturalım ve içini minimum gereksinimler ile dolduralım.
$ vim /tmp/pfile.oradb_name='TEST26'
db_unique_name='TEST26DG'
Birincil (primary) sunucudan ikincil (standby) sunucuya birincil veritabanına ait şifre dosyasını (orapwTEST26) gönderelim.
scp $ORACLE_HOME/dbs/orapwTEST26 oracle@192.168.0.21:/u01/app/oracle/product/23.0.0/dbhome_1/dbs/orapwTEST26DG
SQLplus kullanılarak ikincil veritabanına bağlanılır ve veritabanı nomount modda hazırladığımız pfile.ora dosyası aracılığıyla açılır.
$ sqlplus / as sysdba
SQL> STARTUP NOMOUNT PFILE='/tmp/pfile.ora';
Hem birincil hem de ikincil veri tabanlarına ve sunucularına birbirleri üzerinden tnsping ve sqlplus aracılığıyla bağlantı testleri yapılır
$ tnsping TEST26
$ tnsping TEST26DG
$ sqlplus /nolog
SQL> connect sys/<parola>@TEST26 as sysdba
SQL> connect sys/<parola>@TEST26DG as sysdba
Data Guard Kurulumu
Tüm bağlantı testleri başarıyla gerçekleştiyse, RMAN üzerinden DUPLICATE komutu ile birincil (primary) veritabanımızı ikincil (standby) veritabanı olarak kopyalamaya başlayabiliriz.
Bu komut birincil veya ikincil sunucudan verilebilir. Ben ikincil (standby) sunucu üzerinden vereceğim.
$ cd
$ . .db26ai_env
$ rman target sys/<PAROLA>@TEST26 auxiliary sys/<PAROLA>@TEST26DG
RMAN> 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 'TEST26','TEST26DG', 'test26', 'test26dg'
set db_name='TEST26'
set db_unique_name='TEST26DG'
set log_archive_max_processes='30'
set fal_server='TEST26'
set standby_file_management='AUTO'
set log_archive_config='DG_CONFIG=(TEST26,TEST26DG)'
set log_archive_dest_2='SERVICE=TEST26 ASYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) DB_UNIQUE_NAME=TEST26'
;
}Dikkat: DUPLICATE esnasında herhangi bir hata ile karşılaşırsak problemi çözdükten sonra ikincil tarafta instance 'shutdown abort' komutu ile kapatılır, ASMCMD kullanılarak disklerde oluşan spfile ve eğer bir kısmı oluştu ise veri dosyaları (datafile) silinir. Tekrar Nomount moda alındıktan sonra DUPLICATE komutu yeniden başlatılır.
$ cd
$ . .grid_env
$ asmcmd -p
ASMCMD [+]> ls
.
.
.
Kopyalama (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.
$ cd
$ . .db26ai_env
$ 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 Data Guard veritabanımızın hazır ve işler durumda olduğundan eminiz.
Dinamik View olan "v$managed_standby" bize Data Guard'a dair önemli ipuçları verecektir. MRP logları işlemekle yükümlü işlemdir, RFS ise birincil (primary) veritabanından gönderilen arşivlenen logları karşılayan ve MRP'ye ileten işlemdir. Thread, gönderilen dosyanın hangi Instance'tan geldiğini söyler eğer RAC kullanıyorsak node sayısı (yani aynı veritabanının birden fazla örneği) 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'nin gönderdiği blok ile MRP'nin işlediği bloğun aynı sekansta olduğunu görüyoruz demek ki bu veritabanında bir gecikme yaşanmıyor ve MRP'nin çalıştığını gösteriyor.
RFS, MRP'den daha ilerideyse ve MRP "APPLYING_LOG" durumunda ise ikincil tarafta işleme yetişemiyor bu durumda paralel MRP kullanılabilir.
MRP, RFS'den 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 arşiv logu bulamadığını anlarız. Bu paketler gönderim esnasında bozulmaya uğramış veya farklı sebeplerle silinmiş olabilir.
Dinamik View olan "v$archived_log" aracılığıyla arşiv logların işlenme durumunu takip edebiliriz.
SQL> select sequence#, first_time, next_time, applied from v$archived_log order by 1;
Örnek olması açısından birincil (primary) veritabanından "alter system switch logfile " komutunu çalıştırarak sekansları gözlemleyebiliriz.
İkincil (standby) veritabanından arşiv log komutunu tekrar çalıştıralım, APPLIED='IN-MEMORY' log dosyalarının belleğe (memory) uygulandığının ancak henüz veri dosyalarının (data files) güncellenmediği anlamına gelmektedir.
Bir başka dinamik View olan "v$dataguard_config " aracılığıyla birincil ve ikincil veritabanları arasında oluşan Data Guard bağlantısını gözlemleyebiliriz.
Şimdi Data Guard işleyişini görebilmek için basit bir uygulama yapalım. Birincil veritabanında bir tablo oluşturup, içerisine kayıt ekleyelim ve "commit" edelim.
$ sqlplus / as sysdba
SQL> create table test (id number, name varchar2(100));
SQL> insert into test values (1,'HEX');
SQL> commit;
İkincil (standby) veritabanında aynı tabloyu sorgulamaya çalıştığımızda hem tablonun varlığını hem de birincil veritabanında eklediğimiz kaydı görüntüleyebiliyoruz.
Gelecek yazılarımızda görüşmek üzere
Yorumlar