BAB IV HASIL DAN PEMBAHASAN

(1)

BAB IV

HASIL DAN PEMBAHASAN

Pada bagian ini berisi tentang uji coba membangun sistem disaster recovery menggunakan Oracle Data Guard. Proses instalasi sistem operasi Oracle Enterprise Linux 7 dan instalasi RDBMS Oracle serta pembuatan database sudah dilakukan sebelumnya dan tidak dibahas pada penelitian ini.

Uji coba yang dilakukan akan berfokus pada:

• Melakukan konfigurasi pada primary database dan standby database.

• Bagaimana cara melakukan duplikasi database dari primary server ke standby server.

• Melakukan pengecekan apakah setiap perubahan data di primary database itu terkirim ke standby database

• Konfigurasi physical data guard menjadi active data guard.

• Melakukan simulasi failover yaitu pembalikan peran standby database menjadi primary database ketika primary database mengalami kagagalan.

Supaya standby database bisa digunakan untuk menggantikan primary database apabila terjadi kegagalan atau kerusakan yang disebabkan oleh faktor tertentu, maka pertama perlu dilakukan konfigurasi Data Guard. Dalam pembuatan standby database menggunakan tool bawaan dari Database Oracle 12c yaitu Recovery Manager atau sering disebut RMAN.

Pada bagian berikutnya akan dibahas tahapan membuat primary database dan

standby database.

(2)

36

4.1 Struktur Konfigurasi Oracle Data Guard

Gambar 4.1 Struktur Konfigurasi Oracle Data Guard

Komponen Primary Standby

Host/Server Name primesvr stdbysvr

IP Address 192.168.168.20 192.168.168.21

Database Name dbta dbta

Database Unique Name primedb stdbydb

Alias TNSNAMES to_primedb to_stdbydb

Instance Name dbta STDBYDB

Tabel 4.1 Rincian Desain Konfigurasi Server

Pada kedua server environment variable DB_NAME, ORACLE_BASE dan ORACLE_HOME mengacu pada nilai yang sama, yaitu:

 DB_NAME=dbta

 ORACLE_BASE=/u01/app/oracle

 ORACLE_HOME=/u01/app/oracle/product/12.2.0/db_home

4.2 Persiapan Server

Bagian pertama yang dilakukan pada uji coba ini mempersiapkan kedua server yaitu primary server dan standby server. Berikut ini langkah-langkahnya:

Primary server:

a. Disable SELinux

(3)

37

Security-Enhanced Linux (SELinux) adalah kernel keamanan linux yang memungkinkan administrator memiliki kontrol penuh terhadap akses ke sistem dan mengatur kebijakannya. SELinux merupakan mekanisme yang mampu melindungi dari berbagai serangan pada perangkat lunak, dengan menyediakan fasilitas logging dan audit untuk seluruh aktivitas yang dicurigai

^[26]

. Namun demikian, pada konfigurasi data guard SELinux harus di-disable agar komunikasi dan transfer file antar server bisa berjalan normal.

Cara melakukan disable SELinux adalah dengan mengedit file

/etc/

selinux/config

seperti berikut:

# vi /etc/selinux/config

-- ganti SELINUX menjadi disabled SELINUX=disabled

-- restart server.

# reboot

b. Disable firewall

Firewall di primary server perlu dimatikan atau disable supaya dari sisi standby server (bagian luar) bisa mengakses dan mengendalikan primary server (bagian dalam) tanpa ada hambatan.

[root@primesvr ~]# systemctl status firewalld

● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service;

enabled; vendor preset: enabled)

Active: active (running) since Wed 2022-04-20 11:24:01 WIB;

33min ago

Docs: man:firewalld(1) Main PID: 789 (firewalld)

CGroup: /system.slice/firewalld.service

└─789 /usr/bin/python2 -Es /usr/sbin/firewalld -- nofork --nopid

Apr 20 11:23:57 primesvr.mjm.com systemd[1]: Starting firewalld - dynamic fi....

Apr 20 11:24:01 primesvr.mjm.com systemd[1]: Started firewalld - dynamic fir....

Hint: Some lines were ellipsized, use -l to show in full.

[root@primesvr ~]# service firewalld stop

Redirecting to /bin/systemctl stop firewalld.service [root@primesvr ~]# systemctl disable firewalld Removed symlink /etc/systemd/system/multi- user.target.wants/firewalld.service.

(4)

38

Removed symlink /etc/systemd/system/dbus- org.fedoraproject.FirewallD1.service.

[root@primesvr ~]# systemctl status firewalld

disabled; vendor preset: enabled) Active: inactive (dead)

Docs: man:firewalld(1)

Apr 20 11:23:57 primesvr.mjm.com systemd[1]: Starting firewalld - dynamic fi....

Apr 20 11:24:01 primesvr.mjm.com systemd[1]: Started firewalld - dynamic fir....

Apr 20 11:57:24 primesvr.mjm.com systemd[1]: Stopping firewalld - dynamic fi....

Apr 20 11:57:25 primesvr.mjm.com systemd[1]: Stopped firewalld - dynamic fir....

c. Membuat direktori

/u01/BACKUP

untuk tempat backup

[root@primesvr ~]# mkdir -p /u01/BACKUP

[root@primesvr ~]# chown -R oracle:oinstall /u01/BACKUP [root@primesvr ~]# chmod -R 775 /u01/BACKUP

Standby server:

a. Disable SELinux

Sama seperti primary server, pada standby server SELinux juga perlu dimatikan atau disabled.

# vi /etc/selinux/config

-- ganti SELINUX menjadi disabled SELINUX=disabled

-- restart server.

# reboot

b. Disable firewall

Firewall di standby server perlu dimatikan atau disable supaya dari sisi primary server (bagian luar) bisa mengakses dan mengendalikan standby server (bagian dalam) tanpa ada hambatan.

[root@stdbysvr ~]# systemctl status firewalld

● firewalld.service - firewalld - dynamic firewall daemon

(5)

39

Loaded: loaded (/usr/lib/systemd/system/firewalld.service;

enabled; vendor preset: enabled)

Active: active (running) since Wed 2022-04-20 11:24:49 WIB;

14min ago

Docs: man:firewalld(1) Main PID: 819 (firewalld)

CGroup: /system.slice/firewalld.service

└─819 /usr/bin/python2 -Es /usr/sbin/firewalld -- nofork --nopid

[root@stdbysvr ~]# service firewalld stop

Redirecting to /bin/systemctl stop firewalld.service [root@stdbysvr ~]# systemctl disable firewalld Removed symlink /etc/systemd/system/multi- user.target.wants/firewalld.service.

Removed symlink /etc/systemd/system/dbus- org.fedoraproject.FirewallD1.service.

[root@stdbysvr ~]# systemctl status firewalld

disabled; vendor preset: enabled) Active: inactive (dead)

Docs: man:firewalld(1)

Apr 20 11:24:45 stdbysvr.mjm.com systemd[1]: Starting firewalld - dynamic fi....

Apr 20 11:24:49 stdbysvr.mjm.com systemd[1]: Started firewalld - dynamic fir....

Apr 20 11:40:03 stdbysvr.mjm.com systemd[1]: Stopping firewalld - dynamic fi....

Apr 20 11:40:04 stdbysvr.mjm.com systemd[1]: Stopped firewalld - dynamic fir....

c. Membuat direktori /u01/BACKUP untuk tempat backup

[root@stdbysvr ~]# mkdir -p /u01/BACKUP

[root@stdbysvr ~]# chown -R oracle:oinstall /u01/BACKUP [root@stdbysvr ~]# chmod -R 775 /u01/BACKUP

4.3 Persiapan Primary Database untuk di-copy Menjadi Standby Database Setelah semua server sudah siap, bagian selanjutnya ialah mempersiapkan primary database untuk di-copy menjadi standby database. Langkah-langkah yang harus dilakukan antara lain:

a. Mengecek instance name di primary database

SQL> SELECT instance_name, status FROM v$instance;

(6)

40

INSTANCE_NAME STATUS --- ---

dbta OPEN

b. Mengaktifkan archive log mode

Archive log mode adalah mode yang digunakan untuk membuat cadangan semua transaksi yang telah terjadi di database sehingga dapat memulihkan ke titik waktu mana pun

^[27]

.

SQL> SELECT name, log_mode, force_logging FROM v$database;

NAME LOG_MODE FORCE_LOGGING

--- --- --- DBTA NOARCHIVELOG NO

SQL> SHUTDOWN immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> STARTUP mount;

ORACLE instance started.

Total System Global Area 1560281088 bytes

Fixed Size 8621088 bytes

Variable Size 1006633952 bytes Database Buffers 536870912 bytes Redo Buffers 8155136 bytes Database mounted.

SQL> ALTER DATABASE archivelog;

Database altered.

SQL> ALTER DATABASE open;

c. Mengonfigurasi flashback database

Sebelumnya periksa apakah fitur flashback database sudah aktif atau belum dengan perintah berikut.

SQL> SELECT flashback_on FROm v$database;

FLASHBACK_ON --- NO

Dari informasi tersebut, fitur flashback belum aktif. Selanjutnya aktifkan

flashback database dengan tahapan sebagai berikut.

(7)

41

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP MOUNT;

SQL> ALTER DATABASE FLASHBACK ON;

SQL> ALTER DATABASE OPEN;

SQL> SELECT flashback_on FROM v$database;

FLASHBACK_ON --- YES

Secara default, database bisa di-flashback sejauh 1440 menit (24 jam) ke belakang. Hal ini bisa diketahui dari parameter DB_FLASHBACK

_RETENTION_TARGET.

SQL> SHOW PARAMETER db_flashback_

NAME TYPE VALUE

--- --- --- db_flashback_retention_target integer 1440

d. Mengaktifkan force logging

Force logging adalah metode teraman untuk memastikan bahwa semua

perubahan database akan dicatat dalam redo log file, bahkan untuk operasi

nologging. Artinya jika force logging diaktifkan pada tingkat yang lebih

tinggi, maka nologging pada tingkat yang lebih rendah tidak berpengaruh. Itu

berarti bahkan untuk tabel nologging sekalipun, informasi redo masih dapat

dicatat

^[28]

. Pada primary database, force logging perlu diaktifkan agar semua

operasi yang terjadi di database akan dicatat di redo log file.

(8)

42

SQL> ALTER DATABASE force logging;

SQL> COL force_logging FORMAT A15 SQL> SET LINESIZE 100

SQL> SELECT name, 2 open_mode, 3 log_mode, 4 force_logging, 5 controlfile_type 6* FROM v$database;

NAME OPEN_MODE LOG_MODE FORCE_LOGGING CONTROL --- --- --- --- --- DBTA READ WRITE ARCHIVELOG YES CURRENT

e. Melakukan backup database dengan RMAN

Sebelum melakukan backup database dengan RMAN, ada baiknya diperiksa dahulu struktur file database mulai dari tablespace, data file, control file, dan redo log file.

Informasi tablespace:

SQL> SELECT name FROM v$tablespace;

NAME

--- SYSAUX

SYSTEM UNDOTBS1 USERS TEMP

Informasi data file:

SQL> SELECT name FROM v$datafile;

NAME

--- /u01/app/oracle/oradata/dbta/system01.dbf

/u01/app/oracle/oradata/dbta/sysaux01.dbf /u01/app/oracle/oradata/dbta/undotbs01.dbf /u01/app/oracle/oradata/dbta/users01.dbf

(9)

43

Informasi control file:

SQL> SELECT name FROM v$controlfile;

NAME

--- /u01/app/oracle/oradata/dbta/control01.ctl

/u01/app/oracle/fast_recovery_area/dbta/control02.ctl

Informasi redo log file:

SQL> SELECT group#, member FROM v$logfile ORDER BY 1;

GROUP# MEMBER

--- --- 1 /u01/app/oracle/oradata/dbta/redo01.log 2 /u01/app/oracle/oradata/dbta/redo02.log 3 /u01/app/oracle/oradata/dbta/redo03.log

Setelah proses pengecekan dan dokumentasi, kemudian lakukan backup database dan control file untuk standby database menggunakan RMAN dengan perintah sebagai berikut:

[oracle@primesvr ~]$ rman target /

RMAN> run 2> {

3> allocate channel c1 DEVICE TYPE DISK FORMAT '/u01/BACKUP/%U';

4> BACKUP DATABASE;

5> BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT '/u01/BACKUP/standbyCTRL.bkp';

6> }

f. Membuat Parameter File (PFILE) dari SPFILE

SQL> CREATE PFILE='/u01/BACKUP/initSTDBYDB.ora' FROM spfile;

File created.

g. Copy file-file backup dan PFILE dari primary server ke standby server

[oracle@primesvr ~]$ cd /u01/BACKUP [oracle@primesvr BACKUP]$ ls -l total 1118172

-rw-r--- 1 oracle oinstall 1134338048 Apr 20 12:11 010rdrqs_1_1

-rw-r--r-- 1 oracle oinstall 1065 Apr 20 12:21 initSTDBYDB.ora

(10)

44

-rw-r--- 1 oracle oinstall 10665984 Apr 20 12:11 standbyCTRL.bkp

[oracle@primesvr BACKUP]$ scp * oracle@stdbysvr:/u01/BACKUP

h. Copy password file dari primary server ke standby server

[oracle@primesvr ~]$ scp $ORACLE_HOME/dbs/orapwdbta oracle@stdbysvr:$ORACLE_HOME/dbs/orapwSTDBYDB

4.4 Startup Database pada Standby Server

Setelah semua file di-backup dan di-copy dari primary server ke standby server, selanjutnya ialah melakukan startup database pada standby server. Namun, sebelumnya periksa dahulu file-file backup yang ditransfer dari primary server.

[oracle@stdbysvr ~]$ ls -l /u01/BACKUP total 1118172

Setelah yakin semua file sudah di-copy, lakukan langkah-langkah berikut ini.

a. Mengedit PFILE sesuaikan fungsi sebagai standby

oracle@stdbysvr ~]$ cp /u01/BACKUP/initSTDBYDB.ora

$ORACLE_HOME/dbs

[oracle@stdbysvr ~]$ ls -l $ORACLE_HOME/dbs total 12

-rw-r--r--. 1 oracle oinstall 3079 May 15 2015 init.ora

-rw-r--r-- 1 oracle oinstall 1065 Apr 20 12:29 initSTDBYDB.ora -rw-r--- 1 oracle oinstall 3584 Apr 20 12:25 orapwSTDBYDB [oracle@stdbysvr ~]$ vi $ORACLE_HOME/dbs/initSTDBYDB.ora -- ganti DB_UNIQUE_NAME='STDBYDB'

*.DB_UNIQUE_NAME='STDBYDB'

-- lengkapnya isi initSTDBYDB.ora dbta. data_transfer_cache_size=0 dbta. db_cache_size=603979776 dbta. inmemory_ext_roarea=0 dbta. inmemory_ext_rwarea=0 dbta. java_pool_size=16777216 dbta. large_pool_size=33554432

dbta. oracle_base='/u01/app/oracle'#ORACLE_BASE set from environment

dbta. pga_aggregate_target=637534208

(11)

45

dbta. sga_target=922746880

dbta. shared_io_pool_size=50331648 dbta. shared_pool_size=201326592 dbta. streams_pool_size=0

*.audit_file_dest='/u01/app/oracle/admin/dbta/adump'

*.audit_trail='db'

*.compatible='12.2.0'

*.control_files='/u01/app/oracle/oradata/dbta/control01.ctl','/u 01/app/oracle/fast_recovery_area/dbta/control02.ctl'

*.db_block_size=8192

*.db_name='dbta'

*.db_unique_name='STDBYDB'

*.db_recovery_file_dest='/u01/app/oracle/fast_recovery_area/dbta '

*.db_recovery_file_dest_size=8016m

*.diagnostic_dest='/u01/app/oracle'

*.dispatchers='(PROTOCOL=TCP) (SERVICE=dbtaXDB)'

*.local_listener='LISTENER_DBTA'

*.memory_target=1476m

*.nls_language='AMERICAN'

*.nls_territory='AMERICA'

*.open_cursors=300

b. Membuat direktori yang diperlukan untuk file-file audit dan control file sesuai

dengan nilai parameter audit_file_dest dan control_files

*.audit_file_dest

*.control_files

[oracle@stdbysvr ~]$ mkdir -p /u01/app/oracle/admin/dbta/adump [oracle@stdbysvr ~]$ mkdir -p /u01/app/oracle/oradata/dbta [oracle@stdbysvr ~]$ mkdir -p

/u01/app/oracle/fast_recovery_area/dbta

c. Menjalankan instance dalam mode nomount di standby server. Pada langkah ini sesuaikan environment variable ORACLE_SID dengan parameter DB_UNIQUE_NAME(STDBYDB)

[oracle@stdbysvr ~]$ export ORACLE_SID=STDBYDB [oracle@stdbysvr ~]$ sqlplus / as sysdba

SQL*Plus: Release 12.2.0.1.0 Production on Wed Apr 20 12:36:07 2022

Connected to an idle instance.

SQL> STARTUP NOMOUNT;

(12)

46

Variable Size 1006633952 bytes Database Buffers 536870912 bytes Redo Buffers 8155136 bytes SQL>

Kemudian periksa status instance.

INSTANCE_NAME STATUS --- --- STDBYDB STARTED

Setelah itu periksa service instance apakah sudah jalan atau belum.

[oracle@stdbysvr ~]$ ps -ef|grep pmon

oracle 9548 1 0 12:36 ? 00:00:00 ora_pmon_STDBYDB oracle 9738 9666 0 12:37 pts/1 00:00:00 grep --

color=auto pmon

d. Restore control file dan mount database di standby server

[oracle@stdbysvr ~]$ ls -l /u01/BACKUP total 1128588

[oracle@stdbysvr ~]$ export ORACLE_SID=STDBYDB [oracle@stdbysvr ~]$ rman target /

Recovery Manager: Release 12.2.0.1.0 - Production on Wed Apr 20 12:45:41 2022

connected to target database: DBTA (not mounted)

RMAN> RESTORE CONTROLFILE FROM '/u01/BACKUP/standbyCTRL.bkp';

Starting restore at 20-APR-2022 12:46:21

using target database control file instead of recovery catalog allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=34 device type=DISK channel ORA_DISK_1: restoring control file

channel ORA_DISK_1: restore complete, elapsed time: 00:00:01 output file name=/u01/app/oracle/oradata/dbta/control01.ctl output file

name=/u01/app/oracle/fast_recovery_area/dbta/control02.ctl Finished restore at 20-APR-2022 12:46:23

(13)

47

Jalankan database dalam mode mount.

SQL> ALTER DATABASE MOUNT;

Lalu periksa status instance saat ini.

INSTANCE_NAME STATUS --- --- STDBYDB MOUNTED

Terakhir, lihat control file type-nya.

SQL> SELECT name, controlfile_type FROM v$database;

NAME CONTROL --- --- DBTA STANDBY

e. Restore data file di standby server

RMAN> RESTORE DATABASE;

Starting restore at 20-APR-2022 12:51:49 released channel: ORA_DISK_1

Starting implicit crosscheck backup at 20-APR-2022 12:51:49 allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=34 device type=DISK Crosschecked 1 objects

Finished implicit crosscheck backup at 20-APR-2022 12:51:49 Starting implicit crosscheck copy at 20-APR-2022 12:51:49 using channel ORA_DISK_1

Finished implicit crosscheck copy at 20-APR-2022 12:51:49 searching for all files in the recovery area

cataloging files...

no files cataloged using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00001 to /u01/app/oracle/oradata/dbta/system01.dbf channel ORA_DISK_1: restoring datafile 00003 to /u01/app/oracle/oradata/dbta/sysaux01.dbf channel ORA_DISK_1: restoring datafile 00004 to /u01/app/oracle/oradata/dbta/undotbs01.dbf

(14)

48

channel ORA_DISK_1: restoring datafile 00007 to /u01/app/oracle/oradata/dbta/users01.dbf

channel ORA_DISK_1: reading from backup piece /u01/BACKUP/010rdrqs_1_1

channel ORA_DISK_1: piece handle=/u01/BACKUP/010rdrqs_1_1 tag=TAG20220420T121108

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:35 Finished restore at 20-APR-2022 12:52:25

Sampai tahap ini, database di standby server siap dikonfigurasi menjadi standby database sebagai cadangan dari database yang ada di primary server.

digunakan untuk melakukan konfigurasi data guard.

4.5 Konfigurasi Data Guard

Tahapan dalam konfigurasi data guard adalah sebagai berikut:

a. Edit LISTENER.ORA dan TNSNAMES.ORA di kedua server dan tes koneksi antar database.

Proses ini untuk memastikan konektivitas antara database yang ada di primary server dengan database yang ada di standby server. Agar bisa dikoneksi dari server lain maka database harus didaftarkan di file LISTENER.ORA. Sementara itu untuk melakukan koneksi ke suatu database maka nama alias database harus didaftarkan di file TNSNAMES.ORA Primary server:

Pertama, edit file LISTENER.ORA.

[oracle@primesvr ~]$ vi $ORACLE_HOME/network/admin/listener.ora

Tambahkan PRIMEDB pada bagian SID_LIST_LISTENER. Hal ini dilakukan agar service database PRIMEDB bisa diakses dari standby server.

# listener.ora Network Configuration File:

/u01/app/oracle/product/12.2.0/db_home/network/admin/listener.or a

# Generated by Oracle configuration tools.

LISTENER =

(DESCRIPTION_LIST = (DESCRIPTION =

(15)

49

(ADDRESS = (PROTOCOL = TCP)(HOST = primesvr.mjm.com)(PORT

= 1521))

(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521)) )

)

SID_LIST_LISTENER = (SID_LIST =

(SID_DESC =

(ORACLE_HOME = /u01/app/oracle/product/12.2.0/db_home) (SID_NAME = PRIMEDB)

) )

Selanjutnya, edit file TNSNAMES.ORA.

[oracle@primesvr ~]$ vi $ORACLE_HOME/network/admin/tnsnames.ora

Tambahkan service alias TO_STDBYDB yang mengarahkan koneksi ke database STDBYDB.

TO_STDBYDB = (DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = stdbysvr.mjm.com)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED) (SERVICE_NAME = STDBYDB) )

)

Standby server:

Pertama, pada standby server edit file LISTENER.ORA.

[oracle@stdbysvr ~]$ vi $ORACLE_HOME/network/admin/listener.ora

Tambahkan STDBYDB pada bagian SID_LIST_LISTENER agar service database STDBYDB bisa diakses dari primary server.

# listener.ora Network Configuration File:

LISTENER =

(DESCRIPTION_LIST = (DESCRIPTION =

(16)

50

(ADDRESS = (PROTOCOL = TCP)(HOST = stdbysvr.mjm.com)(PORT

= 1521))

(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521)) )

)

SID_LIST_LISTENER = (SID_LIST =

(SID_DESC =

(ORACLE_HOME = /u01/app/oracle/product/12.2.0/db_home) (SID_NAME = STDBYDB)

) )

Kemudian, edit file TNSNAMES.ORA.

[oracle@stdbysvr ~]$ vi $ORACLE_HOME/network/admin/tnsnames.ora

Terakhir, tambahkan service alias TO_PRIMEDB yang mengarahkan koneksi ke database PRIMEDB.

# tnsnames.ora Network Configuration File:

#

/u01/app/oracle/product/12.2.0/db_home/network/admin/tnsnames.or a

TO_PRIMEDB = (DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = primesvr.mjm.com)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED) (SERVICE_NAME = PRIMEDB) )

)

b. Jalankan LISTENER di kedua server dan tes koneksi antar database dengan TNSPING.

Primary server:

[oracle@primesvr ~]$ lsnrctl start LISTENER

LSNRCTL for Linux: Version 12.2.0.1.0 - Production on 20-APR- 2022 13:02:34

Starting /u01/app/oracle/product/12.2.0/db_home/bin/tnslsnr:

please wait...

(17)

51

TNSLSNR for Linux: Version 12.2.0.1.0 - Production System parameter file is

Log messages written to

/u01/app/oracle/diag/tnslsnr/primesvr/listener/alert/log.xml Listening on:

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=primesvr.mjm.com)(PORT

=1521))) Listening on:

(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521))) Connecting to

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=primesvr.mjm.com)(PORT

=1521)))

STATUS of the LISTENER ---

Alias LISTENER

Version TNSLSNR for Linux: Version 12.2.0.1.0 - Production

Start Date 20-APR-2022 13:02:36 Uptime 0 days 0 hr. 0 min. 1 sec

Trace Level off

Security ON: Local OS Authentication

SNMP OFF

Listener Parameter File

Listener Log File

/u01/app/oracle/diag/tnslsnr/primesvr/listener/alert/log.xml Listening Endpoints Summary...

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=primesvr.mjm.com)(PORT

=1521)))

(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521))) Services Summary...

Service "PRIMEDB" has 1 instance(s).

Instance "PRIMEDB", status UNKNOWN, has 1 handler(s) for this service...

The command completed successfully

Standby server:

[oracle@stdbysvr ~]$ lsnrctl start LISTENER

LSNRCTL for Linux: Version 12.2.0.1.0 - Production on 20-APR- 2022 13:04:11

Starting /u01/app/oracle/product/12.2.0/db_home/bin/tnslsnr:

please wait...

(18)

52

TNSLSNR for Linux: Version 12.2.0.1.0 - Production System parameter file is

Log messages written to

/u01/app/oracle/diag/tnslsnr/stdbysvr/listener/alert/log.xml Listening on:

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=stdbysvr.mjm.com)(PORT

=1521))) Listening on:

(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521))) Connecting to

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=stdbysvr.mjm.com)(PORT

=1521)))

STATUS of the LISTENER ---

Alias LISTENER

Version TNSLSNR for Linux: Version 12.2.0.1.0 - Production

Start Date 20-APR-2022 13:04:13 Uptime 0 days 0 hr. 0 min. 0 sec

Trace Level off

Security ON: Local OS Authentication

SNMP OFF

Listener Parameter File

Listener Log File

/u01/app/oracle/diag/tnslsnr/stdbysvr/listener/alert/log.xml Listening Endpoints Summary...

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=stdbysvr.mjm.com)(PORT

=1521)))

(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521))) Services Summary...

Service "STDBYDB" has 1 instance(s).

Instance "STDBYDB", status UNKNOWN, has 1 handler(s) for this service...

The command completed successfully

LISTENER sudah dijalankan di kedua server, kemudian tes koneksi.

Primary server:

[oracle@primesvr ~]$ tnsping TO_STDBYDB

TNS Ping Utility for Linux: Version 12.2.0.1.0 - Production on 20-APR-2022 13:05:42

Used parameter files:

(19)

53

Used TNSNAMES adapter to resolve the alias

Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = stdbysvr.mjm.com)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = STDBYDB)))

OK (0 msec)

Standby server:

[oracle@stdbysvr ~]$ tnsping TO_PRIMEDB

TNS Ping Utility for Linux: Version 12.2.0.1.0 - Production on 20-APR-2022 13:05:06

Used parameter files:

Used TNSNAMES adapter to resolve the alias

Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = primesvr.mjm.com)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = PRIMEDB)))

OK (10 msec)

Shutdown standby database.

c. Buat standby log file di primary database

Standby log file atau standby redo log file adalah file yang digunakan untuk menyimpan data redo yang diterima dari database lain atau sumber data utama

^[29]

. Di uji coba kali ini, buat standby log file di primary database dengan ukuran file disesuaikan dengan ukuran redo log file yang sudah ada.

Pertama periksa dahulu ukuran redo log file dan cek lokasi redo log file berada.

SQL> SELECT group#, bytes/1024/1024 as "Size MB" FROM v$log ORDER BY 1;

GROUP# Size MB --- ---

1 200

2 200

3 200

SQL> SELECT group#, member FROM v$logfile ORDER BY 1;

(20)

54

GROUP# MEMBER

--- --- 1 /u01/app/oracle/oradata/dbta/redo01.log 2 /u01/app/oracle/oradata/dbta/redo02.log 3 /u01/app/oracle/oradata/dbta/redo03.log

Lalu, buat standby log file sebanyak tiga group.

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 4

'/u01/app/oracle/oradata/dbta/standby_redo01.log' SIZE 200M;

SQL> SELECT group#, sequence#, archived, status FROM v$standby_log;

GROUP# SEQUENCE# ARC STATUS --- --- --- ---

4 0 YES UNASSIGNED 5 0 YES UNASSIGNED 6 0 YES UNASSIGNED

d. Edit parameter database yang berkaitan dengan data guard di primary database

SQL> ALTER SYSTEM SET db_unique_name='PRIMEDB' SCOPE=SPFILE;

System altered.

SQL> ALTER SYSTEM SET

log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES, ALL_ROLES) db_unique_name=PRIMEDB';

System altered.

SQL> ALTER SYSTEM SET log_archive_dest_2='SERVICE=TO_STDBYDB ARCH ASYNC NOAFFIRM VALID_FOR=(ALL_LOGFILES, ALL_ROLES) db_unique_name=STDBYDB';

System altered.

SQL> ALTER SYSTEM SET log_archive_dest_state_1=ENABLE;

System altered.

(21)

55

SQL> ALTER SYSTEM SET log_archive_dest_state_2=ENABLE;

System altered.

SQL> ALTER SYSTEM SET

log_archive_config='DG_CONFIG=(STDBYDB,PRIMEDB)';

System altered.

SQL> ALTER SYSTEM SET fal_server=TO_STDBYDB;

System altered.

SQL> ALTER SYSTEM SET standby_file_management=AUTO;

System altered.

SQL> ALTER SYSTEM SET log_file_name_convert='dummy','dummy' SCOPE=SPFILE;

System altered.

e. Edit file parameter database di standby database

[oracle@stdbysvr ~]$ vi $ORACLE_HOME/dbs/initSTDBYDB.ora

Tambahkan parameter-parameter yang berhubungan dengan data guard.

##### Parameter Dataguard #####

log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES, ALL_ROLES) db_unique_name=STDBYDB' log_archive_dest_2='SERVICE=TO_PRIMEDB ARCH ASYNC NOAFFIRM VALID_FOR=(ALL_LOGFILES, ALL_ROLES) db_unique_name=PRIMEDB' log_file_name_convert='dummy','dummy'

log_archive_dest_state_1=ENABLE log_archive_dest_state_2=DEFER

log_archive_config='DG_CONFIG=(PRIMEDB,STDBYDB)' fal_server=TO_PRIMEDB

standby_file_management=AUTO

f. Lakukan startup pada standby database

[oracle@stdbysvr ~]$ export ORACLE_SID=STDBYDB [oracle@stdbysvr ~]$ sqlplus / as sysdba

Variable Size 1006633952 bytes Database Buffers 536870912 bytes

(22)

56

Redo Buffers 8155136 bytes Database mounted.

Periksa protection mode dan database role.

SQL> SELECT open_mode, protection_mode, database_role FROM v$database;

OPEN_MODE PROTECTION_MODE DATABASE_ROLE --- --- --- MOUNTED MAXIMUM PERFORMANCE PHYSICAL STANDBY

g. Melakukan simulasi generate archive log di primary database

Primary database:

SQL> ALTER SYSTEM SWITCH LOGFILE;

System altered.

SQL> ARCHIVE LOG LIST;

Database log mode Archive Mode Automatic archival Enabled

Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 3

Next log sequence to archive 5 Current log sequence 5

Standby database:

SQL> ARCHIVE LOG LIST;

Database log mode Archive Mode Automatic archival Enabled

Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 1

Next log sequence to archive 2 Current log sequence 2

(23)

57

Proses yang berjalan di standby database.

SQL> SELECT process, status, sequence# FROM v$managed_standby;

PROCESS STATUS SEQUENCE#

--- --- ---

ARCH CONNECTED 0

DGRD ALLOCATED 0

RFS IDLE 0

10 rows selected.

Lihat archive log yang sudah diproses (applied).

SQL> SELECT max(sequence#) FROM v$archived_log WHERE applied='YES';

MAX(SEQUENCE#) ---

Sampai saat ini auto recovery belum diaktifkan dan belum ada archive log yang di-applied. Hal ini bisa dilihat dari hasil yang ditampilkan pada max(sequence#) yang masih kosong.

h. Aktifkan proses RFS

RFS atau Remote File Server adalah proses yang menerima data redo dari primary database ke standby database baik dalam bentuk archived redo log atau standby redo log

^[30]

.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

MAX(SEQUENCE#) --- 5

(24)

58

Setelah RFS diaktifkan, hasil yang ditampilkan pada max(sequence#) adalah 5, ini artinya file archive yang sudah diproses adalah sampai dengan file archive log dengan nomor sequence 5. Berikut ini detailnya.

SQL> SELECT sequence#, first_time, next_time, applied FROM v$archived_log ORDER BY sequence#;

SEQUENCE# FIRST_TIM NEXT_TIME APPLIED --- --- --- ---

2 20-APR-22 20-APR-22 YES 3 20-APR-22 20-APR-22 YES 4 20-APR-22 20-APR-22 YES 5 20-APR-22 20-APR-22 YES

Di primary database lakukan lagi switch log file agar terbentuk archive log file dengan nomor sequence 6.

Primary database:

System altered.

i. Monitoring Data Guard

Saat memantau data guard, kita perlu melihat alert log file apakah ada error atau tidak. Berikut ini hasil yang ditampilkan dari alert log file.

[oracle@stdbysvr ~] $ tail -100f

/u01/app/oracle/diag/rdbms/stdbydb/STDBYDB/trace/alert_STDBYDB.l og

Additional information: 7

2022-04-20T13:52:16.261984+07:00

Clearing online redo logfile 3 complete

Sleep 5 seconds and try to clear ORLs in 2 time(s) 2022-04-20T13:52:21.261894+07:00

Waiting for all non-current ORLs to be archived 2022-04-20T13:52:21.261953+07:00

All non-current ORLs have been archived 2022-04-20T13:53:25.351345+07:00

RFS[1]: Assigned to RFS process (PID:14824)

RFS[1]: Opened log for T-1.S-6 dbid 345805157 branch 1101822119 2022-04-20T13:53:25.356978+07:00

Archived Log entry 5 added for thread 1 sequence 6 rlc 1101822119 ID 0x149c2865 LAD2 :

2022-04-20T13:53:25.974477+07:00 Media Recovery Log

/u01/app/oracle/fast_recovery_area/dbta/STDBYDB/archivelog/2022_

04_20/o1_mf_1_6_k5zch5bx_.arc

Media Recovery Waiting for thread 1 sequence 7

(25)

59

Dari hasil alert log file di atas menunjukkan bahwa media recovery sedang menunggu archive log file ke 7.

Detailnya bisa diperiksa dengan query berikut.

SQL> COL message FOR A60 SQL> COL TIMESTAMP FOR A25 SQL> SET LINESIZE 100

SQL> SELECT to_char(timestamp,'RRRR/MM/DD:HH24:MI:SS') as TIMESSTAMP,

2 message FROM v$dataguard_status 3 ORDER BY 1;

TIMESSTAMP MESSAGE

--- --- 2022/04/20:13:51:34 Network throttle feature is disabled as mount

time

2022/04/20:13:51:34 ARC0: Archival started

2022/04/20:13:51:34 ARC0: Becoming a 'no FAL' ARCH

2022/04/20:13:51:34 TT00: Gap Manager starting (PID:14694) 2022/04/20:13:51:34 ARC1: Archival started

2022/04/20:13:51:34 Archiving previously deferred ORLs 2022/04/20:13:51:34 ARC2: Archival started

2022/04/20:13:51:34 ARC3: Archival started

2022/04/20:13:51:59 Attempt to start background Managed Standby Recovery process

2022/04/20:13:51:59 MRP0: Background Managed Standby Recovery process started

2022/04/20:13:52:04 Managed Standby Recovery not using Real Time Apply

TIMESSTAMP MESSAGE

--- --- 2022/04/20:13:52:04 Clearing online redo logfile 1

/u01/app/oracle/oradata/dbta/redo01.log

2022/04/20:13:52:04 Media Recovery Waiting for thread 1 sequence 6 2022/04/20:13:52:08 Clearing online redo logfile 1 complete

2022/04/20:13:52:08 Clearing online redo logfile 2

/u01/app/oracle/oradata/dbta/redo02.log 2022/04/20:13:52:12 Clearing online redo logfile 2 complete 2022/04/20:13:52:12 Clearing online redo logfile 3

/u01/app/oracle/oradata/dbta/redo03.log TIMESSTAMP MESSAGE

--- --- 2022/04/20:13:52:16 Clearing online redo logfile 3 complete

2022/04/20:13:53:25 Media Recovery Log

/u01/app/oracle/fast_recovery_area/dbta/

STDBYDB/archivelog/2022_04_20/

o1_mf_1_6_k5zch5bx_.arc

2022/04/20:13:53:25 RFS[1]: Assigned to RFS process (PID:14824) 2022/04/20:13:53:26 Media Recovery Waiting for thread 1 sequence 7 21 rows selected.

(26)

60

Lihat archive log yang sudah diproses (applied).

MAX(SEQUENCE#) --- 6

SQL> SELECT sequence#, first_time, next_time, applied FROM v$archived_log ORDER BY sequence#;

SEQUENCE# FIRST_TIM NEXT_TIME APPLIED --- --- --- ---

2 20-APR-22 20-APR-22 YES 3 20-APR-22 20-APR-22 YES 4 20-APR-22 20-APR-22 YES 5 20-APR-22 20-APR-22 YES 6 20-APR-22 20-APR-22 YES

--- --- ---

RFS IDLE 0

MRP0 WAIT_FOR_LOG 7

4.6 Konversi Physical Standby Database ke Active Data Guard

Sesudah melakukan konfigurasi data guard, berikutnya melakukan konversi physical standby database ke active data guard. Maksud dari active data guard adalah mengubah kondisi standby database dalam mode open read only.

Manfaat menggunakan active data guard adalah kita bisa melakukan query

ke standby database, hal ini diperlukan untuk mengurangi akses ke primary

database khususnya untuk proses pembuatan laporan.

(27)

61

Untuk mengonversikan physical standby database ke active data guard, tahapan yang harus dilakukan adalah:

a. Enable-kan active data guard

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

SQL> SELECT name, open_mode, database_role FROM v$database;

NAME OPEN_MODE DATABASE_ROLE --- --- --- DBTA READ ONLY PHYSICAL STANDBY

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

b. Verifikasi MRP yang berjalan sebagai background process

Managed Recovery Process (MRP) adalah proses yang akan memelihara dan menerapkan informasi archive log ke standby database

^[31]

.

--- --- ---

RFS IDLE 0

c. Tes active data guard

Untuk tes active data guard kita perlu membuat tabel dan insert data di primary database.

Primary database:

(28)

62

SQL> CREATE TABLE matakuliah (

2 kode VARCHAR2(4) PRIMARY KEY, 3 nama_mk VARCHAR2(20) NOT NULL, 4 sks NUMBER(3))

5 TABLESPACE users;

Table created.

SQL> INSERT INTO matakuliah VALUES('1011','Database 1',3);

1 row created.

SQL> COMMIT;

Commit complete.

System altered.

Standby database:

SQL> SELECT * FROM matakuliah;

KODE NAMA_MK SKS

---- --- ---

1011 Database 1 3

Dari sini terlihat bahwa transaksi yang terjadi di primary database otomatis akan dikirim ke standby database.

d. Mengembalikan ke physical standby database

(29)

63

SQL> SELECT name, open_mode, database_role FROM v$database;

NAME OPEN_MODE DATABASE_ROLE --- --- --- DBTA MOUNTED PHYSICAL STANDBY

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

--- --- ---

RFS IDLE 0

4.7 Melakukan Simulasi Failover

Bagian terakhir, kita akan melakukan simulasi failover di mana hal ini difungsikan untuk menguji apakah standby database bisa me-recovery dan menggantikan perannya sebagai primary database ketika primary database mengalami kegagalan atau tidak. Untuk pengujiannya dilakukan dengan cara berikut.

a. Crash-kan primary server

Dalam hal ini primary server di shutdown saja. Sebelum di-crash-kan lakukan insert beberapa data ke tabel MATAKULIAH. Nanti dilakukan pengecekan apakah data baru yang di-insert di primary database bisa di- recovery di standby database.

SQL> INSERT INTO matakuliah VALUES('1021','Database 2',3);

1 row created.

SQL> INSERT INTO matakuliah VALUES('1001','Pemrograman 1',3);

1 row created.

(30)

64

SQL> COMMIT;

Commit complete.

System altered.

Kemudian shutdown pada server PRIMESVR.

# shutdown -h now

b. Lakukan pengecekan gap pada redo log file antara primary database dan standby database

Standby database:

SQL> SELECT thread#, low_sequence#, high_sequence# FROM v$archive_gap;

no rows selected

Dari hasil pengecekan ternyata tidak ada gap archive log file. Sehingga standby database bisa langsung diaktifkan sebagai primary database.

Jika dari hasil pengecekan ada gap archive log file, maka sebelum standby database diaktifkan sebagai primary database, archive log file-archive log file yang ada di primary database tetapi tidak ada di standby database harus di-copy ke standby server dan diregister pada standby database. Hal ini dilakukan untuk meminimalkan data yang hilang.

Untuk copy dan register archive log file ke standby database ada dua kemungkinan, yaitu:

1. Jika primary database bisa di-startup mount lakukan flash log ke standby database. Di primary database lakukan perintah berikut:

SQL> STARTUP MOUNT

SQL> ALTER SYSTEM FLUSH REDO TO 'stdbydb';

(31)

65

2. Jika primary database tidak bisa di-startup mount tetapi primary

server masih up, copy archive log gap (sisanya) ke standby server, kemudian di standby server lakukan perintah berikut:

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE '&logfile_path';

c. Lakukan proses failover, yaitu konfigurasi standby server menjadi primary server

Standby database:

Sebelum melakukan proses failover, aktifkan pencatatan waktu proses query di SQL*Plus dengan perintah SET TIMING ON.

SQL> SET TIMING ON

Elapsed: 00:00:00.32

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

Elapsed: 00:00:00.45

Harus dilihat apakah status switchover yang muncul TO PRIMARY atau SESSIONS ACTIVE.

SQL> SELECT switchover_status FROM v$database;

SWITCHOVER_STATUS --- TO PRIMARY

Elapsed: 00:00:00.30

Hasilnya status yang muncul sudah berubah ke TO PRIMARY. Kemudian

lakukan switchover dari standby database ke primary database.

(32)

66

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

Elapsed: 00:00:03.49

Elapsed: 00:00:13.26

Periksa database role.

SQL> SELECT name, open_mode, db_unique_name, database_role FROM v$database;

NAME OPEN_MODE DB_UNIQUE_NAME DATABASE_ROLE --- --- --- --- DBTA READ WRITE STDBYDB PRIMARY

Dari hasil query, database sudah berperan sebagai primary. Recovery Time Objective (RTO) atau total waktu yang diperlukan untuk mengaktifkan standby database menjadi primary database adalah 00:00:17:82 (tujuh belas koma delapan puluh dua detik). Hal ini diperoleh dengan menjumlahkan elapsed time query-query yang dilakukan untuk konfigurasi failover seperti di bawah ini:

Elapsed: 00:00:00.32 Elapsed: 00:00:00.45 Elapsed: 00:00:00.30 Elapsed: 00:00:03.49 Elapsed: 00:00:13.26 --- +

00:00:17.82

(33)

67

Selanjutnya untuk verifikasi apakah data yang di-insert ke tabel MATAKULIAH di primary database bisa di-recovery di standby database?

SQL> SELECT * FROM matakuliah;

KODE NAMA_MK SKS

---- --- ---

1011 Database 1 3

1021 Database 2 3

1001 Pemrograman 1 3

Hasilnya data yang di-insert di primary database bisa di recovery di standby database dan standby database bisa mengubah perannya menjadi primary database ketika primary database mengalami kegagalan. Hal ini berarti menunjukkan Recovery Point Objective (RPO) sangat tinggi, artinya selama semua archive log bisa terkirim dari primary database ke standby database maka fitur Oracle Data Guard bisa melakukan recovery sampai ke transaksi terakhir.