BAB 4 RANCANGAN SISTEM HIGH AVAILABILITY YANG …thesis.binus.ac.id/Asli/Bab4/2009-1-00220-IF bab...

135

BAB 4

RANCANGAN SISTEM HIGH AVAILABILITY YANG DIUSULKAN

4.1 Sistem yang Diusulkan

Perancangan sistem high availability dengan Oracle Data Guard dilakukan

dalam beberapa tahap. Adapun tahapan-tahapan tersebut adalah :

a. Mempelajari latar belakang dan tujuan perusahaan.

Dilakukan untuk mengetahui faktor apa saja yang dapat mempengaruhi

keberhasilan perusahaan dan kebutuhan informasi untuk pihak manajemen.

b. Menganalisis proses bisnis.

Dilakukan untuk mengetahui alur bisnis yang terjadi di perusahaan, dan

mengetahui aktor-aktor bisnis yang terlibat dalam proses bisnis perusahaan.

c. Menganalisis teknologi informasi perusahaan.

Di dalam menganalisis teknologi informasi perusahaan, maka bisa didapat

arsitektur data center yang digunakan perusahaan dimana akan menentukan

arsitektur yang dirancang untuk pengimplementasian Data Guard. Selain itu juga

dilakukan analisis terhadap sistem availabilty yang sedang berjalan. Dengan

mengetahui sistem availability yang dilakukan perusahaan, dapat diketahui

sejauh mana perusahaan dapat menangani gangguan yang mungkin terjadi pada

data center, khususnya pada database server dan storage server.

d. Menganalisis masalah yang terjadi pada database server dan storage server

beserta dampaknya.

Hasil dari analisis permasalahan dan dampak, selanjutnya dapat digunakan untuk

mengangkat isu pentingnya sistem high availability. Apabila dibandingkan

136

dengan analisis sistem availability yang sedang berjalan, maka perusahaan dapat

mengetahui bahwa ada kemungkinan masalah dengan dampak besar yang belum

dapat ditangani sistem availability yang sedang berjalan.

e. Menganalisis dampak bisnis.

Berdasarkan analisis masalah dan setelah itu dilakukan analisis untuk

menentukan dampak yang terjadi pada proses bisnis.

f. Menganalisis kerugian pendapatan akibat system down.

Kerugian pendapatan bekerjasama dapat diperhitungkan dengan menganailsis

nilai transaksi yang terhambat ketika terjadi gangguan sistem.

g. Menganalisis RTO dan RPO.

Hasil yang dapat diperoleh dari analisis RTO dan RPO, akan menjadi landasan

pengajuan rancangan sistem Data Guard.

h. Merancang arsitektur logikal Disaster Recovery Center (DRC) sebagai tempat

dari standby database.

Arsitektur DRC disesuaikan dengan data center pusat, dan ditempatkan di lokasi

yang terpisah, yang dihubungkan dengan jaringan WAN.

i. Melakukan konfigurasi Data Guard pada primary database dan standby

database.

Meng-konfigurasi Oracle Data Guard dengan disesuaikan dengan kebutuhan

perusahaan.

137

4.2 Arsitektur Logikal Disaster Recovery Center

Perancangan arsitektur DRC dimulai dengan melihat arsitektur data center utama

perusahaan, dimana arsitektur DRC akan menggunakan arsitektur yang sama dengan

data center utama. Antara data center utama dan DRC sendiri terhubung secara logikal

seperti gambar berikut.

Gambar 4.1 Arsitektur Logikal Disaster Recovery Center

138

Kantor-kantor cabang terhubung dengan data center utama melalui jaringan

WAN yang disediakan oleh Telkom dan XL. Dalam keadaan normal, 2 jaringan ini

berperan sebagai load balancer dan apabila terjadi gangguan pada salah satu jaringan,

maka seluruh arus informasi dan komunikasi akan ditangani oleh jaringan yang tidak

bermasalah. Dari cloud provider, jaringan Telkom dan XL masuk ke router di data

center utama, dan untuk jaringan yang masuk ke router DRC, sementara ini perusahaan

baru menghubungkan provider XL secara standby. Sinkronisasi database antara data

center utama dan DRC dilakukan melalui koneksi antar router yang dihubungkan oleh

leased line MetroNet dengan bandwidth 10 Mbps.

Apabila sewaktu-waktu terjadi gangguan pada data center utama, yang

mengakibatkan kantor cabang tidak dapat mengakses data center utama, maka jaringan

standby dari cloud provider XL ke DRC akan diaktifkan dan Data Guard akan

mengubah peran standby database pada DRC menjadi primary database. Selanjutnya

koneksi dari kantor cabang ke data center utama akan dialihkan menuju DRC. Dengan

demikian kantor cabang tetap dapat beroperasi dengan menggunakan standby database.

PT Anugrah Argon Medica telah merencanakan untuk mendirikan DRC di Cikarang,

tepatnya di lokasi yang sama dengan salah satu pabrik Dexa Group, PT Pheron.

4.3 Kebutuhan Perangkat Keras dan Perangkat Lunak

Data Guard membutuhkan arsitektur sistem operasi yang sama antara sistem

pada primary database dan sistem pada standby database. Dan versi Oracle Database

Enterprise Edition pada sistem utama dan sistem standby juga harus sama. Oleh karena

itu, kebutuhan perangkat keras dan perangkat lunak untuk database server dan storage

server pada DRC PT Anugrah Argon Medica adalah sebagai berikut :

139

a. Perangkat Keras

• Database server menggunakan perangkat keras :

o IBM P570

o 6 buah prosesor Dual Core masing-masing 1 GigaHertz

o 24 GigaByte RAM (Random Access Memory).

• Storage server menggunakan perangkat keras :

o EMC CX700 dengan kapasitas total RAW 7 TeraByte

b. Perangkat Lunak

Database server menggunakan perangkat lunak :

o Sistem Operasi : IBM AIX 5.3

o Versi Database : Oracle 10.2.0.1.0

Meskipun saat ini PT Anugrah Argon Medica masih menggunakan versi

database Oracle 9.2.0.7, namun PT Anugrah Argon Medica berencana untuk

meng-upgrade versi menjadi Oracle 10g.

4.4 Kebutuhan Perangkat Keras dan Perangkat Lunak Prototipe

Sebagai prototipe, penulis hanya menggunakan perangkat sederhana, berupa

sebuah komputer yang berperan sebagai primary database dan sebuah komputer yang

berperan sebagai standby database dengan spesifikasi perangkat keras dan lunak sebagai

berikut :

140

a. Perangkat Keras

Database server menggunakan perangkat keras :

o Mainboard Biostar TA690G AM2

o Prosesor AMD Athlon 64 X2 Dual Core 4200+

o 2 GigaByte RAM

o Hardisk 40 GigaByte

b. Perangkat Lunak

Database server menggunakan perangkat lunak :

o Sistem Operasi : Windows XP service pack 2

o Versi Database : Oracle 10.2.0.1.0

4.5 Konfigurasi Data Guard

Konfigurasi Data Guard terdiri dari satu primary database dan satu atau lebih

standby database. Pada konfigurasi Data Guard, database-database tersebut terhubung

dengan Oracle Net dan dapat saja terpisah secara geografis. PT Anugrah Argon Medica

berencana akan menempatkan standby database di daerah Cikarang. Primary database

dan standby database dapat diatur dengan menggunakan antar muka SQL command

line, dengan menggunakan antar muka Data Guard Broker (DGMGRL) atau dengan

menggunakan Oracle Enterprise Manager.

Sesuai dengan kebutuhan PT Anugrah Argon Medica, maka standby database

yang akan dibuat adalah physical standby database. Ada beberapa faktor yang

melatarbelakangi pemilihan physical standby database sebagai standby database yang

akan digunakan sesuai dengan teori di landasan teori seperti :

141

• PT. Anugrah Argon Medica tidak menggunakan standby database untuk

kegiatan bisnis, melainkan hanya menggunakan standby database untuk

keperluan data protection sehingga standby database tidak perlu diakses oleh

pengguna.

• PT. Anugrah Argon Medica menginginkan agar semua tipe data dan tabel yang

berada dalam objek database dapat didukung oleh standby database.

• PT. Anugrah Argon Medica juga menginginkan adanya integrasi antara Oracle

Application Server yang sedang digunakan dengan standby database yang ada.

• PT. Anugrah Argon Medica menginginkan adanya kinerja akses database yang

tidak terlalu lambat sehingga physical standby dapat menjadi pilihan yang tepat.

4.5.1 Pembuatan Physical Standby Database

Konfigurasi untuk membuat physical standby database dilakukan dengan

langkah-langkah sebagai berikut.

1. Cek persyaratan Data Guard

Persyaratan untuk membuat Data Guard antara lain versi perangkat lunak

Oracle harus sama untuk primary database maupun standby database.

Sistem operasi yang berjalan di lokasi primary database dan standby

database harus sama, namun versi sistem operasi boleh berbeda. Jika

primary database dan standby database berada pada sistem yang sama,

parameter inisialisasi harus diatur dengan benar. Parameter

DB_UNIQUE_NAME harus digunakan dari versi 10g ke atas.

142

2. Aktifkan FORCE LOGGING pada primary database. Ketika primary

database dalam kondisi FORCE LOGGING, Oracle database akan

memaksa penulisan redo log untuk semua perubahan yang terjadi pada

database.

SQL> ALTER DATABASE FORCE LOGGING;

Gambar 4.2 Aktifkan Mode FORCE LOGGING

Untuk memeriksa status FORCE LOGGING dapat menggunakan perintah :

SQL> SELECT FORCE_LOGGING FROM V$DATABASE;

Gambar 4.3 Periksa Mode FORCE LOGGING

3. Periksa password file untuk primary database. Setiap database dalam

konfigurasi Data Guard harus menggunakan password file, dan password

untuk SYS harus identik pada setiap sistem supaya pengiriman redo data

berhasil. Biasanya ada pada direktori [ORACLE_HOME]\database dengan

nama PWD[nama_instance].ora atau bisa diperiksa dengan menggunakan

sintaks :

SQL> SELECT * FROM V$PWFILE_USERS;

143

Gambar 4.4 Periksa Password File

Jika belum ada, buat password file baru dengan menggunakan perintah

berikut ini :

C:\> cd [ORACLE_HOME]\database C:\> orapwd file=PWDorcl.ora password=oracle

force=y

Pada prototipe ini kami menggunakan [ORACLE_HOME] pada direktori

C:\> oracle\product\10.2.0\db_1.

4. Membuat standby redo log, dimana ukuran standby redo log harus sama

dengan ukuran online redo log dari primary database yang digunakan.

Standby redo log digunakan untuk menyimpan redo data yang diterima

dari database lain ketika database penerima redo data berperan sebagai

standby database.

Untuk mengecek ukuran online redo log :

SQL> SELECT GROUP#, BYTES FROM V$LOG;

Gambar 4.5 Cek Ukuran Online Log Files

144

Untuk membuat standby redo log :

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 SIZE 50M;



Gambar 4.6 Membuat Standby Redo Log

Untuk memeriksa hasil pembuatan standby redo log :

SQL> SELECT GROUP#, BYTES FROM V$STANDBY_LOG;

Gambar 4.7 Cek Standby Redo Log

File standby redo log tersebut akan dibuat pada direktori

C:\oracle\product\10.2.0\flash_recovery_area\ORCL\

ONLINELOG.

145

5. Atur initialization parameter / SPFILE pada primary database dengan

parameter yang berhubungan dengan konfigurasi Data Guard sebagai

berikut.

1. DB_NAME='orcl' 2. DB_UNIQUE_NAME='orcl' 3. LOG_ARCHIVE_CONFIG='DG_CONFIG=(orcl,orcl2)' 4. LOG_ARCHIVE_DEST_1='LOCATION=C:\oracle\produc

t\10.2.0\flash_recovery_area\orcl\archivelog VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orcl'

5. LOG_ARCHIVE_DEST_2='SERVICE=orcl2 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl2'

6. LOG_ARCHIVE_DEST_STATE_1='ENABLE' 7. LOG_ARCHIVE_DEST_STATE _2='ENABLE' 8. LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc 9. LOG_ARCHIVE_MAX_PROCESSES=10 10. SERVICE_NAMES='orcl' 11. STANDBY_ARCHIVE_DEST=' LOCATION=

C:\oracle\product\10.2.0\flash_recovery_area\ orcl\archivelog'

12. STANDBY_FILE_MANAGEMENT='AUTO' 13. REMOTE_LOGIN_PASSWORDFILE='EXCLUSIVE' 14. FAL_SERVER=orcl2 15. FAL_CLIENT=orcl 16. DB_FILE_NAME_CONVERT='C:\oracle\product\10.2.

0\oradata\orcl','C:\oracle\product\10.2.0\oradata\orcl2'

17. LOG_FILE_NAME_CONVERT='C:\oracle\product\10.2.0\oradata\orcl','C:\oracle\product\10.2.0\oradata\orcl2’

Deskripsi dari initialization parameter yang digunakan dalam SPFILE

untuk konfigurasi Data Guard untuk primary database adalah sebagai

berikut :

146

No. Nama

parameter Deskripsi

1. DB_NAME Digunakan untuk mengidentifikasi nama primary database

yang bernama ‘orcl’.

2. DB_UNIQUE_N

AME

Digunakan untuk mengidentifikasi nama database ‘orcl’.

3. LOG_ARCHIVE

_CONFIG

Digunakan untuk mengidentifikasi berturut-turut nama

primary (‘orcl’) dan standby database (‘orcl2’) yang

digunakan dalam konfigurasi Data Guard.

4. LOG_ARCHIVE

_DEST_1

Parameter ini hanya berlaku jika menggunakan Oracle

Enterprise Edition. Digunakan untuk mendeskripsikan

tujuan dan atribut dari archived redo log.

Atribut LOCATION digunakan untuk menuliskan alamat

tujuan dari file sistem lokal pada

‘C:\oracle\product\10.2.0\flash_recovery_area\orcl\

archivelog’.

Atribut DB_UNIQUE_NAME digunakan untuk nama

database yang dituju yaitu ‘orcl’.

Atribut VALID_FOR digunakan untuk menggambarkan

pada kondisi apa redo transport service akan dijalankan ke

alamat yang dituju berdasarkan nilainya. Jika nilainya

ALL_LOGFILES maka baik online redo log maupun

standby redo log akan di-archive ke alamat tujuan. Jika

147

nilainya ALL_ROLES maka baik primary maupun standby

database dapat digunakan untuk tujuan.

5. LOG_ARCHIVE

_DEST_2

Sama seperti penjelasan sebelumnya, namun di parameter

ini ada beberapa atribut seperti SERVICE yang digunakan

untuk mendeskripsikan service name dari database tujuan

ke mana redo data akan dikirimkan yang dalam hal ini

adalah standby database ‘orcl2’.

Atribut DB_UNIQUE_NAME digunakan untuk nama

database yang dituju yaitu ‘orcl’.

Atribut LGWR menjelaskan bahwa proses LGWR yang

digunakan untuk mengumpulkan redo data dan

mengirimkannya ke standby database tujuan.

Atribut ASYNC menggambarkan bahwa proses LGWR

akan berjalan secara asynchronous ke tujuan. Atribut

VALID_FOR digunakan untuk menggambarkan pada

kondisi apa redo transport service akan dijalankan ke

alamat yang dituju berdasarkan nilainya. Jika nilainya

ONLINE_LOGFILES itu berarti alamat tujuan hanya

berlaku ketika melakukan archiving pada online redo log.

Jika nilainya PRIMARY_ROLE maka alamat tujuan hanya

berlaku ketika database dijalankan dalam primary role.

148

6. LOG_ARCHIVE

_DEST_STATE

_1

Digunakan untuk menjelaskan kondisi ketersediaan dari

alamat tujuan archive log di primary database ‘orcl’. Jika

nilainya ENABLED maka alamat tujuan ini dapat

digunakan untuk operasi archiving berikutnya baik secara

otomatis maupun manual.

7. LOG_ARCHIVE

_DEST_STATE

_2

Digunakan untuk menjelaskan kondisi ketersediaan dari

alamat tujuan archived log di standby database ‘orcl2’.

Jika nilainya ENABLED maka alamat tujuan ini dapat

digunakan untuk operasi archiving berikutnya baik secara

otomatis maupun manual.

8. LOG_ARCHIVE

_FORMAT

Parameter ini digunakan jika database menggunakan redo

log dalam kondisi ARCHIVELOG untuk mendeskripsikan

format nama dari archived redo log. Nilai %s memberikan

nomor pada log sequence dan %t memberikan nomor pada

thread.

9. LOG_ARCHIVE

_MAX_PROCES

SES

Parameter ini mendeskripsikan jumlah proses ARCH

maksimum yang akan digunakan. Dalam ini sebanyak 10

proses.

10. SERVICE_NAM

ES

Parameter ini berisi nama service yang didukung oleh

Oracle instance. Dalam hal ini ‘orcl’.

149

11. STANDBY_ARC

HIVE_DEST

Parameter ini berisi alamat tujuan standby database ‘orcl2’

untuk menyimpan archived redo log. Dalam hal ini alamat

penempatan dari archived redo log pada standby database

adalah ‘C:\oracle\product\10.2.0\flash_recovery_area\

orcl\archivelog’.

12. STANDBY_FIL

E_MANAGEMEN

T

Parameter ini digunakan untuk menentukan apakah

pengaturan data file berjalan secara manual atau otomatis

diatur oleh sistem. Jika nilainya AUTO maka ketika ada

perubahan data file di primary database, perubahan yang

sama juga akan dilakukan otomatis oleh sistem pada

standby database.

13. REMOTE_LOGI

N_PASSWORDF

ILE

Parameter ini mendeskripsikan apakah Oracle akan

memeriksa password file dan berapa banyak database yang

dapat menggunakan password file tersebut. Jika nilainya

adalah EXCLUSIVE maka password file akan dapat

digunakan hanya oleh sebuah database dan password file

dapat berisi nama selain SYS dan INTERNAL.

14. FAL_SERVER Parameter ini berisi service name dari standby database

yang sedang aktif dalam hal ini ‘orcl2’.

15. FAL_CLIENT Parameter ini berisi service name dari primary database

yang sedang aktif dalam hal ini ‘orcl’.

16. DB_FILE_NAM

E_CONVERT

Parameter ini digunakan untuk menkonversi nama sebuah

data file baru pada primary database ke nama data file

150

pada standby database. Isinya adalah alamat lokasi data file

pada primary database diikuti alamat lokasi data file pada

standby database. Yang dalam hal ini diwakili oleh

‘C:\oracle\product\10.2.0\oradata\orcl',

'C:\oracle\product\10.2.0\oradata\orcl2'.

17. LOG_FILE_NA

ME_CONVERT

Parameter ini digunakan untuk menkonversi nama sebuah

log file baru pada primary database ke nama log file pada

standby database. Isinya adalah alamat lokasi log file pada

primary database diikuti alamat lokasi log file pada

standby database. Yang dalam hal ini diwakili oleh

'C:\oracle\product\10.2.0\oradata\orcl',

'C:\oracle\product\10.2.0\oradata\orcl2'.

Tabel 4.1 Deskripsi Parameter pada Primary Database

Untuk menambahkan parameter tersebut, maka harus terlebih dahulu

membuat PFILE dari SPFILE, dengan sintaks :

SQL> CREATE PFILE=’[ORACLE_HOME]\database\pfileprim.ora’ FROM SPFILE;

Setelah itu, parameter di atas ditambahkan ke dalam PFILE yang telah

dibuat dengan menggunakan Wordpad. Langkah selanjutnya adalah

mengubah SPFILE suatu instance, namun instance harus tidak boleh dalam

keadaan OPEN.

151

SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP NOMOUNT

PFILE=’[ORACLE_HOME\database\pfileprim.ora’;

SQL> CREATE SPFILE FROM PFILE=’[ORACLE_HOME\database\pfileprim.ora’;

SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP;

Untuk memeriksa apakah parameter sudah ter-apply dengan benar, maka

dilakukan query :

SQL> SHOW PARAMETER;

6. Atur primary database dalam kondisi ARCHIVELOG. Saat berada pada

kondisi ARCHIVELOG, Oracle menyalin online redo log yang telah terisi

ke disk. Dengan mode ARCHIVELOG, backup database dapat dilakukan

saat database masih dalam kondisi OPEN dan sedang diakses oleh

pemakai. Untuk memeriksa apakah primary database sudah berada dalam

kondisi ARCHIVELOG atau belum dapat menggunakan sintaks SQL

berikut.

SQL> ARCHIVE LOG LIST;

Gambar 4.8 Archive Log List

152

Jika database belum dalam kondisi ARCHIVELOG, maka dapat dilakukan

perubahan kondisi database ke dalam kondis i ARCHIVELOG dengan

sintaks SQL berikut.

SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; SQL> ALTER DATABASE ARCHIVELOG; SQL> ALTER DATABASE OPEN;

Gambar 4.9 Enable ARCHIVELOG

7. Buat standby control file dari control file yang dimiliki primary database.

Standby control file akan digunakan oleh standby database untuk

mengidentifikasi datafile dan redo log file yang harus dibuka untuk operasi

database.

SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS‘C:\oracle\product\10.2.0\oradata\ sbycontrol.ctl’;

153

Gambar 4.10 Buat Control File untuk Standby

8. Identifikasi data file, redo log, dan standby redo log pada primary database

dan salin ke direktori standby database

SQL> SELECT FILE_NAME FROM DBA_DATA_FILES; SQL> SELECT FILE_NAME FROM DBA_TEMP_FILES; SQL> SELECT GROUP#, MEMBER FROM V$LOGFILE ORDER

BY GROUP#;

154

Gambar 4.11 Identifikasi data file dan redo log

155

Buat salinan dari primary database dengan mematikan primary database

dan buat salinan dari cold backup primary database dengan menggunakan

sintaks SQL berikut untuk mematikan database :

SQL> SHUTDOWN IMMEDIATE;

Buat direktori-direktori standby database sebagai berikut :

C:\oracle\product\10.2.0\admin\orcl2\adump C:\oracle\product\10.2.0\admin\orcl2\bdump C:\oracle\product\10.2.0\admin\orcl2\cdump C:\oracle\product\10.2.0\admin\orcl2\dpdump C:\oracle\product\10.2.0\admin\orcl2\pfile C:\oracle\product\10.2.0\admin\orcl2\udump C:\oracle\product\10.2.0\oradata\orcl2 C:\oracle\product\10.2.0\flash_recovery_area\orcl2\archivelog C:\oracle\product\10.2.0\flash_recovery_area\orcl2\backupset C:\oracle\product\10.2.0\flash_recovery_area\orcl2\datafile C:\oracle\product\10.2.0\flash_recovery_area\orcl2\flashback C:\oracle\product\10.2.0\flash_recovery_area\orcl2\onlinelog

Salin semua data file dan redo log dari primary database ke lokasi standby

database di C:\oracle\product\10.2.0\oradata\orcl2. Salin semua standby

redo log dari direktori C:\oracle\product\10.2.0\flash_recovery_area\orcl\

onlinelog menuju direktori C:\oracle\product\10.2.0\flash_recovery_area\

orcl2\onlinelog dan salin standby control file sbycontrol.ctl ke direktori

C:\oracle\product\10.2.0\oradata\orcl2.

9. Buat instance baru dengan nama “orcl2” pada primary database.

C:> ORADIM –NEW –SID orcl2 –SYSPWD oracle –STARTMODE manual

156

Gambar 4.12 Buat Instance Baru

- NEW akan menginisialisasi pembuatan instance baru.

- SID akan menentukan nama SID untuk instance yang baru.

- SYSPWD akan menentukan password untuk user SYS.

- STARTMODE akan menentukan jenis startup bagi instance baru.

Kini instance orcl2 telah siap untuk dijadikan physical standby database.

10. Konfigurasi listener dengan menggunakan “Net Manager” agar primary

database dan standby database dapat berkomunikasi.

Pada bagian Service Naming, tambahkan Service Name baru dengan

mengunakan port yang sama dengan port listener dengan pengaturan

sebagai berikut :

Net Service Name : orcl2

157

Gambar 4.13 Pengaturan Service Name (1 dari 5)

Protocol : TCP/IP (Internet Protocol)


158

Host Name : oracle

Port Number : 1521

Ini adalah hostname dan nomor port dari listener yang digunakan


Service Name : orcl2

Connection Type : Database Default

159


Pengaturan telah selesai. Tekan tombol finish.


160

Simpan konfigurasi yang telah diubah tersebut dengan memilih dari menu

File Save Network Configuration

Matikan dan nyalakan lagi listener dengan sintaks :

C:> LSNRCTL STOP C:> LSNRCTL START

11. Pada standby server, ubah environment variable ORACLE_SID menjadi

orcl2.

C:> set ORACLE_SID=orcl2

12. Aktifkan instance orcl2 dengan login ke dalam instance.

C:> SQLPLUS sys/oracle AS SYSDBA; SQL> STARTUP MOUNT;

13. Buat SPFILE untuk standby database dengan menyalin PFILE milik

primary database, dan melakukan beberapa perubahan parameter sebagai

berikut :

1. DB_NAME='orcl' 2. DB_UNIQUE_NAME='orcl2' 3. LOG_ARCHIVE_CONFIG='dg_config=(orcl,orcl2)' 4. LOG_ARCHIVE_DEST_1='LOCATION=C:\oracle\produ

ct\10.2.0\flash_recovery_area\ORCL2\archivelog VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orcl2'

5. LOG_ARCHIVE_DEST_2='SERVICE=orcl LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl'

6. LOG_ARCHIVE_DEST_STATE_1='ENABLE' 7. LOG_ARCHIVE_DEST_STATE _2='ENABLE' 8. LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc 9. LOG_ARCHIVE_MAX_PROCESSES=10 10. SERVICE_NAMES='orcl'

161

11. STANDBY_ARCHIVE_DEST=' LOCATION= C:\oracle\product\10.2.0\flash_recovery_area\orcl\archivelog'

12. STANDBY_FILE_MANAGEMENT='AUTO' 13. REMOTE_LOGIN_PASSWORDFILE='EXCLUSIVE' 14. FAL_SERVER=orcl 15. FAL_CLIENT=orcl2 16. DB_FILE_NAME_CONVERT='C:\oracle\product\10.2

.0\oradata\orcl','C:\oracle\product\10.2.0\oradata\orcl2'

17. LOG_FILE_NAME_CONVERT='C:\oracle\product\10.2.0\oradata\orcl','C:\oracle\product\10.2.0\oradata\orcl2’

Deskripsi dari initialization parameter yang digunakan dalam SPFILE

untuk konfigurasi Data Guard untuk standby database adalah sebagai

berikut :

No. Nama

parameter Deskripsi

1. DB_NAME Digunakan untuk mengidentifikasi nama primary

database yang bernama ‘orcl’

2. DB_UNIQUE_N

AME

Digunakan untuk mengidentifikasi nama

database ‘orcl2’

3. LOG_ARCHIVE

_CONFIG

Digunakan untuk mengidentifikasi berturut-turut

nama primary(‘orcl’) dan standby database

(‘orcl2’) yang digunakan dalam konfigurasi Data

Guard.

4. LOG_ARCHIVE

_DEST_1

Parameter ini hanya berlaku jika menggunakan

Oracle Enterprise Edition. Digunakan untuk

mendeskripsikan tujuan dan atribut dari archived

redo log.

Atribut LOCATION digunakan untuk menuliskan

alamat tujuan dari file sistem lokal pada

‘C:\oracle\product\10.2.0\flash_recovery_area\O

162

RCL2\ARCHIVELOG’

Atribut DB_UNIQUE_NAME digunakan untuk

nama database yang dituju yaitu ‘orcl2’

Atribut VALID_FOR digunakan untuk

menggambarkan pada kondisi apa redo transport

service akan dijalankan ke alamat yang dituju

berdasarkan nilainya. Jika nilainya

ALL_LOGFILES maka baik online redo log

maupun standby redo log akan di-archive ke

alamat tujuan. Jika nilainya ALL_ROLES maka

baik primary maupun standby database dapat

digunakan untuk tujuan.

5. LOG_ARCHIVE

_DEST_2

Sama seperti penjelasan sebelumnya, namun di

parameter ini ada beberapa atribut seperti

SERVICE yang digunakan untuk

mendeskripsikan service name dari database

tujuan ke mana redo data akan dikirimkan yang

dalam hal ini adalah primary database ‘orcl’.

Atribut DB_UNIQUE_NAME digunakan untuk

nama database yang dituju yaitu ‘orcl’.

Atribut LGWR menjelaskan bahwa pross LGWR

yang digunakan untuk mengumpulkan redo data

dan mengirimkannya ke tujuan standby database.

Atribut ASYNC menggambarkan bahwa proses

LGWR akan berjalan secara asynchronous ke

tujuan. Atribut VALID_FOR digunakan untuk

menggambarkan pada kondisi apa redo transport

service akan dijalankan ke alamat yang dituju

berdasarkan nilainya. Jika nilainya

ONLINE_LOGFILES itu berarti alamat tujuan

hanya berlaku ketika melakukan archiving pada

163

online redo log. Jika nilainya PRIMARY_ROLE

maka alamat tujuan hanya berlaku ketika

database dijalankan dalam primary role.

6. LOG_ARCHIVE

_DEST_STATE

_1

Digunakan untuk menjelaskan kondisi

ketersediaan dari alamat tujuan archived log di

primary database ‘orcl’. Jika nilainya ENABLED

maka alamat tujuan ini dapat digunakan untuk

operasi archiving berikutnya baik secara otomatis

maupun manual.

7. LOG_ARCHIVE

_DEST_STATE

_2

Digunakan untuk menjelaskan kondisi

ketersediaan dari alamat tujuan archived log di

standby database ‘orcl2’. Jika nilainya

ENABLED maka alamat tujuan ini dapat

digunakan untuk operasi archiving berikutnya

baik secara otomatis maupun manual.

8. LOG_ARCHIVE

_FORMAT

Parameter ini digunakan jika database

menggunakan redo log dalam kondisi

ARCHIVELOG untuk mendeskripsikan format

nama dari archived redo log. Nilai %s

memberikan nomor pada log sequence dan %t

memberikan nomor pada thread.

9. LOG_ARCHIVE

_MAX_PROCES

SES

Parameter ini mendeskripsikan jumlah proses

ARCH maksimum yang akan digunakan. Dalam

ini sebanyak 10 proses.

10. SERVICE_NAM

ES

Parameter ini berisi nama service yang didukung

oleh Oracle instance. Dalam hal ini ‘orcl2’.

11. STANDBY_ARC

HIVE_DEST

Parameter ini berisi alamat tujuan standby

database ‘orcl2’ untuk menyimpan archived

164

redo log. Dalam hal ini alamat penempatan dari

archived redo log pada standby database adalah

‘C:\oracle\product\10.2.0\flash_recovery_area\or

cl2\archivelog’.

12. STANDBY_FIL

E_MANAGEMEN

T

Parameter ini digunakan untuk menentukan

apakah pengaturan data file berjalan secara

manual atau otomatis diatur oleh sistem. Jika

nilainya AUTO maka ketika ada perubahan data

file di primary database, perubahan yang sama

juga akan dilakukan otomatis oleh sistem pada

standby database.

13. REMOTE_LOGI

N_PASSWORDF

ILE

Parameter ini mendeskripsikan apakah Oracle

akan memeriksa password file dan berapa banyak

database yang dapat menggunakan password file

tersebut. Jika nilainya adalah EXCLUSIVE maka

password file akan dapat digunakan hanya oleh

sebuah database dan password file dapat berisi

nama selain SYS dan INTERNAL.

14. FAL_SERVER Parameter ini berisi service name dari primary

database yang sedang aktif dalam hal ini ‘orcl’

15. FAL_CLIENT Parameter ini berisi service name dari standby

database yang sedang aktif dalam hal ini ‘orcl2’

16. DB_FILE_NAM

E_CONVERT

Parameter ini digunakan untuk menkonversi

nama sebuah data file baru pada primary

database ke nama data file pada standby

database. Isinya adalah alamat lokasi data file

pada primary database diikuti alamat lokasi data

file pada standby database. Yang dalam hal ini

diwakili oleh 'C:\oracle\product\10.2.0\oradata\

orcl', 'C:\oracle\product\10.2.0\oradata\orcl2'

17. LOG_FILE_NA Parameter ini digunakan untuk menkonversi

165

ME_CONVERT nama sebuah log file baru pada primary database

ke nama log file pada standby database. Isinya

adalah alamat lokasi log file pada primary

database diikuti alamat lokasi log file pada

standby database. Yang dalam hal ini diwakili

oleh 'C:\oracle\product\10.2.0\oradata\ orcl',

'C:\oracle\product\10.2.0\oradata\orcl2'

Tabel 4.2 Deskripsi Parameter pada Standby Database

Setelah melakukan perubahan pada PFILE tersebut, buatlah SPFILE

dengan menggunakan PFILE tersebut.

SQL> CREATE SPFILE FROM PFILE=’

C:\oracle\product\10.2.0\db_1\database\initorcl2.ora’;

14. Inisialisasi log apply services

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

Gambar 4.18 Inisialisasi Log Apply Services

Buka standby database dalam mode read-only untuk memeriksa apakah

semuanya sudah diatur dengan benar.

SQL> RECOVER MANAGED STANDBY DATABASE CANCEL; SQL> ALTER DATABASE OPEN READ ONLY;

166

Gambar 4.19 Buka Database dalam Mode Read Only

SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; SQL> ALTER DATABASE RECOVER MANAGED STANDBY

DATABASE DISCONNECT FROM SESSION;

Standby database sekarang sudah dalam posisi MOUNT dan berfungsi.

Periksa alert log untuk melihat apakah standby database dapat menerima

archived log dengan benar. Dapat juga query view V$ARCHIVED_LOG

untuk memeriksa bahwa redo log telah diterima.

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

Gambar 4.20 Melihat Archivelog pada Standby Database

Lakukan archiving current log pada primary database menggunakan

sintaks berikut.

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

167

Gambar 4.21 Archive Log Current

Periksa lagi pada standby database apakah archived log sudah diterima

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

Gambar 4.22 Melihat Archived log pada Standby Database setelah Archived

Log Current pada Primary Database

Jika archived log telah diterima, berarti standby databae sudah berhasil

dibuat.

Alur pembuatan physical standby database dapat diwakilkan oleh diagram berikut

:

168

Gambar 4.23 Flow Chart Pembuatan Physical Standby Database

169

4.5.2 Konfigurasi Tipe Data Protection

Data Guard menyediakan 3 macam tipe data protection, yaitu maximum

protection, maximum availability, dan maximum performance. Tipe data

protection yang dipilih akan menentukan apa yang terjadi apabila primary

database kehilangan koneksi dengan standby database.

Setiap tipe data protection pada Data Guard membutuhkan paling tidak

sebuah standby database dengan konfigurasi yang harus memenuhi syarat sebagai

berikut :

Maximum

Protection

Maximum

Availability

Maximum

Performance

Proses Redo Archival LGWR LGWR LGWR atau ARCH

Tipe Transmisi

Network

SYNC SYNC SYNC atau ASYNC

ketika menggunakan

LGWR. SYNC ketika

menggunakan ARCH

Tipe Penulisan Disk AFFIRM AFFIRM AFFIRM atau

NOAFFIRM

Butuh Standby Redo

Log ?

Ya Ya Tidak, namun

disarankan

Tabel 4.3 Syarat Standby Database

Tipe data protection yang dikonfigurasi untuk PT. Anugrah Argon Medica

adalah tipe proteksi maximum availability. Pemilihan tipe proteksi ini berdasarkan

beberapa pertanyaan sesuai landasan teori yang ada. Maximum availability akan

170

menjamin tidak ada data yang hilang, transaksi tidak akan di-commit pada primary

database sampai telah dipastikan bahwa data transaksi tersedia juga pada standby

database. Maximum availability juga menjaga sistem primary database tetap

tersedia apabila sewaktu-waktu standby database mengalami gangguan. Maximum

availability juga dapat mendukung konfigurasi role transition Fast-Start Failover.

Untuk mengatur tipe data protection untuk konfigurasi prototipe Data

Guard PT. Anugrah Argon Medica, dilakukan langkah-langkah sebagai berikut :

1. Konfigurasi parameter LOG_ARCHIVE_DEST_n pada primary

database.

Pada konfigurasi ini, perlu diingat bahwa setiap tipe data protection

memiliki persyaratan proses redo archival, tipe transmisi network, dan tipe

penulisan disk yang berbeda seperti tercantum dalam tabel 4.1. Konfigurasi

di bawah adalah konfigurasi untuk tipe data protection maximum

availability.

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=orcl2 OPTIONAL LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl2;

Gambar 4.24 Konfigurasi LOG_ARCHIVE_DEST_2 pada Primary Database

171

Baris kode ke-3 di atas disesuaikan dengan tipe data protection. Daftarkan

semua database pada parameter LOG_ARCHIVE_CONFIG dengan

atribut DG_CONFIG, sebagai berikut :

SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(orcl,orcl2)';

Gambar 4.25 Konfigurasi LOG_ARCHIVE_CONFIG pada Primary Database

2. Restart Database

SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT;

3. Tentukan tipe data protection

Untuk menentukan tipe data protection, dapat menggunakan sintaks

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE}

Konfigurasi di bawah adalah konfigurasi untuk tipe data protection dengan

tipe maximum availability yang direkomendasikan untuk PT Anugrah

Argon Medica.

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;

Gambar 4.26 Ubah Kondisi Proteksi

172

4. Buka database

SQL> ALTER DATABASE OPEN;

5. Konfigurasi parameter LOG_ARCHIVE_DEST_n pada standby

database

Pada standby database, lakukan konfigurasi parameter

LOG_ARCHIVE_DEST_n sehingga konfigurasi dapat melanjutkan operasi

ke tipe proteksi yang baru setelah switchover.

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=orcl OPTIONAL LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl';

Gambar 4.27 Konfigurasi LOG_ARCHIVE_DEST_2 pada Standby Database

6. Konfirmasi tipe data protection yang sedang berjalan

Lakukan query V$DATABASE untuk melihat tipe data protection yang

sedang berjalan.

SQL> SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE;

Gambar 4.28 Cek Mode Proteksi

173

Alur konfigurasi tipe data protection dapat diwakilkan oleh diagram berikut :

Gambar 4.29 Flow Chart Konfigurasi Mode Data Protection

174

4.5.3 Apply Redo Data pada Physical Standby Database

Metode apply redo data pada konfigurasi physical standby database

dinamakan Log Apply Service dimana akan mensinkronisasi standby database dan

primary database dengan meng-apply redo data. Log apply pada konfigurasi ini

menggunakan proses LGWR SYNC,dimana transaksi tidak akan di-commit di

primary database sampai redo data telah diterima oleh standby redo log standby

database. Tipe log apply yang digunakan adalah real-time apply, dimana proses

MRP akan langsung me-recover redo data dari standby redo log ke data file,

ketika standby redo log sedang diisi oleh proses RFS.

a. Real-Time Apply

Untuk menggunakan real-time apply, maka tambahkan perintah USING

CURRENT LOGFILE pada akhir perintah SQL di atas seperti :

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

Untuk menghentikan proses real-time apply, maka gunakan perintah :

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY

DATABASE DISCONNECT USING CURRENT LOGFILE;

b. Time Delay

Penggunaan time-delay dapat membantu melindungi kerusakan

pada aplikasi atau kesalahan data pada standby database. Time-delay yang

dimaksudkan disini adalah selang waktu yang dimulai ketika redo data

telah di-archive secara keseluruhan pada standby database tujuan. Satu hal

175

yang perlu diperhatikan adalah jika sebuah delay didefinisikan pada tujuan

standby database yang sedang berada dalam kondisi real-time apply, maka

delay tersebut tidak akan berfungsi.

Untuk mengatur waktu delay pada primary dan standby database,

perhatikan konfigurasi atribut DELAY pada parameter

LOG_ARCHIVE_DEST_n. Secara umum, Oracle Data Guard tidak akan

memasukkan waktu delay. Nilai standar dari DELAY adalah 30 menit.

Untuk membatalkan waktu delay yang telah dikonfigurasi sebelumnya

dapat menggunakan perintah

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

Menghentikan Redo Apply

Untuk menghentikan redo apply, baik dalam proses foreground atau background

dapat menggunakan perintah berikut.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

4.5.4 Konfigurasi Data Guard Broker

Ada beberapa tahap untuk mengatur konfigurasi Data Guard Broker

dengan menggunakan Data Guard command-line interface (DGMGRL).

DGMGRL dapat digunakan untuk membuat, mengatur, dan mengawasi

konfigurasi broker. Konfigurasi ini dibuat dengan asumsi sebagai berikut :

176

• Nama Konfigurasi: broker1.

• Database unique name (DB_UNIQUE_NAME) untuk primary database

adalah orcl.

• Database unique name (DB_UNIQUE_NAME) untuk standby database

adalah orcl2.

• Menggunakan mode proteksi maximum availability.

• Standby database adalah physical standby.

Langkah-langkah untuk mengatur konfigurasi broker antara lain sebagai berikut :

1. Enable Data Guard Broker Start

Pada primary database dan standby database, ubah parameter

DG_BROKER_START menjadi TRUE.

SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE SCOPE=BOTH;

Gambar 4.30 Enable Data Guard Broker Start

2. Periksa File Konfigurasi Broker

File konfigurasi broker secara otomatis akan dibuat saat

menggunakan ALTER SYSTEM SET DG_BROKER_START=TRUE.

Direktori dari file konfigurasi ini dapat dilihat dan diubah dengan

menggunakan parameter DG_BROKER_CONFIG_FILE1 dan

DG_BROKER_CONFIG_FILE2.

177

SQL> SHOW PARAMETER DG_BROKER_CONFIG;

Pada primary database :

Gambar 4.31 DG_BROKER_CONFIG pada Primary Database

Pada standby database :

Gambar 4.32 DG_BROKER_CONFIG pada Standby Database

3. Membuat Konfigurasi Broker

Untuk menggunakan DGMGRL, pada command prompt ketik sintaks :

C:\> DGMGRL

Gambar 4.33 Masuk ke DGMGRL

Hubungkan ke primary database menggunakan perintah CONNECT.

Account yang digunakan untuk mengakses database (misalnya SYS) harus

mempunyai hak sebagai SYSDBA.

178

DGMGRL> CONNECT sys/[password]@[connect

identifier];

Gambar 4.34 Hubungkan dengan Primary Database

Buat konfigurasi broker dengan mendefinisikan profil untuk primary

database. Kemudian tambahkan standby database dengan menggunakan

perintah ADD DATABASE. Gunakan perintah SHOW

CONFIGURATION untuk melihat konfigurasi yang telah dibuat.

DGMGRL> CREATE CONFIGURATION ‘broker1’ AS PRIMARY DATABASE IS ‘orcl’ CONNECT IDENTIFIER IS orcl;

DGMGRL> ADD DATABASE ‘orcl2’ AS CONNECT

IDENTIFIER IS orcl2 MAINTAINED AS PHYSICAL;

DGMGRL> SHOW CONFIGURATION;

Gambar 4.35 Konfigurasi Broker

179

4. Mengatur Database Properties

Setelah membuat konfigurasi dengan DGMGRL, property database dapat

dilihat dengan perintah :

DGMGRL> SHOW DATABASE VERBOSE [nama database];

Gambar 4.36 Lihat Property Database orcl2

180

Untuk mengubah property database tersebut, gunakan perintah berikut :

DGMGRL> EDIT DATABASE ‘[nama database]’ SET PROPERTY ‘[property]’=’[value]’;

5. Enable Konfigurasi Broker

Konfigurasi broker1 masih dalam status DISABLED, yang

berarti tidak dibawah kendali Data Guard broker. Setelah selesai mengatur

database ke dalam konfigurasi broker dan membuat pengaturan yang perlu

pada property database, konfigurasi broker dapat di-enable sehingga

broker dapat mengatur Data Guard.

DGMGRL> ENABLE CONFIGURATION;

Gambar 4.37 Enable Konfigurasi Broker

6. Enable Observer dan Fast-Start Failover

Fast-start failover dapat di-enable dari mana saja yang terhubung

dengan konfigurasi broker, termasuk tempat observer. Enable fast-start

failover tidak menyebabkan failover. Akan tetapi, fast-start failover

memungkinkan observer meninjau primary database dan standby database

181

dan memulai fast-start failover saat terjadi kerusakan primary database

sehingga perlu melakukan failover. Langkah-langkah untuk enable

observer dan fast-start failover :

• Pastikan standby redo log sudah dikonfigurasi pada semua

database. Ini sudah dilakukan pada saat membuat physical standby

database (langkah ke 4). Untuk memeriksa standby redo log,

gunakan perintah ini pada primary database dan standby database :

SQL> SELECT GROUP#, BYTES FROM V$STANDBY_LOG;


Gambar 4.38 Memeriksa Standby Redo Log pada Primary Database


Gambar 4.39 Memeriksa Standby Redo Log pada Standby Database

• Pastikan property LOGXPTMODE bernilai SYNC pada primary

database dan standby database. Gunakan perintah EDIT

DATABASE untuk mengubah cara pengiriman redo.

DGMGRL> EDIT DATABASE ‘orcl’ SET PROPERTY ‘LogXptMode’=’sync’;

182

DGMGRL> EDIT DATABASE ‘orcl2’

SET PROPERTY ‘LogXptMode’=sync’;

Gambar 4.40 Atur Property LOGXPTMODE

• Tentukan property FASTSTARTFAILOVERTARGET pada

primary database dan standby database untuk saling menunjuk satu

sama lainnya.

DGMGRL> EDIT DATABASE ‘orcl’ SET PROPERTY FastStartFailoverTarget=’orcl2’;

DGMGRL> EDIT DATABASE ‘orcl2’ SET PROPERTY

FastStartFailoverTarget=’orcl’;

Gambar 4.41 Atur Property FASTSTARTFAILOVERTARGET

• Ubah mode proteksi menjadi MAXAVAILABILITY dengan

perintah :

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

Dalam prototipe ini, mode proteksi diasumsikan dalam mode

MAXAVAILABILITY. Dapat dilihat dengan perintah SHOW

CONFIGURATION.

183

Enable flashback database pada primary database dan standby

database dengan menggunakan perintah :

SQL> ALTER SYSTEM SET UNDO_RETENTION=3600 SCOPE=SPFILE;

SQL> ALTER SYSTEM SET UNDO_MANAGEMENT=’auto’ SCOPE=SPFILE;

SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; SQL> SHOW PARAMETER UNDO; SQL> ALTER SYSTEM SET

DB_FLASHBACK_RETENTION_TARGET=4320 SCOPE=BOTH;

SQL> ALTER DATABASE ARCHIVELOG; SQL> ALTER DATABASE FLASHBACK ON; SQL> ALTER DATABASE OPEN;

184

Gambar 4.42 Enable Flashback Database

• Enable fast-start failover dapat dilakukan saat sedang terhubung

dengan sistem database pada konfigurasi broker.

DGMGRL> ENABLE FAST_START FAILOVER;

Gambar 4.43 Enable Fast-Start Failover

185

• Jalankan observer dengan DGMGRL. Sambungkan ke konfigurasi

dengan perintah CONNECT, kemudian jalankan perintah START

OBSERVER.

DGMGRL> CONNECT sys/oracle@orcl; DGMGRL> START OBSERVER;

Gambar 4.44 Start Observer

• Periksa kembali konfigurasi fast-start failover dengan

menggunakan perintah SHOW CONFIGURATION VERBOSE.

DGMGRL> SHOW CONFIGURATION VERBOSE;

Gambar 4.45 Periksa Konfigurasi Fast-Start Failover

Alur konfigurasi Data Guard broker dapat diwakilkan oleh diagram

berikut :

186

Gambar 4.46 Flowchart Konfigurasi Data Guard Broker

4.5.5 Konfigurasi Role Transition

Ada beberapa tahap yang perlu diperhatikan sebelum mengatur dan

membangun konfigurasi switchover atau failover pada physical standby database

antara lain :

1. Periksa apakah ada koneksi antara lokasi primary database dengan lokasi

standby database. Hal ini begitu penting karena tanpa adanya suatu koneksi

antar lokasi database tersebut, maka pengaturan akan sulit dilakukan.

2. Periksa apakah standby database yang ada mendukung role transition atau

tidak. Ini bisa dilihat dari nilai yang terdapat pada parameter-parameter

LOG_ARCHIVE_DEST_n dan LOG_ARCHIVE_DEST_STATE_n yang

sudah dijelaskan pada bagian pembuatan physical standby database

sebelumnya.

187

3. Periksa apakah standby database yang akan dijadikan primary database

yang baru berada dalam kondisi ARCHIVELOG. Jika standby database

tidak berada dalam kondisi ARCHIVELOG, maka role transition akan

gagal dan tidak dapat dilakukan. Untuk memeriksanya dapat menggunakan

perintah :

SQL> ARCHIVE LOG LIST;

Jika database belum dalam kondisi ARCHIVELOG, maka dapat dilakukan

perubahan kondisi database ke dalam kondis i ARCHIVELOG dengan

sintaks SQL berikut.

SQL> STARTUP MOUNT; SQL> ALTER DATABASE ARCHIVELOG; SQL> ALTER DATABASE OPEN;

4. Pastikan bahwa temporary file yang berada di standby database sama

dengan temporary file yang berada di primary database.

5. Jika ada delay dalam penggunaan redo log, maka delay harus dibuang /

dihapus.

6. Jika standby database menggunakan RAC maka pastikan hanya ada 1

database instance yang menyala dan matikan instance lainnya. Jika tidak

menggunakan RAC, maka perhatikan prasyarat pada bagian konfigurasi

switchover atau failover.

7. Kemudian berdasarkan tipe gangguan yang ada, atur konfigurasi

switchover atau failover pada physical standby database yang akan

dijelaskan dalam bagian switchover pada physical standby database dan

failover pada physical standby database.

188

Jika terjadi gangguan pada database, maka dapat digambarkan dalam

bentuk diagram seperti dibawah ini.

189

Gambar 4.47 Flow Chart Role Transition Jika Terjadi Gangguan

190

4.5.5.1 Switchover pada Physical Standby Database

Switchover dapat dilakukan untuk mengubah peran standby database

menjadi primary database, dan sebaliknya secara manual. Hal ini mungkin

dilakukan pada saat akan dilakukan pemeliharaan atau upgrade system pada

primary database. Peran primary database dapat diambil alih oleh standby

database, selama primary database tidak dapat diakses.

Konfigurasi untuk membuat physical standby database melakukan

switchover dapat dilakukan dengan langkah-langkah sebagai berikut.

1. Periksa apakah masih ada sesi yang sedang aktif dalam mengakses

database. Jika masih ada sesi yang aktif, maka sesi itu harus dimatikan

sebelum proses konfigurasi switchover dimulai.

2. Periksa apakah primary database instance sudah terbuka (OPEN) dan

standby database instance berada dalam kondisi MOUNT.

SQL> SELECT OPEN_MODE FROM V$DATABASE;

Jika standby database tidak berada dalam kondisi MOUNT maka

standby database terlebih dahulu harus dimatikan


Kemudian nyalakan kembali standby database tersebut dan lakukan

proses MOUNT.

SQL> STARTUP MOUNT;

3. Periksa database role apa yang sedang aktif di database server.

SQL> SELECT DATABASE_ROLE FROM V$DATABASE;

191

4. Pada primary database yang sedang digunakan, lakukan query untuk

memastikan bahwa primary database tersebut dapat melakukan

switchover.

SQL> SELECT SWITCHOVER_STATUS FROM

V$DATABASE;

Gambar 4.48 Cek Status Switchover

Jika hasilnya adalah TO_STANDBY, itu berarti primary

database tersebut dapat melakukan penggantian role menjadi standby

role. Ini adalah status hasil yang diharapkan. Jika hasilnya adalah

SESSIONS_ACTIVE, itu berarti ada sesi yang sedang mengakses

database pada saat itu.

Jika hasilnya di luar dari SESSIONS ACTIVE dan

TO_STANDBY, maka periksa parameter-parameter yang terdapat

pada LOG_ARCHIVE_DEST_n apakah sudah diatur dengan benar.

Hasil-hasil yang dimaksudkan di luar dari 2 jenis nilai output di atas

antara lain.

- NOT ALLOWED: Ini berarti baik standby database maupun

primary database belum dilakukan switchover atau

menunjukkan tidak adanya standby database yang sedang aktif.

192

- SWITCHOVER PENDING: Ini berarti ada permintaan

switchover antara standby database dan primary database yang

sudah diterima namun belum dilakukan.

- SWITCHOVER LATENT: Proses switchover berada dalam

kondisi pending, tidak dapat terselesaikan dan akhirnya kembali

ke bentuk semula primary database.

- TO PRIMARY: Menandakan bahwa database ini adalah

standby database dan dapat melakukan switchover ke primary

database.

- RECOVERY NEEDED: Menandakan bahwa database ini

adalah standby database dan belum menerima permintaan

switchover.

- PREPARING SWITCHOVER: Ada 2 kondisi yang bisa terjadi

disini. Kondisi pertama, database ini adalah primary database

yang sedang menerima redo data dari sebuah logical standby

database dalam persiapannya untuk melakukan switchover ke

logical standby database role. Kondisi kedua, database ini

adalah logical standby database yang sedang mengirimkan redo

data ke sebuah primary database dan ada standby database lain

yang sedang bersiap untuk melakukan switchover ke primary

database role.

- PREPARING DICTIONARY: Menunjukkan bahwa ini adalah

sebuah logical standby database yang sedang mengirimkan

redo data ke sebuah primary database dan ada standby

193

database lain yang sedang bersiap untuk melakukan switchover

ke primary database role.

- TO LOGICAL STANDBY: Menunjukkan bahwa ini adalah

sebuah primary database yang telah menerima dictionary

lengkap dari sebuah logical standby database.

5. Lakukan konversi primary database menjadi sebuah physical standby

database role dengan perintah di bawah ini :

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;

Jika ketika sintaks tersebut dijalankan dan ada pesan error seperti :

ORA-01093: ALTER DATABASE CLOSE only permitted with no sessions connected

maka itu berarti ada sesi yang sedang mengakses database pada saat

itu. Lakukan query di bawah ini untuk melakukan konversi dan

mematikan sesi tersebut sekaligus.

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;

Gambar 4.49 Ubah Primary Database menjadi Physical Standby Database

6. Matikan primary database dan lakukan STARTUP MOUNT

SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT;

194

7. Lakukan verifikasi bahwa primary database telah beralih menjadi

standby role.


Gambar 4.50 Cek Database Role

8. Pada standby database yang sedang digunakan, konversi physical

standby database role ke primary database role dengan sintaks :

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

Gambar 4.51 Ubah Standby Database menjadi Primary Database

Jika muncul pesan error seperti :

“ORA-16139: media recovery required”,

Maka jalankan perintah berikut :

SQL> RECOVER MANAGED STANDBY DATABASE;

Lalu kembali jalankan konversi yang tadi sempat tertunda karena ada

kesalahan dengan perintah di atas.

9. Periksa apakah physical standby database dalam mode READ-ONLY.

Jika dalam kondisi terbuka pada mode READ-ONLY, maka database

195

tersebut harus dimatikan. Hanya standby database yang terlibat dalam

proses failover saja yang harus dimatikan.

SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP

Jika dalam kondisi MOUNT, maka buka physical standby database

tersebut.


10. Lakukan verifikasi bahwa standby database telah beralih menjadi

primary database role.


11. Jika dibutuhkan, lakukan restart pada log apply services.

12. Primary database yang baru siap untuk digunakan.

Alur konfigurasi pengaturan switchover pada physical standby database dapat

diwakilkan oleh diagram berikut :

196

Cek apakah primary database instance sudah ter buka(OPE N) & standby database

instance d i-m ount

Cek SWITCHOV ER_STATUS di primar y database

STATUS la in

Konv ersikan primary ke standby database role

ALTER DATABAS E COMMIT TO SWITCHOVER TO PHYSICA L

STANDB Y

Cek par ameter LOG_ARCHIV E

_DEST_n

TO_STANDBY

Gunakan ALTE R DA TA BASE COMMIT TO

SWITCHOV ER TO PHYS ICAL STANDB Y WITH S ESSION

SHUTDOWN

SESS IONS_ACTIVE

Switchover pada

Physical standby Database

Shutdown primary databaseSHUTDOWN IMMEDIATE

Mount as a standby databaseSTARTUP MOUNT

K onversikan physic al ke new pr imary database ro le ALTER DATAB ASE COM MIT TO SWITCHOV ER TO PRIMA RY

E rror mengenai media recovery selesaikan

denganRECOV ER MA NAGED STANDB Y DATABA SE

STA RTUP phy sica l standby databaseSQL>S TA RTUP

Restart log apply s ervices

Kirim redo data ke s tandby databaseA LTER SYSTEM SWITCH LOGFILE

New primary database s iap digunakan

Shutdown IMM EDIATE physical standby databas e

Cek apakah phys ica l standby DB terbuka

dalam mode read-only

Buka physical standby DB

dengan ALTER DATAB ASE

OP EN

tidak

ya

Tentukan jenis s wi tchov er

P eriksa apakah m asih ada sesi yang

aktif

P hysicalstandby

Tidak

YaMatikan sesi

yang aktif

open primary databaseALTER DATAB ASE OPENMount standby database

S HUTDOWN IMME DIATESTARTUP M OUNT

tidak

Per iksa database ro le d i database serv erSE LECT DATABA SE_ROLE FROM V$DATABA SE

Ya

Apak ah ada error

tidak

Periksa database ro le d i database serv erSELECT DATABAS E_ROLE FROM V$DATABAS E

ya

Gambar 4.52 Flow Chart Switchover pada Physical Standby Database

197

4.5.5.2 Failover pada Physical Standby Database

Konfigurasi untuk membuat physical standby database melakukan

failover dapat dilakukan dengan langkah-langkah sebagai berikut.

1. Memeriksa jenis proteksi yang sedang digunakan. Lakukan query

V$DATABASE untuk melihat tipe data protection yang sedang

berjalan

SQL> SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE;

Gambar 4.53 Periksa Mode Proteksi

Jika jenis proteksi yang sedang digunakan adalah MAXIMIZE

PROTECTION atau MAXIMIZE AVAILABILITY dengan LGWR

maka tidak perlu untuk memeriksa gap yang ada pada redo log file dan

menuju ke langkah nomor 2.

Jika jenis proteksi yang sedang digunakan adalah MAXIMIZE

PERFORMANCE maka perlu dilakukan langkah-langkah berikut

sebelum masuk ke tahap selanjutnya.

a. Periksa apakah ada gap di redo log pada standby database

melalui query bagian V$ARCHIVE_GAP

SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

198

Gambar 4.54 Periksa Archive Gap

Bagian V$ARCHIVE_GAP berisi nomor sequence dari

archived redo log yang diketahui hilang pada masing-masing

thread. Nilai data yang ditampilkan hanya menampakkan

bagian gap yang tertinggi saja.

b. Jika ada redo log yang memiliki gap dan situasinya masih

memungkinkan, salin semua archived redo log yang

teridentifikasi hilang dari primary database ke standby database

c. Daftarkan kembali redo log tersebut. Hal ini harus dilakukan

untuk setiap masing-masing thread.

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'namafile';

d. Langkah a, b dan c harus dilakukan terus menerus hingga gap

yang ada terselesaikan (tidak ada baris yang muncul dari query

SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

e. Pastikan kembali bahwa tidak ada archived redo log yang hilang

di standby database dengan melakukan query pada bagian

V$ARCHIVED_LOG.

SQL> SELECT UNIQUE THREAD# AS THREAD,

MAX(SEQUENCE#) OVER (PARTITION BY

199

THREAD#) AS LAST FROM V$ARCHIVED_LOG;

Gambar 4.55 Periksa Archived Redo Log yang Hilang

Bagian query di atas akan memberikan hasil nomor sequence tertinggi

untuk masing-masing thread. Jika ada nomor sequence archived redo

log di primary database yang lebih tinggi dari nomor sequence

archived redo log di standby database, maka redo log tersebut harus

disalin dan didaftarkan sesuai langkah b dan c di atas.

2. Inisialisasi failover dan matikan semua proses Remote File Server

(RFS) yang sedang aktif pada physical standby database.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE;

Gambar 4.56 Mematikan Proses RFS pada Standby Database

3. Lakukan konversi pada physical standby database agar memiliki

primary role.

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

200

Gambar 4.57 Konversi pada Physical Standby Database agar Memiliki Primary Role

Setelah perintah ini dijalankan, standby database akan mengalami

perubahan menjadi primary role. Selama proses failover berlangsung,

redo log yang terdapat pada standby database akan secara otomatis di-

archive dan di-recover dari primary database yang terdahulu.

4. Periksa apakah physical standby database dalam mode READ-ONLY.

Jika dalam kondisi terbuka pada mode READ-ONLY, maka database

tersebut harus dimatikan. Hanya standby database yang terlibat dalam

proses failover saja yang harus dimatikan.


Jika dalam kondisi MOUNT, maka buka physical standby database

tersebut.


5. Lakukan backup pada primary database yang baru saja terbentuk ini.

6. Untuk kondisi standby database yang sedang dalam kondisi mati, dapat

dinyalakan dengan query :

SQL> STARTUP;

201

Pada posisi ini, standby database yang sebelumnya memegang standby

role sekarang telah memiliki primary role dan menjadi primary

database. Semua standby database sekarang mulai menerima dan men-

apply redo data dari primary database yang baru.

7. Primary database yang berada dalam kondisi rusak dapat diperbaiki

dan menjadi sebuah standby database yang baru. Primary database

dapat diperbaiki dengan menggunakan beberapa metode antara lain :

a. Menggunakan flashback database untuk mengembalikan

primary database ke posisi sebelum terjadinya kerusakan atau

gangguan tersebut dan setelah itu dapat dikonversi menjadi

standby database (dengan catatan pengaturan konfigurasinya

telah memungkinkan flashback database pada primary database

tersebut sebelum terjadinya gangguan / kerusakan).

b. Membuat ulang database yang rusak dan menjadikannya

sebagai standby database yang baru dengan menggunakan

salinan backup dari primary database yang baru.

c. Menggunakan Oracle Enterprise Manager atau perintah

DGMGRL seperti REINSTATE DATABASE untuk kembali

membuat ulang primary database yang rusak sebagai sebuah

standby database (dengan catatan pengaturan konfigurasinya

telah memungkinkan flashback database pada primary database

tersebut sebelum terjadinya gangguan / kerusakan).

202

Alur konfigurasi pengaturan failover pada physical standby database

dapat diwakilkan oleh diagram berikut :

203

Failover pada physical standby DB

Cek prot ection mod e

Maximize Pro tectionatau

MAXIMIZE AVAILABILITYd engan LGWR

Ma ximize Performance

Copy gap redo log yang te ridentifikasi ke Standby DB dan lakukan Registe r deng an ALTER DATABASE REGISTER

PHYSICAL LOGFILE ‘namafile’

Initiate failover & matika n pro ses yang sedan g aktif pada ph ysica l standb y DB denga n ALTER DATABASE RECOVER

MANAGED STANDBY DATABASE FI NISH FORCE

Konversikan physical standby DB ke primary role

ALTER DATABASE COMM IT TO SWITCHOVER TO PRIMARY

Shutdo wn IMM EDIATE physical stan dby DB

STARTUP p hysica l standb y DB

Restore pr ima ry datab ase lama yang rusak dengan FLASHBACK, DGMGRL

a tau re -crea te ulang

Ce k ad a Gap di red o lo g standby DB de ngan Query V$ARCHIVE_ GAP

Cek apa kah masih ada gap redo logdeng an Query V$ARCHI VE_ GAP

Ya

tidak

Cek redo log deng an sequence tertinggi di standby DB d engan q uery V$ARCHIVED_LOG

Cek apakah a da redo log di p rimary yang seq uencenya

lebih tinggi dari stan dby DB

Copy redo log tersebut ke stan dby DB dan register kemb ali deng an ALTER DATABASE REGISTER PHYSICAL LOGFILE ‘nam afile’

ya

tida k

Query V$ARCHIVE_GAP da n pastikan tida k ad a gap an tara redo log d i standb y DB

Ce k ap aka h physical sta ndby DB terbuka Ya

Buka physical standby DB denga n ALTER DATABASE OPEN

tidakBackup new primary

data base

Backup new primary dat abase

Ne w primary da tabase sia p diguna kan OPTIONAL

FAILOVER PADA PHYSICAL STANDBY DATABASE

Gambar 4.58 Flow Chart Failover pada Physical Standby Database

204

4.5.6 Fast-Start Failover dengan Broker

Dengan menggunakan observer pada broker, Data Guard dapat melakukan

fast-start failover secara otomatis saat terjadi gangguan pada primary database.

Cara kerja broker pada proses fast-start failover adalah sebagai berikut :

• Pastikan primary database, standby database, dan observer sudah berjalan

dengan baik dan saling terhubung satu sama lain.

Gambar 4.59 Proses Fast-Start Failover (1 dari 5)

Command prompt di kiri atas adalah primary database dengan

ORACLE_SID=orcl. Command prompt di kiri bawah adalah physical

standby database dengan ORACLE_SID=orcl2. Command prompt di

205

kanan atas adalah observer yang mengawasi primary database secara terus

menerus untuk memastikan ketersediaan primary database. Command

prompt di kanan bawah adalah broker untuk melihat konfigurasi Data

Guard broker.

• Pada saat terjadi gangguan pada primary database yang mengakibatkan

primary database menjadi DOWN, maka observer akan segera mendeteksi

adanya masalah pada primary database dan berusaha untuk

menghubungkan lagi dengan primary database dalam jangka waktu yang

telah diatur pada properti FASTSTARTFAILOVERTHRESHOLD. Waktu

FASTSTARTFAILOVERTHRESHOLD berjalan saat observer

mendeteksi adanya masalah pada primary database yang menyebabkan

primary database mengalami DOWN. Prosesnya dapat dilihat pada gambar

berikut :

206


Pada primary database dijalankan perintah SHUTDOWN ABORT yang

akan menyebabkan primary database mengalami “hard crash”, menjadi

DOWN dan tidak tersedia. Setelah waktu

FASTSTARTFAILOVERTHRESHOLD berlalu dan observer tetap tidak

dapat terhubung dengan primary database, maka observer akan segera

melakukan proses fast-start failover. Setelah proses fast-start failover

selesai dijalankan, maka physical standby database akan menjadi primary

database oleh observer secara otomatis dan dibuka untuk proses READ-

WRITE. Konfigurasi broker juga berubah dan terdapat error karena

207

physical standby database belum aktif. Orcl2 menjadi primary database

dan orcl menjadi physical standby database.

• Setelah primary database yang lama (orcl) diperbaiki dan terhubung

kembali dengan observer, observer akan segera melakukan REINSTATE

pada primary database yang lama (orcl) menjadi standby database yang

baru.


Jika observer tidak dapat melakukan REINSTATE secara otomatis pada

primary database yang lama (orcl), maka observer akan meminta

208

Administrator untuk melakukan REINSTATE secara manual.

REINSTATE primary database dapat dilakukan dengan perintah :

DGMGRL> REINSTATE DATABASE orcl;


Sebelum melakukan REINSTATE pada DGMGRL, database yang akan

di- REINSTATE harus dalam keadaan MOUNT.

• Setelah proses REINSTATE berhasil, maka status orcl akan berubah peran

menjadi physical standby database. Konfigurasi pada broker juga akan

berubah secara otomatis. Setelah physical standby database yang baru

209

sudah terhubung dengan primary database, pengiriman redo data yang di-

pending segera dilakukan untuk sinkronasi data.


4.5.7 Memonitoring Standby Database

Untuk memonitoring kondisi standby database, maka ada beberapa hal

yang harus diperiksa :

1. Periksa jenis proteksi, tingkat proteksi, database role, nama database

instance, kondisi database saat ini dan status switchover-nya di bagian

V$DATABASE.

210

SQL> SELECT DATABASE_ROLE, DB_UNIQUE_NAME INSTANCE, OPEN_MODE, PROTECTION_MODE, PROTECTION_LEVEL, SWITCHOVER_STATUS FROM V$DATABASE;


Gambar 4.64 Periksa Atribut Primary Database


Gambar 4.65 Periksa Atribut Standby Database

2. Periksa pula kondisi fast-start failover yang sedang digunakan pada

standby database.

SQL> SELECT FS_FAILOVER_STATUS FSFO_STATUS, FS_FAILOVER_CURRENT_TARGET, FS_FAILOVER_THRESHOLD THRESHOLD, FS_FAILOVER_OBSERVER_PRESENT OBS_PRES FROM V$DATABASE;

211

Gambar 4.66 Periska Kondisi Fast-Start Failover

Jika kondisi status failover tidak bernilai SYNCHRONIZED maka fast-start

failover tidak akan dapat dijalankan pada sistem. Salah satu penyebabnya

adalah adanya redo log yang belum di-apply ke standby database atau tidak

tersimpan di standby database. Nilai YES pada atribut OBS_PRES berarti

sistem mendeteksi adanya observer yang sedang aktif memantau kondisi

koneksi database. Nilai 30 pada atribut THRESHOLD berarti sebelum

waktu 30 detik habis maka observer akan mencoba untuk berkomunikasi

dengan primary database terus menerus. Jika selama 30 detik itu masih tidak

ada reaksi dari primary database maka proses fast-start failover akan

dilakukan.

3. Periksa aktivitas redo apply dan transportasi redo data pada standby

database di bagian V$MANAGED_STANDBY.

SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;

212

Gambar 4.67 Periksa Aktivitas Redo Apply

Gambar di atas memberikan suatu gambaran proses yang sedang terjadi

pada standby database. Kolom PROCESS berisi proses-proses yang

sedang terjadi di foreground dan background standby database. Pada

proses ARCH yang berjumlah 10 buah (sesuai dengan parameter

LOG_ARCHIVE_MAX_PROCESSES yang berada di SPFILE). Ada

proses yang sedang bersiap melakukan proses archiving (CONNECTED),

1 buah proses yang sedang melakukan proses archiving (IDLE) , dan

beberapa proses yang sudah selesai melakukan archiving (CLOSING).

Proses RFS ada yang sedang melakukan penulisan redo data pada standby

redo log di standby database. Hal ini bisa dilihat dari posisi thread,

sequence, dan perkiraan jumlah blok data yang sedang aktif dilakukan

proses MRP0. Proses MRP sendiri melakukan proses applying log pada

standby database sesuai dengan STATUS yang ada.

213

4. Periksa level sinkronisasi standby database untuk melihat jumlah archived

redo log yang ada di bagian V$ARCHIVE_DEST_STATUS.

SQL> SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#, APPLIED_THREAD#, APPLIED_SEQ# FROM V$ARCHIVE_DEST_STATUS;


Gambar 4.68 Periksa Level Sinkronisasi pada Primary Database


Gambar 4.69 Periksa Level Sinkronisasi pada Standby Database

214

Pastikan bahwa jumlah sequence dan posisi thread yang di-archive dan di-

apply sama baik di primary maupun standby database untuk menghindari

adanya gap antar redo log. Posisi terakhir sequence yang di-archive

berdasarkan gambar di atas adalah sequence ke-46 dan sequence terakhir

yang di-apply adalah sequence ke-45.

Jika fitur real-time apply diaktifkan, maka lakukan query pada

kolom RECOVERY_MODE dari V$ARCHIVE_DEST_STATUS di

standby database. Nilai yang ada seharusnya adalah MANAGED REAL

TIME APPLY.

SQL> SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2;

Gambar 4.70 Periksa Mode Recovery

5. Periksa log terakhir yang berhasil di-apply ke standby database pada

primary dan standby database dengan perintah berikut :

SQL> SELECT THREAD#, MAX(SEQUENCE#) AS "LAST_APPLIED_LOG" FROM V$LOG_HISTORY GROUP BY THREAD#;

215


Gambar 4.71 Periksa Log Terakhir yang di-apply pada Primary Database


Gambar 4.72 Periksa Log Terakhir yang di-apply pada Standby Database

Pastikan bahwa nilai maksimum sequence dari log paling akhir yang

berhasil di-apply pada standby database sama dengan nilai maksimum

sequence di primary database.

6. Periksa log mana yang belum diterima di standby database dengan

melakukan query pada primary database.

SQL> SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1 )LOCAL WHERE LOCAL.SEQUENCE# NOT IN (SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND THREAD# = LOCAL.THREAD#);

216

Gambar 4.73 Periksa Log yang Belum Diterima oleh Standby Database

Jika ternyata nanti ditemukan beberapa log yang belum diterima di standby

database, maka log file tersebut harus disalin secara manual ke lokasi

standby database dan kemudian dilakukan pendaftaran pada sistem dengan

perintah SQL berikut :

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE

'nama file' ;

7. Periksa semua archived redo log yang diterima dari primary database di

standby database setelah standby database mulai menerima redo data.

SQL> SELECT REGISTRAR, CREATOR, THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# FROM V$ARCHIVED_LOG;

217

Gambar 4.74 Periksa Semua Archived Redo Log Yang Diterima Oleh Standby

Database

Untuk memeriksa agar archived redo log sinkron atau tidak, perhatikan

urutan sequence yang telah di-apply. Pastikan urutannya tidak ada yang

terlewatkan atau hilang. Perhatikan pula FIRST_CHANGE# dan

NEXT_CHANGE# yang nilainya selalu berkelanjutan seperti ditunjukkan

gambar di atas. Pada gambar di atas sequence dari nomor 1 hingga 16 tidak

tercantum, ini disebabkan karena query ini hanya menampilkan sequence-

sequence yang terbentuk ketika database sudah mulai menerima redo

datadan ini bukan hal yang mengkhawatirkan untuk database.

218

8. Periksa semua archived redo log yang sudah di-apply pada standby

database di bagian V$LOG_HISTORY

SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# FROM V$LOG_HISTORY;

Gambar 4.75 Periksa Semua Archived Redo Log Yang Sudah Di-Apply Pada

Standby Database

9. Periksa apakah ada gap atau tidak pada archived redo log dengan perintah

berikut :

SQL> SELECT * FROM V$ARCHIVE_GAP;

219

Gambar 4.76 Periksa Apakah Ada Gap Pada Archived Redo Log

Jika terjadi gap antara redo log maka akan ditampilkan nomor sequence

terendah, tertinggi, dan thread-nya.

10. Periksa kondisi Oracle Data Guard pada primary database dan standby

database dengan semua pesan peringatan di dalamnya di bagian

V$DATAGUARD_STATUS.

SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;

220


Gambar 4.77 Periksa Kondisi Oracle Data Guard Pada Primary Database

221


Gambar 4.78 Periksa Kondisi Oracle Data Guard Pada Standby Database

4.6 Rencana Implementasi Sistem

Rencana implementasi Oracle Data Guard akan dilaksanakan setelah rancangan

dan prototipe Data Guard tersebut selesai dibangun. Rencana implementasi ini dibuat

agar Data Guard yang telah dirancang dapat diimplementasikan dengan baik sehingga

berguna untuk menjamin keberlangsungan proses bisnis dan keamanan data PT.

222

Anugrah Argon Medica. Penjadwalan rencana implementasi dari sistem Data Guard

yang telah dirancang ditunjukkan pada tabel berikut.

Aktivitas Minggu

1 3 5 7 9 11 13 15 17 19

Pembentukan Tim

Pengadaan H/W

Instalasi H/W

Instalasi S/W

Instalasi Jaringan

Konfigurasi Data Guard

Uji coba sistem

Pelatihan DBA

Implementasi sistem

Tabel 4.4 Jadwal Rencana Implementasi Sistem

Konfigurasi Data Guard dilakukan dengan mengatur konfigurasi pada standby

database terlebih dahulu. Setelah standby database siap dihubungkan dengan primary

database, barulah melakukan konfigurasi pada primary database. Konfigurasi Data

Guard pertama dilakukan dengan menggunakan server lain untuk uji coba. Jika

konfigurasi telah berhasil berjalan, maka konfigurasi akan dilakukan terhadap database

produksi. Konfigurasi primary database dilakukan pada saat tidak ada yang mengakses

sistem sama sekali, yaitu pada hari Minggu atau pada hari libur kerja, karena saat

melakukan konfigurasi pada database produksi, sistem perlu dimatikan untuk

223

melakukan perubahan terhadap initialization parameter, dan di-STARTUP kembali. Uji

coba sistem dilakukan dalam beberapa tahap selama 2 minggu di awal bulan :

• Green Zone, yaitu pada saat tidak ada session yang mengakses sistem sama

sekali. Biasanya pada hari Minggu atau hari libur di awal bulan.

• Low Peak Hour, yaitu pada saat tidak begitu banyak transaksi yang berlangsung.

Biasanya pada hari Sabtu di awal bulan.

• Medium Peak Hour, yaitu pada saat transaksi yang menggunakan sistem cukup

banyak. Biasanya pada pertengahan bulan sekitar jam 14.00.

4.7 Perbandingan Anailsis Sistem

4.7.1 Perbandingan Sistem

Perbandingan antara sistem availability PT Anugrah Argon Medica yang

sedang berjalan dengan sistem yang diusulkan berdasarkan penanganan dan waktu

yang dibutuhkan untuk recovery adalah sebagai berikut :

No. Tipe Gangguan Penanganan & Lama Waktu Recovery

Sistem yang sedang berjalan Sistem yang diusulkan

1 Database Server

down

DBA harus mencari penyebab

down, dan melakukan recovery

manual.

Waktu Recovery:

Satuan jam

Fast-Start Failover dan

Fast Connection

Failover.

Waktu Recovery:

< 5 menit

224

Tabel 4.5 Tabel Perbandingan Sistem

Tabel 4.5 menunjukkan perbandingan antara sistem availability yang

sedang berjalan dengan sistem high availability yang diusulkan. Dari tabel tersebut

2 Kerusakan pada

disk storage server

Mengganti disk yang rusak terlebih

dahulu, setelah itu data bisa

kembali diakses.

Waktu Recovery:

Satuan jam

Fast-Start Failover dan

Fast Connection

Failover.

Waktu Recovery:

< 5 menit

3 Kerusakan pada

disk dimana ada file

yang belum sempat

di backup

Tidak ada penanganan, sehingga

file menjadi tidak terselamatkan.

Sinkronisasi database

dengan Real Time Apply.

4 System

Maintenance atau

System Upgrade

Menggunakan Standby Server

untuk menggantikan Primary

Server.

Waktu Recovery: 2 Jam

Switchover Role

Transition.

Waktu Recovery:

< 5 menit

5 Kerusakan data

center akibat

bencana

Belum ada penanganan, proses

bisnis terhenti total, data yang

terselamatkan hanyalah data yang

telah di-backup.

Standby Database, Fast-

Start Failover dan Fast

Connection Failover.

Waktu Recovery:

< 5 menit

225

dapat disimpulkan bahwa sistem high availability yang diusulkan lebih mampu

untuk menjaga kelangsungan proses bisnis, keutuhan dan keamanan penyimpanan

informasi perusahaan pada saat terjadi gangguan pada database server dan storage

server baik terencana maupun tidak terencana dengan lama waktu recovery yang

sesingkat mungkin.

4.7.2 Cost and Benefit

Analisis cost and benefit dilakukan dengan menganalisis biaya yang

dibutuhkan untuk membangun sistem high availability yang diusulkan

dibandingkan dengan keuntungan yang diberikan oleh sistem tersebut kepada PT.

Anugrah Argon Medica.

• Analisis Biaya

Di dalam merancang sebuah sistem Disaster Recovery Center (DRC), ada

beberapa hal baik berupa perangkat keras maupun perangkat lunak yang

diperlukan di dalamnya. Berikut adalah perkiraan biaya investasi yang dibutuhkan

untuk membangun sebuah Disaster Recovery Center (DRC).

Kebutuhan Arsitektur Harga

Database server $ 50.000

Storage server $ 60.000

Data center $ 100.000

Total Biaya $ 210.000

Tabel 4.6 Biaya Kebutuhan Arsitektur

226

Di dalam perhitungan biaya arsitektur, PT. Anugrah Argon Medica

mengikuti ketentuan SAK (Standar Akuntansi Keuangan), dengan asumsi biaya

investasi awal dicicil selama 4 tahun. Sehingga untuk mendapatkan perhitungan

biaya 1 tahun, total biaya yang diperlukan untuk kebutuhan arsitektur dibagi 4.

Maka biaya yang harus dikeluarkan perusahaan untuk kebutuhan arsitektur

adalah sebesar :

$ 210.000 x Rp.10.000 (kurs $1 = Rp. 10.000) = Rp. 2.100.000.000

Rp. 2.100.000.000 : 4 = Rp. 525.000.000,-

Selain biaya arsitektur, perusahaan juga harus mengeluarkan biaya

operasional tiap tahunnya dengan perincian sebagai berikut :

Biaya Operasional Harga

Jaringan dan bandwidth Rp. 14.000.000 per bulan

Biaya listrik, perawatan peralatan Rp. 4.000.000 per bulan

Total Biaya per bulan Rp. 18.000.000

Total Biaya per tahun Rp. 216.000.000

Tabel 4.7 Biaya Operasional DRC

Berdasarkan perincian di atas, maka total biaya yang harus dikeluarkan

untuk membangun Disaster Recovery Center tahun pertama adalah sebesar :

Rp. 525.000.000 + Rp. 216.000.000 = Rp. 741.000.000,-

227

• Analisis Benefit

Analisis benefit ini dilakukan dengan menghitung kemungkinan kerugian

perusahaan yang akan diproteksi oleh sistem high availability dengan Oracle Data

Guard berdasarkan pengalaman terjadinya system down pada PT. Anugrah Argon

Medica. Berdasarkan analisis transaksi pada bagian 3.7.2 yang membahas

kerugian pendapatan akibat ketidaktersediaan sistem, maka dapat dilihat bahwa

kemungkinan kerugian terbesar yang akan dialami PT. Anugrah Argon Medica

adalah apabila perusahaan sedang berada pada masa peak transaction di akhir

bulan.

Dapat digambarkan pada gambar berikut :

0

20000

40000

60000

80000

100000

120000

1 5 10 15 20 25 30

Gambar 4.79 System Down pada Akhir Bulan

Keterangan: sumbu X : Satuan Hari sumbu Y : Jumlah transaksi yang terjadi

Berdasarkan statistik 2002-2008, PT. Anugrah Argon Medica sudah

mengalami 8 kali system down yang mengakibatkan proses bisnis terhambat.

Sehingga dapat diperkirakan probabilitas kejadian system down dalam 1 bulan

adalah :

228

( ) 91

728

1268

==x

Dalam perhitungan persentase adalah :

91

x 100% = 11,11%

Berdasarkan persentase diatas, maka dapat dikatakan bahwa kemungkinan

terjadinya system down dalam 1 bulan adalah sebesar 11,11% atau 1 kali dalam

kurun waktu 9 bulan. Kemungkinan terburuknya adalah jika system down tersebut

terjadi pada akhir bulan atau pada saat peak transaction dimana akan

mengakibatkan kerugian sebesar Rp. 50.000.000.000,-. Jika dalam kurun waktu 9

bulan terjadi 1 kali system down yang mengakibatkan kerugian sebesar Rp.

50.000.000.000,- maka kerugian perbulannya adalah sebesar :

Rp. 50.000.000.000 x 11,11% = Rp. 5.500.000.000,- per bulan

Dalam 1 tahun, perusahaan akan mengalami kerugian :

Rp. 5.500.000.000,- x 12 = Rp. 66.000.000.000 per tahun

Berdasarkan analisis di atas, maka perbandingan cost dan kerugian yang diproteksi

dengan sistem high availablilty dapat digambarkan sebagai berikut :

229

Gambar 4.80 Cost berbanding Kerugian yang Diproteksi

Keterangan: Nilai dalam satuan juta

Dengan demikian, dapat dilihat bahwa sistem high availability dengan investasi

cost sebesar Rp. 741.000.000,- akan memproteksi kerugian sebesar Rp.

66.000.000.000,- per tahun.

4.8 Evaluasi

Berdasarkan evaluasi dari perancangan dan prototipe sistem high availability

dengan menggunakan Oracle Data Guard, maka sistem yang diusulkan ini dapat

menjamin keberlangsungan proses bisnis dan tidak adanya kehilangan data pada saat

terjadi gangguan atau kerusakan pada primary database. Data Guard dapat mengatasi

kekurangan dari sistem availability yang sedang berjalan. Berdasarkan analisis Cost and

230

Benefit, pembangunan sistem high availability juga akan mendatangkan benefit yang

signifikan dengan cost yang optimal.

Melalui perancangan prototipe ini, PT Anugrah Argon Medica dapat memiliki

pertimbangan untuk meningkatkan sistem availability-nya, menjadi sistem high

availability dengan Oracle Data Guard.

BAB 4 RANCANGAN SISTEM HIGH AVAILABILITY YANG …thesis.binus.ac.id/Asli/Bab4/2009-1-00220-IF bab...

Documents

Transcript of BAB 4 RANCANGAN SISTEM HIGH AVAILABILITY YANG …thesis.binus.ac.id/Asli/Bab4/2009-1-00220-IF bab...