BAB 4 RANCANGAN SISTEM HIGH AVAILABILITY YANG DIUSULKAN. Perancangan sistem high availability dengan Oracle Data Guard dilakukan

135 BAB 4 RANCANGAN S IS TEM HIGH AVAILABILITY YANG DIUS ULKAN

4.1

Sistem yang Diusulkan Perancangan sistem high availability dengan Oracle Data Guard dilakukan

dalam beberapa tahap. Adapun tahapan-tahapan tersebut adalah : a. M empelajari latar belakang dan tujuan perusahaan. Dilakukan untuk mengetahui faktor apa saja yang dapat mempengaruhi keberhasilan perusahaan dan kebutuhan informasi untuk pihak manajemen. b. M enganalisis proses bisnis. Dilakukan untuk mengetahui alur bisnis yang terjadi di perusahaan, dan mengetahui aktor-aktor bisnis yang terlibat dalam proses bisnis perusahaan. c. M enganalisis 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. M enganalisis 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. M enganalisis dampak bisnis. Berdasarkan analisis masalah dan setelah itu dilakukan analisis untuk menentukan dampak yang terjadi pada proses bisnis. f. M enganalisis kerugian pendapatan akibat system down. Kerugian pendapatan bekerjasama dapat diperhitungkan dengan menganailsis nilai transaksi yang terhambat ketika terjadi gangguan sistem. g. M enganalisis RTO dan RPO. Hasil yang dapat diperoleh dari analisis RTO dan RPO, akan menjadi landasan pengajuan rancangan sistem Data Guard. h. M erancang 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. M elakukan konfigurasi Data Guard pada primary database dan standby database. M eng-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 M etroNet dengan bandwidth 10 M bps. 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 M edica 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 M edica 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 EM C 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

M eskipun saat ini PT Anugrah Argon M edica masih menggunakan versi database Oracle 9.2.0.7, namun PT Anugrah Argon M edica 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 AM 2 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 :

4.5

o Sistem Operasi

: Windows XP service pack 2

o Versi Database

: Oracle 10.2.0.1.0

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 M edica 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 (DGM GRL) atau dengan menggunakan Oracle Enterprise Manager. Sesuai dengan kebutuhan PT Anugrah Argon M edica, 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 M edica 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 M edica menginginkan agar semua tipe data dan tabel yang berada dalam objek database dapat didukung oleh standby database.

•

PT. Anugrah Argon M edica juga menginginkan adanya integrasi antara Oracle Application Server yang sedang digunakan dengan standby database yang ada.

•

PT. Anugrah Argon M edica 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.

DB_UNIQUE_NAM E harus digunakan dari versi 10g ke atas.

Parameter

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_HOM E]\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_HOM E] pada direktori C:\> oracle\product\10.2.0\db_1.

4.

M embuat 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; SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 SIZE 50M; SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 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. DB_NAME='orcl' 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\ora data\orcl2' 17. LOG_FILE_NAME_CONVERT='C:\oracle\product\10.2 .0\oradata\orcl','C:\oracle\product\10.2.0\or adata\orcl2’ 1. 2.

Deskripsi dari initialization parameter yang digunakan dalam SPFILE untuk konfigurasi Data Guard untuk primary database adalah sebagai berikut :

146 Nama No.

Deskripsi parameter

1.

DB_NAME

Digunakan untuk mengidentifikasi nama primary database yang bernama ‘orcl’.

2.

DB_UNIQUE_N

Digunakan untuk mengidentifikasi nama database ‘orcl’.

AME 3.

LOG_ARCHIVE

Digunakan untuk mengidentifikasi berturut-turut nama

_CONFIG

primary (‘orcl’) dan standby database (‘orcl2’) yang digunakan dalam konfigurasi Data Guard.

4.

LOG_ARCHIVE

Parameter ini hanya berlaku jika menggunakan Oracle

_DEST_1

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_NAM E

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

Sama seperti penjelasan sebelumnya, namun di parameter

_DEST_2

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_NAM E

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

Digunakan untuk menjelaskan kondisi ketersediaan dari

_DEST_STATE

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

_1

nilainya ENABLED maka alamat tujuan ini dapat digunakan untuk operasi archiving berikutnya baik secara otomatis maupun manual.

7.

LOG_ARCHIVE

Digunakan untuk menjelaskan kondisi ketersediaan dari

_DEST_STATE

alamat tujuan archived log di standby database ‘orcl2’.

_2

Jika nilainya ENABLED maka alamat tujuan ini dapat digunakan untuk operasi archiving berikutnya baik secara otomatis maupun manual.

8.

LOG_ARCHIVE

Parameter ini digunakan jika database menggunakan redo

_FORMAT

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.

10.

LOG_ARCHIVE

Parameter ini mendeskripsikan jumlah proses ARCH

_MAX_PROCES

maksimum yang akan digunakan. Dalam ini sebanyak 10

SES

proses.

SERVICE_NAM

Parameter ini berisi nama service yang didukung oleh

ES

Oracle instance. Dalam hal ini ‘orcl’.

149 11.

STANDBY_ARC

Parameter ini berisi alamat tujuan standby database ‘orcl2’

HIVE_DEST

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

Parameter ini digunakan untuk menentukan apakah

E_MANAGEMEN

pengaturan data file berjalan secara manual atau otomatis

T

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

Parameter ini mendeskripsikan apakah Oracle akan

N_PASSWORDF

memeriksa password file dan berapa banyak database yang

ILE

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

Parameter ini digunakan untuk menkonversi nama sebuah

E_CONVERT

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

Parameter ini digunakan untuk menkonversi nama sebuah

ME_CONVERT

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> SQL> SQL> SQL>

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

Gambar 4.9 Enable ARCHI VELOG

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)

Gambar 4.14 Pengaturan Service Name (2 dari 5)

158 Host Name

: oracle

Port Number

: 1521

Ini adalah hostname dan nomor port dari listener yang digunakan

Gambar 4.15 Pengaturan Service Name (3 dari 5)

Service Name

: orcl2

Connection Type

: Database Default

159

Gambar 4.16 Pengaturan Service Name (4 dari 5)

Pengaturan telah selesai. Tekan tombol finish.

Gambar 4.17 Pengaturan Service Name (5 dari 5)

160 Simpan konfigurasi yang telah diubah tersebut dengan memilih dari menu File Æ Save Network Configuration M atikan 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. 2. 3. 4.

DB_NAME='orcl' DB_UNIQUE_NAME='orcl2' LOG_ARCHIVE_CONFIG='dg_config=(orcl,orcl2)' LOG_ARCHIVE_DEST_1='LOCATION=C:\oracle\produ ct\10.2.0\flash_recovery_area\ORCL2\archivel og 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\o radata\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 : Nama

No.

Deskripsi

parameter 1.

DB_NAME

Digunakan untuk mengidentifikasi nama primary database yang bernama ‘orcl’

2.

3.

DB_UNIQUE_N

Digunakan

untuk

mengidentifikasi

nama

AME

database ‘orcl2’

LOG_ARCHIVE

Digunakan untuk mengidentifikasi berturut-turut

_CONFIG

nama primary(‘orcl’) dan standby database (‘orcl2’) yang digunakan dalam konfigurasi Data Guard.

4.

LOG_ARCHIVE

Parameter ini hanya berlaku jika menggunakan

_DEST_1

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_NAM E 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

Sama seperti penjelasan sebelumnya, namun di

_DEST_2

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_NAM E 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 PRIM ARY_ROLE maka alamat

tujuan

hanya berlaku

ketika

database dijalankan dalam primary role. 6.

LOG_ARCHIVE

Digunakan

untuk

menjelaskan

kondisi

_DEST_STATE

ketersediaan dari alamat tujuan archived log di

_1

primary database ‘orcl’. Jika nilainya ENABLED maka alamat tujuan ini dapat digunakan untuk operasi archiving berikutnya baik secara otomatis maupun manual.

7.

LOG_ARCHIVE

Digunakan

untuk

_DEST_STATE

ketersediaan dari alamat tujuan archived log di

_2

standby

database

ENABLED

menjelaskan

‘orcl2’.

maka alamat

Jika tujuan

kondisi

nilainya ini dapat

digunakan untuk operasi archiving berikutnya baik secara otomatis maupun manual. 8.

LOG_ARCHIVE

Parameter

_FORMAT

menggunakan

ini

digunakan redo

log

jika dalam

database kondisi

ARCHIVELOG untuk mendeskripsikan format nama

dari

archived

redo

log.

Nilai

%s

memberikan nomor pada log sequence dan %t memberikan nomor pada thread.

9.

10.

11.

LOG_ARCHIVE

Parameter ini mendeskripsikan jumlah proses

_MAX_PROCES

ARCH maksimum yang akan digunakan. Dalam

SES

ini sebanyak 10 proses.

SERVICE_NAM

Parameter ini berisi nama service yang didukung

ES

oleh Oracle instance. Dalam hal ini ‘orcl2’.

STANDBY_ARC

Parameter ini berisi alamat tujuan standby

HIVE_DEST

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

Parameter ini digunakan untuk menentukan

E_MANAGEMEN

apakah pengaturan data file berjalan secara

T

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

Parameter ini mendeskripsikan apakah Oracle

N_PASSWORDF

akan memeriksa password file dan berapa banyak

ILE

database yang dapat menggunakan password file tersebut. Jika nilainya adalah EXCLU SIVE 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

Parameter ini digunakan untuk menkonversi

E_CONVERT

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\ini torcl2.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 M OUNT 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 Cu rrent

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

Maximum

Maximum

Protection

Availability

Performance

Proses Redo Archival

LGWR

LGWR

LGWR atau ARCH

Tipe Transmisi

SYNC

SYNC

SYNC atau ASYNC

Network

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 S yarat Standby Database Tipe data protection yang dikonfigurasi untuk PT. Anugrah Argon M edica 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 M edica, dilakukan langkah-langkah sebagai berikut : 1. Konfigurasi

parameter

LOG_ARCHIVE_DES T_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_D ES T_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 M edica. 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_D ES T_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_D ES T_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 M etode 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 M RP 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 DELA Y 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).

DGM GRL 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_NAM E) untuk primary database adalah orcl. • Database unique name (DB_UNIQUE_NAM E) untuk standby database adalah orcl2. • M enggunakan 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

DG_BROKER_CONFIG_FILE2.

dan

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 DGM GRL, 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

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

SHOW

179 4.

Mengatur Database Properties Setelah membuat konfigurasi dengan DGM GRL, 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; Pada primary database :

Gambar 4.38 Memeriksa Standby Redo Log pada Primary Database

Pada standby database :

Gambar 4.39 Memeriksa Standby Redo Log pada Standby Database

•

Pastikan property LOGXPTM ODE 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 FAS TS TARTFAILOVERTARGET •

Ubah mode proteksi menjadi M AXAVAILABILITY 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 DGM GRL. 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 M OUNT. SQL> SELECT OPEN_MODE FROM V$DATABASE; Jika standby database tidak berada dalam kondisi M OUNT maka standby database terlebih dahulu harus dimatikan SQL> SHUTDOWN IMMEDIATE; 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 S tatus 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:

M enandakan bahwa database ini adalah

standby database dan dapat melakukan switchover ke primary database. -

RECOVERY NEEDED: M enandakan 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: M enunjukkan 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: M enunjukkan 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. M atikan primary database dan lakukan STARTUP MOUNT SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT;

194 7. Lakukan verifikasi bahwa primary database telah beralih menjadi standby role. SQL> SELECT DATABASE_ROLE FROM V$DATABASE;

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”, M aka 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 M OUNT, maka buka physical standby database tersebut. SQL> ALTER DATABASE OPEN;

10. Lakukan verifikasi bahwa standby database telah beralih menjadi primary database role. SQL> SELECT DATABASE_ROLE FROM V$DATABASE;

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

Ten tu ka n je ni s s wi tch ov er

P hysi cal stan db y

P eri ksa a pa kah m asi h ad a se si ya ng a ktif

Ya

Switchover pada Physical standby Database

Ma tika n se si ya ng aktif

Ti da k

C ek a pa ka h pri ma ry d ata ba se i nstan ce su da h ter bu ka(OPE N) & stan db y da tab ase i nstan ce d i-m ou nt

o pe n pri ma ry da ta ba se ALTER DATAB ASE OPEN Mo un t stan db y da tab ase S HU TD OWN IMME DIATE STAR TUP M OU N T

tid ak

Ya Per iksa da ta ba se ro le d i d atab ase serv er SE LEC T D ATABA SE_R OLE FR OM V$D ATABA SE

STATUS la in

Ce k p ar ame ter LOG_ ARC H IV E _D EST_n

Ce k SWITC HOV ER_ STATUS d i pri mar y d ata ba se

SESS ION S_ ACTIVE

Gun aka n AL TE R DA TA BASE C OMMIT TO SWITC HOV ER TO PHYS IC AL STAN DB Y WITH S ESSION SH UTD OWN

TO_STAN D BY Ko nv ersi kan pri mary ke stan db y da tab ase rol e AL TER D ATABAS E COMMIT TO SWITCH OVER TO PH YSICA L STAN DB Y

Sh utdo wn pri mary d ata ba se SH UTD OWN IMMED IATE Mou n t a s a stan db y d ata ba se STAR TUP MOU NT

K on versi kan ph ysic al ke ne w pr ima ry da ta ba se ro le ALTER DATAB ASE COM MIT TO SWITC H OV ER TO PRIMA RY

Ap ak ah a da e rro r Ce k ap aka h p hys ica l sta nd by D B te rbu ka da la m mod e re ad -on ly

tid ak

Bu ka p hysi cal sta nd by DB de ng an ALTER DATAB ASE OP EN

tid ak

ya

E rror me ng en ai med ia reco ve ry sel esa ika n d en ga n R ECOV ER MA NAGED STAN DB Y DATABA SE

ya Shu tdo wn IMM EDIATE ph ysi cal sta nd by d atab as e STA RTUP p hy sica l stan db y da ta ba se SQL >S TA RTU P

Peri ksa d ata ba se ro le d i da tab ase serv er SEL EC T D ATABAS E_R OLE FR OM V$D ATABAS E R esta rt l og a pp ly s ervi ces

Kiri m red o d ata ke s ta nd by d ata ba se A LTER SYSTEM SWITCH LOGFILE

Ne w pr im a ry da taba se s iap digunak an

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. M emeriksa 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 M AXIM IZE PROTECTION atau M AXIMIZE 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 M AXIM IZE PERFORM ANCE 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 diarchive 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. SQL> SHUTDOWN IMMEDIATE; Jika dalam kondisi M OUNT, maka buka physical standby database tersebut. SQL> ALTER DATABASE OPEN;

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 menapply 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. M enggunakan 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. M embuat ulang database yang rusak dan menjadikannya sebagai standby database yang baru dengan menggunakan salinan backup dari primary database yang baru. c. M enggunakan Oracle Enterprise Manager atau perintah DGM GRL 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

FAILOV ER PA DA PHYS ICAL STANDB Y DATABAS E

F ailover pada physical standby D B

Ma ximize Performance

C ek prot ection mod e

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

C opy gap redo log yang te ridentifikasi ke Standby D B dan lakukan R egiste r deng an ALT ER DAT ABASE REGISTER PHYSIC AL LOGF ILE ‘namafile’

Ya Cek apa kah masih ada gap redo log deng an Query V$AR CHI VE_ GAP

tidak Cek redo log deng an sequence tertinggi di standby DB d engan q uery V$ARC HIVED _LOG

Maximize Pro tection atau MAXIMIZ E AVAILABILITY d engan LGWR

Cek apakah a da redo log di p rimary yang seq uencenya lebih tinggi dari stan dby DB ya tida k C opy redo log tersebut ke stan dby DB dan register kemb ali deng an ALT ER D ATABASE REGIST ER PHYSIC AL LOGFILE ‘nam afile’

Query V$AR CHIVE_GAP da n pastikan tida k ad a gap an tara redo log d i standb y D B Initiate failover & matika n pro ses yang sedan g aktif pada ph ysica l standb y D B denga n ALTER DAT ABASE RECOVER MAN AGED STAN DBY D AT ABASE FI NISH F ORCE Konversikan physical standby D B ke primary role ALT ER D ATABASE COMM IT T O SWIT CHOVER T O PRIMAR Y

Buka physical standby D B denga n ALTER DAT ABASE OPEN

tidak

Ce k ap aka h physical sta ndby DB terbuka

Ya

Shutdo wn IMM EDIAT E physical stan dby DB

Backup new primary data base

START UP p hysica l standb y D B

Backup new primary dat abase Ne w p rim ary da tab ase sia p d igu na kan

OPT IONAL Restore prima ry datab ase lama yang rusak dengan F LASHBACK, DGMGRL a tau re -crea te ulang

 

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

Gambar 4.60 Proses Fast-Start Failover (2 dari 5)

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 READWRITE. 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.

Gambar 4.61 Proses Fast-Start Failover (3 dari 5)

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;

 

Gambar 4.62 Proses Fast-Start Failover (4 dari 5)

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 dipending segera dilakukan untuk sinkronasi data.

Gambar 4.63 Proses Fast-Start Failover (5 dari 5)

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; Pada primary database :

Gambar 4.64 Periksa Atribut Primary Database

Pada standby 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$M ANAGED_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 (CLO SING). 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; Pada primary database :

Gambar 4.68 Periksa Level Sinkronisasi pada Primary Database

Pada standby database :

Gambar 4.69 Periksa Level Sinkronisasi pada Standby Database

214 Pastikan bahwa jumlah sequence dan posisi thread yang di-archive dan diapply 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 RECO VERY_M ODE dari V$ARCHIVE_DEST_STATUS di standby database. Nilai yang ada seharusnya adalah M ANAGED REAL TIM E 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 Pada primary database :

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

Pada standby 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 sequencesequence 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 S udah 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  

 

Pada primary database :

Gambar 4.77 Periksa Kondisi Oracle Data Guard Pada Primary Database

221 Pada standby database :

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 M edica. Penjadwalan rencana implementasi dari sistem Data Guard yang telah dirancang ditunjukkan pada tabel berikut. Minggu Aktivitas 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 M inggu 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 M inggu 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 S istem Perbandingan antara sistem availability PT Anugrah Argon M edica yang

sedang berjalan dengan sistem yang diusulkan berdasarkan penanganan dan waktu yang dibutuhkan untuk recovery adalah sebagai berikut :

Penanganan & Lama Waktu Recovery No.

Tipe Gangguan Sistem yang sedang berjalan

1

Sistem yang diusulkan

Database Server

DBA harus mencari penyebab

Fast-Start Failover dan

down

down, dan melakukan recovery

Fast Connection

manual.

Failover.

Waktu Recovery:

Waktu Recovery:

Satuan jam

< 5 menit

224 2

3

Kerusakan pada

M engganti disk yang rusak terlebih

Fast-Start Failover dan

disk storage server

dahulu, setelah itu data bisa

Fast Connection

kembali diakses.

Failover.

Waktu Recovery:

Waktu Recovery:

Satuan jam

< 5 menit

Kerusakan pada

Tidak ada penanganan, sehingga

Sinkronisasi database

disk dimana ada file

file menjadi tidak terselamatkan.

dengan Real Time Apply.

System

M enggunakan Standby Server

Switchover Role

Maintenance atau

untuk menggantikan Primary

Transition.

System Upgrade

Server.

Waktu Recovery:

Waktu Recovery: 2 Jam

< 5 menit

Kerusakan data

Belum ada penanganan, proses

Standby Database, Fast-

center akibat

bisnis terhenti total, data yang

Start Failover dan Fast

bencana

terselamatkan hanyalah data yang

Connection Failover.

telah di-backup.

Waktu Recovery:

yang belum sempat di backup 4

5

< 5 menit 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

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 M edica. •

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 M edica 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. M aka 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 M edica. Berdasarkan analisis transaksi pada bagian 3.7.2 yang membahas kerugian pendapatan akibat ketidaktersediaan sistem, maka dapat dilihat bahw a kemungkinan kerugian terbesar yang akan dialami PT. Anugrah Argon M edica adalah apabila perusahaan sedang berada pada masa peak transaction di akhir bulan. Dapat digambarkan pada gambar berikut : 120000 100000 80000 60000 40000 20000 0 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 M edica sudah mengalami 8 kali system down yang mengakibatkan proses bisnis terhambat. Sehingga dapat diperkirakan probabilitas kejadian system down dalam 1 bulan adalah :

228

8 8 1 = = (6 x12 ) 72 9

Dalam perhitungan persentase adalah :

1 x 100% = 11,11% 9

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 berban ding 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. M elalui perancangan prototipe ini, PT Anugrah Argon M edica dapat memiliki pertimbangan untuk meningkatkan sistem availability-nya, menjadi sistem high availability dengan Oracle Data Guard.