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
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.
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.
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
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 :
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 :
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 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 :
• 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
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 :
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;
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.
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\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’
Deskripsi dari initialization parameter yang digunakan dalam SPFILE untuk konfigurasi Data Guard untuk primary 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 ‘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_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
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_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.
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’.
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
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.
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;
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 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\
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#;
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 –
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 :
Gambar 4.13 Pengaturan Service Name (1 dari 5)
Protocol : TCP/IP (Internet Protocol)
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
Gambar 4.16 Pengaturan Service Name (4 dari 5)
Pengaturan telah selesai. Tekan tombol finish.
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. 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\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'
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 :
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
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 _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_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
online redo log. Jika nilainya PRIM ARY_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
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 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 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'
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;
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.
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 :
Gambar 4.23 Flow Chart Pembuatan Physical Standby Database
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 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
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;
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;
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;
Alur konfigurasi tipe data protection dapat diwakilkan oleh diagram berikut :
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
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 :
• 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.
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
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;
4. Mengatur Database Properties
Setelah membuat konfigurasi dengan DGM GRL, property database dapat dilihat dengan perintah :
DGMGRL> SHOW DATABASE VERBOSE [nama database];
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
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 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’;
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 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.
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;
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;
• 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 :
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.
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
Jika terjadi gangguan pada database, maka dapat digambarkan dalam bentuk diagram seperti dibawah ini.
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.
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
- 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
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;
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
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 :
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
Ce k SWITC HOV ER_ STATUS d i
pri mar y d ata ba se
STATUS la in
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 Ce k p ar ame ter LOG_ ARC H IV E _D EST_n TO_STAN D BY 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 SESS ION S_ ACTIVE
Swi tchover pada
Physical standby Database
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
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
STA RTUP p hy sica l stan db y da ta ba se
SQL >S TA RTU P
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 Shu tdo wn IMM EDIATE ph ysi cal sta nd by d atab as e
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 Bu ka p hysi cal sta nd by DB de ng an ALTER DATAB ASE OP EN tid ak ya Ten tu ka n je ni s s wi tch ov er
P eri ksa a pa kah m asi h ad a se si ya ng a ktif P hysi cal stan db y Ti da k Ya Ma tika n se si ya ng aktif 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
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
Ya
Ap ak ah a da
e rro r
tid ak
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
ya
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;
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
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;
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.
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 :
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. 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).
Alur konfigurasi pengaturan failover pada physical standby database dapat diwakilkan oleh diagram berikut :
F ailover pada physical standby D B
C ek prot ection
mod e
Maximize Pro tection atau
MAXIMIZ E AVAILABILITY d engan LGWR Ma ximize
Perfor mance
C opy gap r edo 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’
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
Konver sikan physical standby D B ke primar y role ALT ER D ATABASE COMM IT T O
SWIT CHOVER T O PRIMAR Y
Shutdo wn IMM EDIAT E physical stan dby DB
START UP p hysica l
standb y D B
Restor e pr ima ry datab ase lama yang r usak dengan F LASHBACK, DGMGRL
a tau re -crea te ulang
Ce k ad a Gap di red o lo g standby DB de ngan
Query V$AR CHIVE_ GAP
Cek apa kah masih ada gap redo log deng an Query V$AR CHI VE_ GAP Ya
tidak
Cek r edo log deng an sequence ter tinggi di
standby DB d engan q uery V$ARC HIVED _LOG
Cek apakah a da
redo log di p rimar y yang seq uencenya
lebih tinggi dar i stan dby DB
C opy redo log tersebut ke stan dby DB dan r egister kemb ali deng an
ALT ER D ATABASE REGIST ER PHYSIC AL LOGFILE ‘nam afile’ ya
tida k
Query V$AR CHIVE_GAP da n pastikan tida k ad a gap an tara r edo log d i standb y D B
Ce k ap aka h physical
sta ndby DB ter buka Ya
Buka physical standby D B denga n ALTER
DAT ABASE OPEN
tidak Backup new pr imary
data base
Backup new pr imary dat abase
Ne w p rim ary da tab ase sia p d igu na kan OPT IONAL FAILOV ER PA DA
PHYS ICAL STANDB Y DATABAS E
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
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
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
