ANALISA PERANCANGAN DAN UJI KINERJA SISTEM DRP DENGAN TEKNOLOGI RAC DAN DATA GUARD MENGGUNAKAN METODE SINGLE INSTANCE PHYSICAL STANDBY DATABASE

TEKNOLOGI RAC DAN DATA GUARD MENGGUNAKAN METODE SINGLE INSTANCE PHYSICAL STANDBY DATABASE

Laporan Tugas Akhir

Diajukan Sebagai Salah Satu Syarat Untuk Memperoleh Gelar Sarjana Satu (S1) Pada Fakultas Ilmu Komputer Program Studi

Teknik Informatika

Oleh :

GUGUN GUNAWAN 01501 - 035

PROGRAM STUDI TEKNIK INFORMATIKA

FAKULTAS ILMU KOMPUTER

UNIVERSITAS MERCU BUANA

2008

DRP (Disaster Recovery Plan) adalah sebuah sistem yang dapat

menangani/mencegah terjadinya kerusakan dan kehilangan data, Real Application

Cluster dan Oracle Data Guard merupakan dua teknologi effektif dari Oracle DRP untuk memberikan perlindungan asset/data pada korporat, dan dapat

membuat data tersedia dalam waktu 24 x 7 x 365 serta mencegah terjadinya kerusakan/kehilangan data tersebut dan menjamin ketersediaan data (High

Availability) kapanpun kita perlukan.

Tujuan dari laporan penelitian ini adalah untuk membangun High

Availability System yang mampu menangani disaster recovery menggunakan Oracle RAC dan Oracle Data Guard dengan Physical Standby Database sehingga

didapatkan waktu downtime seminimal mungkin ( < 5 menit ) dan waktu proses

transfer data seminimal mungkin.

Metodologi yang digunakan dalam melakukan penelitian adalah melakukan analisa kebutuhan sistem DRP yang diperlukan untuk menangani user

requirement yang telah ditetapkan berupa waktu downtime untuk yang

direncanakan maupun tidak direncanakan. Kemudian penulis merancang arsitektur sistem DRP/DRC serta mengimplementasikannya kedalam sistem tersebut.

Pengujian dilakukan dengan menggunakan dua buah skenario yaitu pengujian pada kondisi darurat I ( Sistem Komputer/RAC Node ), dimana ptada kondisi darurat seperti ini diasumsikan salah satu node dari RAC mengalami

dengan menggunakan node lainnya yang tidak mengalami kerusakan. Sementara akses ke server aplikasi dan server database masih menggunakan Primary Site. Dan pengujian pada kondisi darurat II ( Sistem Komputer/2 RAC Node ), dimana pada kondisi darurat ini diasumsikan Server Database yang ada di lingkungan

Primary site tidak dapat diakses/digunakan. Sehingga kegiatan operasional akan

dilaksanakan oleh user dengan menggunakan backup server database yang telah disiapkan di DRC-Site. Dari sisi sistem aplikasi komputer yang ada akan dilakukan proses failover untuk memindahkan bisnis operasional dari primary site ke backup site.

Dari seluruh rangkaian uji kinerja RAC dan Data Guard yang telah dilakukan maka penulis mendapatkan kesimpulan, dengan arsitektur ini penulis mendapatkan 2 nilai waktu downtime, baik yang direncanakan maupun tidak direncanakan kurang dari maksimal downtime (5 menit) yang telah ditetapkan dengan rata-rata downtime untuk kerusakan salah satu node adalah 2,5 detik, sebenarnya ini dapat diasumsikan tidak ada downtime dikarenakan dilakukan proses pengujian secara manual untuk melihat downtime yang terjadi. Dan rata-rata downtime untuk kerusakan dua buah node dimana proses transaksi di failover ke standby site/database adalah 3,5 detik.

Dengan arsitektur ini didapatkan proses pengiriman log file ke standby database dengan rata-rata berukuran 20 MB memerlukan waktu < 20 detik.

DRP ( Disaster Recovery Plan) is a system able to handle / preventing the happening of data loss and damage, Real Application Cluster and Oracle Data Guard represent two effektif technology from Oracle DRP to give protection of asset / data at corporate, and can make data available in time 24 x 7 x 365 and also prevent the happening of damage / losing of the data and guarantee the availibility of data ( High Availability) whenever us need.

Intention of this research report is to develop/build High Availability System capable to handle recovery disaster use Oracle RAC and Oracle Data Guard with Physical Standby Database so that got downtime time as minimum as possible ( < 5 minute ) and time process the transfer of data as minimum as possible.

Methodologies which used in doing/conducting research is to analyse requirement of needed to DRP system handle requirement user which have been specified in the form of downtime time for the things planned and also do not be planned. And then writer design DRP/DRC system architecture and also implementation into the system.

Examination conducted by using two scenario that is examination at condition of emergency I ( System Computer / Node RAC ), where this condition of emergency like this assumed one of the node from one of RAC is damage / down so that operational activity will remain to be executed by user by using other node which do not experience of damage. For a while access to application

emergency II ( System Computer / 2 RAC Node ), where at condition of this emergency is assumed Server Database exist in Primary site environment cannot be accessed / to be used. So that operational activity will be executed by user by using backing up database server which have been prepared in DRC-SITE. From existing computer application system side will to process failover to remove operational business from site primary to backing up site.

From entire/all network test RAC performance and Data Guard which have been conducted writer get conclusion, with this architecture writer get 2 downtime time value, both for planned and also do not be planned maximal less than downtime ( 5 minute) which have been specified with downtime mean for the damage of one of the node is 2.5 second, in fact this can be assumed there no downtime because to process examination manually to see downtime that happened. And downtime mean for the damage of two node where transaction process in failover to site standby / database is 3.5 second.

With this architecture is got by process delivery of archive log to database standby with fairish mean 20 MB need time < 20 second.

LEMBAR PERNYATAAN

Yang bertanda tangan di bawah ini :

Nama : GUGUN GUNAWAN NIM : 01501 – 035

Menyatakan bahwa Tugas Akhir ini adalah hasil buatan sendiri, bukan hasil dari duplikasi kecuali yang tercantum di dalam daftar pustaka.

Jakarta, Juli 2008

LEMBAR PENGESAHAN

NAMA : GUGUN GUNAWAN

NIM : 01501-035

FAKULTAS : ILMU KOMPUTER

JURUSAN : TEKNIK INFORMATIKA

Yang bertanda tangan di bawah ini menyatakan bahwa Laporan Tugas Akhir dari mahasiswa tersebut diatas, dengan judul :

ANALISA PERANCANGAN DAN UJI KINERJA SISTEM DRP DENGAN TEKNOLOGI RAC DAN DATA GUARD MENGGUNAKAN

METODE SINGLE INSTANCE PHYSICAL STANDBY DATABASE

telah diperiksa dan disetujui sebagai Laporan Tugas Akhir.

Disetujui oleh,

(Devi Fitrianah, S.Kom, MTI) Dosen Pembimbing I

(Abdusy Syarif, ST, MT) Dosen Pembimbing II

Mengetahui,

(Abdusy Syarif, ST, MT) Ketua Program Studi

Teknik Informatika

(Devi Fitrianah, S.Kom, MTI) Koordinator Tugas Akhir

KATA PENGANTAR

Assalamualaikum Wr. Wb.

Dengan memanjatkan puji syukur akan kehadirat Allah SWT, yang telah memberikan rahmat dan karuniaNya sehingga Penulis dapat menyelesaikan penulisan Laporan Tugas Akhir ini tanpa terjadi aral yang melintang. Laporan ini dibuat sebagai dokumentasi dari hasil pelaksanaan Tugas Akhir dan sebagai salah satu persyaratan untuk menempuh program studi Strata Satu (S1) pada jurusan Teknik Informatika Universitas Mercu Buana.

Dalam penyusunan laporan Kerja Praktek ini, dengan segala keterbatasan yang ada Penulis sadar bahwa Laporan Tugas Akhir ini tidak akan segera rampung tanpa adanya bantuan, bimbingan dan dorongan dari berbagai pihak. Untuk itu dengan segala kerendahan hati Penulis ucapkan terima kasih kepada : 1. Ayah dan Ibu tercinta, dengan penuh keikhlasan dan cinta kasih yang tulus

memberikan segala macam bentuk dukungan yang sangat berarti untuk Penulis hingga yang di cita – cita kan dapat segera terwujud.

2. Kakak dan adikku tercinta yang telah memberikan masukan – masukan yang berarti dari awal kuliah hingga sekarang.

3. Ibu Devi Fitriana, ST, MT, selaku dosen Pembimbing I Tugas Akhir

4. Bapak Abdusy Syarif, ST, MT, selaku dosen Pembimbing II Tugas Akhir dan selaku Ketua Program Studi Teknik Informatika.

5. Bapak dan Ibu Dosen yang telah memberikan ilmunya selama Penulis menempuh perkuliahan di Universitas Mercu Buana.

6. Sahabat – sahabat dekat Penulis, Herry, Dede, Fitra, Edward, Wawan, Iffa,Vivilia dan lainnya yang telah memberikan warna segar dan baru dalam mejalankan Perkuliahan di Universitas Mercu Buana.

7. Rekan – rekan Mahasiswa Teknik Informatika angkatan 2001 yang telah memberikan ilmunya dari awal perkuliahan hingga sekarang.

8. Seluruh member dari Forum Mercubuana-IT, dimana kita saling berbagi ilmu dalam dunia maya.

9. Amanda Budiasih yang telah memberikan semangat dan tegurannya selama ini, kamulah inspirasiku.

Demikian Laporan Tugas Akhir ini disusun, semoga manfaat yang besar dari isi yang terkandung di dalam Laporan Tugas Akhir ini dapat dirasakan oleh Penulis khususnya dan pihak – pihak yang membutuhkan pada umumnya.

Akhir kata, Penulis sadar akan kekurangan dalam penyusunan Laporan Tugas Akhir ini. Pada kesempatan ini Penulis membuka diri untuk menerima masukan saran dan kritik yang dapat membangun untuk kemajuan Penulis untuk berkarya lebih baik dalam penulisan laporan lainnya di masa mendatang.

Jakarta, Juli 2008

DAFTAR ISI

LEMBAR PERNYATAAN……… i

LEMBAR PENGESAHAN……… ii

KATA PENGANTAR …..………. iii

DAFTAR ISI ……….. v

DAFTAR GAMBAR...……… viii

DAFTAR TABEL....……… xi

DAFTAR ISTILAH….……… xii

BAB I PENDAHULUAN……… 1 1.1 Latar Belakang……….……… 1 1.2 Identifikasi Masalah ...……… 2 1.3 Batasan Masalah …….……… 3 1.4 Tujuan Penelitian ……...………. 3 1.5 Metode Penelitian ...……… 4 1.6 Sistematika Penulisan ………. 4

BAB II LANDASAN TEORI ……….…. 6

2.1 Pengertian DRP ( Disaster Recovery Plan ………. 6

2.2 Pengertian Availability ……… 7

2.3 Alasan Downtime ……… 9

2.4 Jenis – jenis High Availability Recovery ……… 10

2.5 MAA dengan RAC dan Data Guard ………... 13

2.7 Struktur Database Oracle ………... 15

2.7.1 Struktur Logikal …………..……… 15

2.7.2 Sruktur Physical ……….. 16

2.8 Struktur Instance ……….………. 16

2.9 Proses Background ……….. 19

2.10 Oracle Data Guard ………. 20

2.11 Standby Database ……… 20

2.11.1 Physical Standby Database ………..….. 21

2.11.2 Logical Standby Database ……….……… 22

2.12 Data Guard Services ………. 23

2.12.1 Redo Transport Services ……… 24

2.12.2 Log Apply Services ………. 24

2.12.3 Role Transitions ……….. 25

2.13 Keuntungan/kelebihan Data Guard ……… 26

2.14 Oracle Real Application Cluster ..………... 27

2.15 Integrated Clusterware Management ……… 28

2.16 Single System Image Management ……… 29

2.17 Automatic Workload Management ...……… 30

2.18 Workload Monitoring …..……….. 31

2.19 Fast Connection Fail-Over ……… 31

BAB III ANALISA KEBUTUHAN DAN PERANCANGAN SISTEM DRP DENGAN TEKNOLOGI RAC DAN DATA GUARD ……….. 32

3.2 Perancangan arsitektur sistem RAC dan Data Guard …... 37 3.2.1 Standar Operasi Penanggulangan Keadaan Darurat … 40 BAB IV IMPLEMENTASI DAN PENGUJIAN ………... 43

4.1 Instalasi Oracle RAC ….……..……….………….. 43 4.1.1 Konfigurasi Raw Device pada Shared Storage ……. 44 4.1.2 Instalasi Clusterware ………. 47 4.1.3 Instalasi Database Engine ………. 54 4.1.4 Membuat Database ……… 56 4.2 Membuat Single Instance Physical Standby untuk RAC …. 63

4.2.1 Mengumpulkan file untuk melakukan backup …… 63 4.2.2 Konfigurasi Net Service pada Standby Database …. 64 4.2.3 Membuat Physical Standby Database ………. 65 4.2.4 Konfigurasi Primary Database untuk Data Guard .. 68 4.2.5 Verifikasi Konfigurasi Data Guard ………. 69 4.3 Skenario Pengujian ………. ……… 70 4.3.1 Pengujian Keadaan Darurat I ……….. 71 4.3.1.1 Mengaktifkan instance RAC per node ……. 71 4.3.1.2 Mengaktifkan/mematikan RAC Database ... 72 4.3.1.3 Pengujian TAF ………. 72 4.3.2 Pengujian Keadaan Darurat II ………. 77 4.3.2.1 Pengujian fail over secara manual ……….. 78 4.3.3 Pengujian Proses Transfer File Archive Log …….. 83

BAB V PENUTUP………. 85 5.1 Kesimpulan……….. 85 5.2 Saran………. 86 DAFTAR PUSTAKA

DAFTAR GAMBAR

Gambar 2.1. Skema DRP untuk perancangan High Availability ………. 7 Gambar 2.2. Arsitektur Database Oracle …..……… 14 Gambar 2.3. Struktur logical oracle ……….. 15 Gambar 2.4. Konfigurasi Tipikal Data Guard ……… 23 Gambar 2.5. Update otomatis pada physical standby database ………… 25 Gambar 2.6. Manajemen clusterware terintegrasi pada RAC ………… 28 Gambar 2.7. Single system image Cluster Database untuk Oracle RAC .. 30 Gambar 3.1. Arsitektur RAC dan Data Guard ……….………. 37 Gambar 3.2. Kondisi keadaan darurat I ...………. 41 Gambar 3.3. Kondisi keadaan darurat II …………...……….. 42

DAFTAR TABEL

Tabel 2.1. Penyebab downtime ……….. 9 Tabel 2.2. Perbandingan jenis-jenis recovery ..………... 10 Tabel 2.3. Solusi Oracle High availability untuk downtime tidak direncanakan

dengan menggunakan RAC dan Data Guard ……… 13 Tabel 2.4. Solusi Oracle High availability untuk downtime direncanakan

dengan menggunakan RAC dan Data Guard ……… 13

Tabel 2.5. Waktu downtime yang diperlukan untuk kerusakan tidak

direncanakan ………..……… 14

Tabel 2.6. Waktu downtime yang diperlukan untuk kerusakan yang

direncanakan ………..……… 14

Tabel 3.1. Penyebab dan maksimal downtime yang ditetapkan user … 33 Tabel 3.2. Solusi Oracle High availability untuk downtime tidak direncanakan

dengan menggunakan RAC dan Data Guard ………. 34 Tabel 3.2. Solusi Oracle High availability untuk downtime direncanakan

dengan menggunakan RAC dan Data Guard ………. 34

Tabel 3.4 Waktu downtime yang diperlukan untuk kerusakan tidak direncanakan ………. 36

Tabel 3.5 Waktu downtime yang diperlukan untuk kerusakan yang direncanakan ……….. 36

Tabel 4.1 Tabel perbandingan waktu downtime darurat I ……... 77

Tabel 4.2 Tabel perbandingan waktu downtime darurat II ……... 82

BAB I PENDAHULUAN

1.1 Latar Belakang

Kelangsungan bisnis dan perlindungan kerusakan merupakan prioritas utama pada level manajemen senior pada setiap korporat.

Kerusakan data adalah sebuah permasalahan kritis bagi korporat yang berarti kerugian secara materi maupun pencitraan akibat terjadinya downtime pada sistem yang ada.

DRP (Disaster Recovery Plan) adalah sebuah sistem yang dapat

menangani/mencegah terjadinya kerusakan dan kehilangan data, Real Application

Cluster dan Oracle Data Guard merupakan dua teknologi effektif dari Oracle DRP untuk memberikan perlindungan asset/data pada korporat, dan dapat

membuat data tersedia dalam waktu 24 x 7 x 365 serta mencegah terjadinya kerusakan/kehilangan data tersebut dan menjamin ketersediaan data (High

Availability) kapanpun kita perlukan.

Oracle RAC merupakan suatu lingkungan komputasi yang memanfaatkan interkoneksi antar komputer dengan menggunakan teknologi cluster. Dengan hal tersebut maka dapat memberikan skalabilitas tidak terbatas dan juga tingkat ketersediaan yang tinggi bagi aplikasi apapun. Ini bisa dicapai dengan memanfaatkan konfigurasi hardware secara cluster berkat kemudahan dalam penggunaan single system image. Oracle RAC mengijinkan akses ke dalam

single database dari beberapa instance dalam suatu konfigurasi yang ter-cluster.

Semua instance membaca satu physical database (yang lokasinya di shared

storage), client session dilayani oleh semua instance tersebut dengan metode load balancing. Tujuan RAC adalah High Availability, pada saat salah satu atau dua

dari instance tersebut mati/down, masih ada satu instance yang menerima client

session.

Data guard memberikan solusi recovery kerusakan data secara efisien

dengan mengatur penggandaan transaksi dari primary database ke standby

database secara remote. Standby database menjamin bahwa data yang dimiliki

tidak akan hilang ketika pada data terjadi kegagalan. Ketika primary database mengalami gangguan, maka koneksi aplikasi dapat dipindahkan ke standby

database yang sudah disiapkan. Selama primary database dalam perbaikan, maka

semua pemakai aplikasi masih dapat melakukan transaksi secara normal menggunakan standby database.

High Availability system merupakan pengaturan (management),

pengawasan (monitoring), dan perangkat software otomasi yang membuat, merawat, dan memonitor satu atau lebih standby database untuk melindungi data korporasi dari kegagalan, kehilangan, kesalahan, dan kerusakan.

1.2 Identifikasi Masalah

Semakin bertambahnya jumlah data serta semakin banyak dan kompleknya transaksi data yang di tangani oleh database server dimana ketersediaan data selama 24 jam menjadi sebuah keharusan dan kerusakan data

sekecil apapun yang mengakibatkan downtime yang lama tidak dapat ditolerir, sehingga penggunaan sistem recovery manager (backup dan restore) tidaklah cukup. Salah satu kemampuan dari teknologi RAC dan Data Guard adalah dapat melakukan disaster recovery secara cepat dan akurat, sehingga user/sistem dapat terus melakukan transaksi tanpa mengalami gangguan yang berarti.

1.3 Batasan Masalah

Batasan masalah yang akan dibahas adalah merancang sistem DRP dengan menggunakan Oracle Real Application Cluster dan Oracle Data Guard

System berupa Standby Database Server dan melakukan uji kinerja performa dari High Availability System tersebut dalam menangani DRP serta melakukan analisa

dari hasil uji kinerja tersebut berdasarkan acuan dari proses administrasi RAC dan Data Guard.

1.4 Tujuan Penelitian

Tujuan dari laporan Tugas Akhir ini adalah untuk membangun High

Availability System yang mampu menangani disaster recovery menggunakan Oracle RAC dan Oracle Data Guard dengan Physical Standby Database dan

melakukan uji kinerja High Availability System tersebut sebagai solusi yang dapat digunakan dalam membangun sebuah sistem yang high availability yang dikelola oleh Database Administrator.

1.5 Metode Penelitian

Adapun tahapan metode penelitian yang digunakan Penulis adalah sebagai berikut :

1. Studi literatur dan perpustakaan, dilakukan dengan membaca buku-buku yang berkaitan dengan permasalahan yang dibahas khususnya yang berkaitan dengan Oracle Data Guard dan Oracle RAC.

2. Mengumpulkan data – data yang tekait dengan sistem Standby Database

Server menggunakan Physical Standby Database dan Oracle RAC

3. Merancang dan membangun sistem DRP yang High Availability dengan menggabungkan teknologi RAC dan Data Guard.

4. Melakukan pengujian kinerja setelah sistem yang dibangun diyakini sudah benar dan memberikan hasil pengujian dan kesimpulan yang didapatkan.

1.6 Sistematika Penulisan

Di dalam penyusunan Laporan Tugas Akhir ini Penulis telah membagi Laporan ini ke dalam beberapa bab dan disusun dengan sistematika penulisan sebagai berikut :

BAB I : PENDAHULUAN

Pada bab ini akan diuraikan mengenai latar belakang, identifikasi masalah, batasan masalah, tujuan penelitian, metode penelitian dan sistematika penulisan.

BAB II : LANDASAN TEORI

Pada bab ini akan di jelaskan mengenai apa yang menjadi landasan dari teori – teori yang digunakan Penulis untuk menyelesaikan permasalahan pada Laporan Tugas Akhir ini. BAB III : ANALISA KEBUTUHAN & PERANCANGAN SISTEM DRP

DENGAN TEKNOLOGI RAC DAN DATA GUARD

Pada bab ini akan dilakukan analisa kebutuhan untuk perancangan dan membangun sistem DRP yang High Availability beserta konfigurasi yang diperlukan dalam pembuatan RAC,

primary database dan standby database,

BAB IV : IMPLEMENTASI DAN PENGUJIAN

Pada bab ini penulis akan melakukan implementasi dan pengujian mengenai disaster recovery system yang dijalankan dengan teknologi RAC dan Data Guard menggunakan standby

database server.

BAB V : PENUTUP

Pada bab ini akan berisi mengenai kesimpulan – kesimpulan dari hasil pengujian yang telah dilakukan dan saran – saran yang dapat digunakan dikemudian hari dalam melakukan penelitian yang sama.

BAB II LANDASAN TEORI

2.1 Pengertian DRP (Disasters Recovery Plan)

Disasters Recovery Plan, adalah metode/rencana yang diterapkan/disusun

apabila terjadi hal-hal yang tidak diinginkan terjadi pada database atau mesin tempat menyimpan data, sehingga menimbulkan kerusakan atau bahkan hilangnya data pada database kita. Hal-hal yang tidak diinginkan tersebut bisa bermacam-macam, misalnya data terhapus, mesin tempat menyimpan database rusak, kebakaran pada ruang tempat menyimpan mesin database, bencana alam dan lain sebagainya. Sebelum kita membuat metode/rencana yang akan digunakan dalam mengimplementasikan DRP ini, ada beberapa hal yang harus diperhatikan berkaitan dengan hal ini. Hal-hal yang harus diperhatikan tersebut antara lain :

1. Buat suatu list yang yang diurutkan berdasarkan tingkat availability dari semua database yang ada dalam mesin/server.

2. Bedakan lokasi tempat menyimpan mesin/database/backup dengan lokasi tempat menyimpan mesin/database yang sedang running.

3. Pilih metode yang terbaik untuk metode DRP ini, disesuaikan dengan semua resources yang ada, kalau memang tidak bisa mengeluarkan anggaran tambahan untuk implemetasi DRP ini.

4. Lakukan simulasi metode DRP yang telah ditetapkan. 5. Lakukan pengecekkan metode DRP secara berkala.

Gambar 2.1 Skema DRP untuk perancangan High Availability [Referensi:Oracle 10g Online Documentation,2006]

2.2 Pengertian Availability

Availability adalah suatu kondisi dimana suatu aplikasi, layanan, atau fungsi

tersedia pada saat user/pemakai membutuhkannya. Reliability, recoverability,

timely error detection, dan continuous operations adalah karakterisitik utama

pada solusi high availability.

1. Reliability, reliable software termasuk database dan aplikasi merupakan

komponen utama untuk mengimplementasikan solusi high availability. 2. Recoverability, begitu banyak pilihan untuk melakukan recover pada

saat terjadi kegagalan sistem. Sangat penting untuk menentukan tipe kesalahan/kegagalan yang mungkin terjadi pada perangkat sistem kita, dan bagaimana untuk memperbaiki kegagalan tersebut. Contoh, jika tabel kritis terhapus dari database, tindakan apa yang akan diambil

D Doowwnnttiimmee d diirreennccaannaakkaa n n D Doowwnnttiimmee T Tiiddaakk d diirreennccaannaakkaann P Peerraawwaattaann R Ruuttiinn O OppeerraassiiRRuuttiinn K Keessaallaahhaann m maannuussiiaa K Keerruussaakkaann d daattaa K Keerruussaakkaann s siisstteemm U UppggrraaddeeHH//WW&& S S//WW B Baacckkuupp M Meenngghhaappuussddaattaa D DaattaaCCoorrrruupptt S SiisstteemmCCrraasshh

untuk memperbaikinya? Apakah arsitektur sistem kita memiliki kemampuan untuk memperbaiki sesuai dengan Service Level Agreement

(SLA)?

3. Timely error detection, jika sebuah komponen pada arsitektur sistem mengalami kegagalan, kemudian pendeteksian yang cepat merupakan hal yang penting dalam menangani kegagalan tersebut. Jika kita membutuhkan waktu sampai dengan 90 menit untuk mengetahui dan memperbaiki kegagalan tersebut, kemudian hal tersebut tidaklah sesuai dengan SLA yang ada, maka penggunaan sebuah sistem yang dapat memonitoring kondisi dari database dan memberikan peringatan kepada DBA sangatlah penting.

4. Continous operations, akses yang berkelanjutan kepada data adalah

penting disaat aktivitas/proses tidak boleh mengalami downtime. Proses seperti memindahkan tabel ke tempat lain antar database, atau bahkan menambahkan CPU kedalam perangkat kita, dapat dilakukan pada saat user terus beraktifitas bila kita menggunakan arsitektur yang high

availability.

Lebih spesifik lagi bahwa high availability architecture haruslah memiliki sifat-sifat:

1. Kecepatan deteksi kesalahan/kegagalan dari suatu sistem. 2. Perbaikan yang cepat.

3. Operasi perbaikan yang otomatis. 4. Melindungi dari kehilangan data.

2.3 Alasan Downtime

Salah satu cara dalam merancang sistem yang high availability adalah menguji dan memetakan semua kemungkinan penyebab dari downtime. Ini sangat penting untuk mempertimbangkan penyebab/alasan dari downtime yang direncanakan maupun tidak direncanakan saat merancang sebuah sistem agar mampu mengangani kemungkinan tersebut.

Tabel 2.1 Penyebab downtime

Kategori Tipe Deskripsi Contoh Tidak direncanakan Kerusakan

komputer/server

Pada saat server database mengalami kerusakan sehingga database tidak tersedia dan tidak dapat diakses

Kerusakan database Kerusakan OS Kerusakan dari oracle instance

Kerusakan dari kartu jaringan

Kerusakan media penyimpanan data

Pada saat media penyimpanan dari data mengalami kerusakan sehingga data tidak dapat diakses

Kerusakan disk drive Kerusakan disk controller Kerusakan storage Kesalahan manusia Pada saat melakukan

tindakan illegal baik disengaja maupun tidak yang menyebabkan kerusakan/kehilangan data

Menghapus objek database

Kekeliruan merubah data Penghilangan data Kerusakan data Pada saat h/w maupun

s/w menyebabkan data tidak dapat diakses dan ditulis oleh database

OS atau driver media penyimpanan, disk controller atau kerusakan volume manager menyebabkan disk tidak dapat dibaca dan ditulis. Kerusakan/kehancuran

lokasi

Pada saat lokasi server database mengalami kerusakan/kehancuran besar

Kerusakan jaringan total Bencana/bencana alam Aksi terorisme Direncanakan Perubahan system Pada saat merencanakan

untuk melakukan pengembangan sistem, operasi perawatan sistem

Menambah/memindahkan server

Menambah/memindahkan node pada cluster Menambah/memindahkan disk drive Merubah konfigurasi parameter Upgrade/patching s/w

2.4 Jenis-jenis High Availability Recovery

Oracle database memiliki kapabilitas penuh untuk melindungi dari semua penyebab downtime-nya sebuah sistem, baik yang direncanakan maupun tidak direncanakan. Feature-feature yang tersedia pada oracle untuk recovery antara lain:

1. Oracle Real Application Clusters 2. Oracle Data Guard

3. Oracle Streams

4. Oracle Flashback Technology 5. Automatic Storage Management 6. Recovery Manager

7. Flash Recovery Area 8. Fast-Start Fault Recovery

Tabel 2.2 Perbandingan jenis-jenis recovery

Tipe Kapabilitas dan feature database Keuntungan Tidak direncanakan

Kerusakan komputer Oracle Database dengan RAC Oracle Database dengan Data Guard Oracle Database dengan Streams Fast-Start Fault Recovery

Recovery otomatis node dan instance Fast Start Failover dan fast connection failover

Replikasi database secara online Tunable dan predictable cache recovery Kerusakan storsge/media

penyimpanan

Automatic Storage Management

Recovery Manager dengan Flash Recovery Area

Oracle Database dengan RAC Oracle Database dengan Data Guard

Mirroring dan online automatic balance Fully managed database recovery and managed disk-based backups

Recovery otomatis node dan instance Fast Start Failover dan fast connection failover

Kesalahan manusia Oracle Security Oracle Flashback

Oracle Database dengan Data Guard Log Miner

Membatasi akses sebagai pencegahan Mengembalikan data yang hilang

Fast Start Failover dan fast connection failover

Tabel 2.2 Perbandingan jenis-jenis recovery (lanjutan) Tipe Kapabilitas dan feature database Keuntungan Kerusakan data Oracle database dengan Data Guard

Oracle database dengan streams Recovery Manager

Fast Start Failover dan fast connection failover

Replikasi database secara online

Fully managed database recovery and integration with tape management vendors Direncanakan

Perubahan Data Oracle database dengan Data Guard Oracle database dengan streams

Fast Start Failover dan fast connection failover

Replikasi database secara online Perubahan system Automatic Storage Management

Oracle Database dengan RAC Oracle Database dengan Data Guard Oracle Database dengan Streams

Mirroring dan online automatic balance Recovery otomatis node dan instance Fast Start Failover dan fast connection failover

Replikasi database secara online

Dari tabel 2.2 terlihat bahwa feature dari oracle yang mendominasi adalah

Oracle RAC dan Oracle Data Guard dalam melakukan perlindungan terhadap

kerusakan/kehilangan pada sistem. RAC memberikan beberapa keuntungan :

1. Kemampuan untuk memperbaiki secara cepat dari kerusakan komputer dan

instance.

2. Cepat dan otomatis dalam melakukan relokasi dan failover.

3. Kemampuan untuk melakukan load balancing

4. Fleksibel untuk meningkatkan kemampuan dengan menambah perangkat tanpa melakukan downtime atau perubahan pada aplikasi.

Data Guard memberikan beberapa keuntungan :

1. Pencegahan kerusakan, perlindungan data, dan ketersediaan data. Data guard memberikan solusi efisien untuk ketersediaan data dan pencegahan kerusakan data, mudah untuk mengatur proses switchover dan failover untuk mengganti

role antara primary database dan standby database, meminimalisir waktu downtime primary database.

2. Perlindungan data yang lengkap. Data guard dapat memastikan tidak terjadi kehilangan data, standby database menjaga dari kerusakan data dan kesalahan

user. Kerusakan storage primary database tidak berpengaruh kepada standby database.

3. Penggunaan resource system secara efisien. Standby database ter-update melalui redo data yang diterima dari primary database dan dapat digunakan untuk kegiatan lain seperti backups, reporting, dan penarikan data yang akan mengurangi penggunaan CPU dan I/O Cycles pada primary database.

4. Deteksi otomatis perbedaan data. Jika koneksi terputus antara primary dan

standby database, redo data yang di-generated pada primary database tidak

dapat dikirimkan ke standby database, saat koneksi tersambung kembali,

archived redo log files yang tidak terkirim akan dideteksi secara otomatis oleh data guard dan akan mengirimkannya ke standby database. Standby database

melakukan sinkronisasi dengan primary database tanpa campur tangan DBA. 5. Perubahan role otomatis. Saat fungsi fast-start failover di aktifkan, dataguard

broker secara otomatis melakukan failover untuk melakukan sinkronisasi standby database saat terjadi kerusakan pada primary database tanpa campur

Tabel 2.3 Solusi Oracle High availability untuk downtime tidak direncanakan dengan menggunakan RAC dan Data Guard

Tipe Solusi Keuntungan Waktu perbaikan Kerusakan komputer RAC Perbaikan kerusakan

node dan instance secara otomatis

Tidak ada downtime Data Guard Fast start failover dan

fast connection failover

Detik – 5 menit Kerusakan storage Data Guard Fast start failover dan

fast connection failover

Detik – 5 menit RAC dengan ASM Mirroring dan balance

data

Tidak ada downtime Kesalahan manusia Data Guard Fast start failover dan

fast connection failover

Detik – 5 menit Data corrupt Data Guard Validasi otomatis block

redo sebelum diapply, memindahkan ke standby database

Detik – 5 menit

Kerusakan lokasi Data Guard Fast start failover dan fast connection failover

Detik – 5 menit

Tabel 2.4 Solusi Oracle High availability untuk downtime direncanakan dengan menggunakan RAC dan Data Guard

Tipe Solusi Waktu perbaikan Upgrade sistem dan

perangkat

RAC Tidak ada downtime OS upgrade RAC Tidak ada downtime Patching RAC Tidak ada downtime

Data Guard Detik – menit CRS upgrades RAC Tidak ada downtime Upgrade sistem dan

cluster

Data Guard Detik – menit

2.5 Maximum Availability Architecture dengan RAC dan Data Guard

MAA (Maximum Availability Architecture) mengkombinasikan

scalability/skalabilitas dan availability/ketersediaan RAC dengan kemampuan

perlindungan data dari Data Guard. MAA menyediakan arsitektur paling menyeluruh untuk mengurangi downtime yang direncanakan serta menjaga, mendeteksi, dan memperbaiki dari downtime yang tidak direncanakan.

Tabel 2.5 Waktu downtime yang diperlukan untuk kerusakan tidak direncanakan

Tipe RAC Data Guard MAA

Kerusakan komputer Tidak ada downtime Detik – 5 menit Tidak ada downtime Kerusakan storage Tidak ada downtime Tidak ada downtime Tidak ada downtime Kerusakan data Hitungan jam Detik – 5 menit Detik – 5 menit Kerusakan lokasi Jam – Hari Detik – 5 menit Detik – 5 menit

Tabel 2.6 Waktu downtime yang diperlukan untuk kerusakan direncanakan

Tipe RAC Data Guard MAA

Perubahan sistem Tidak ada downtime Tidak ada downtime Tidak ada downtime Upgrade sistem Tidak ada downtime Detik – 5 menit Tidak ada downtime Upgrade cluster Menit – jam Detik – 5 menit Detik – 5 menit Migrasi storage Tidak ada downtime Tidak ada downtime Tidak ada downtime Patching database Tidak ada downtime Detik – 5 menit Tidak ada downtime Perubahan data Tidak ada downtime Tidak ada downtime Tidak ada downtime

2.6 Arsitektur Oracle

Pada Oracle server memiliki 2 komponen penting yaitu Database dan Instance. Database adalah kumpulan file (physical file) untuk menyimpan data

yang saling berelasi. Instance adalah proses yang mengatur jalannya database (engine), instance mengatur penggunaan memory dan background process yang digunakan untuk mengakses data dari physical database files.

Gambar 2.2 Arsitektur Database Oracle [Referensi:Oracle 10g Online Documentation,2006]

2.7 Struktur Database Oracle

Oracle memiliki dua buah struktur yang merupakan bagian dari arsitektur oracle, yaitu:

a. Struktur logikal, komponen yang digunakan untuk mengalokasikan space pada disk (tablespace).

b. Struktur physical, komponen yang digunakan untuk mengatur fisik dari

database file.

2.7.1 Struktur Logical

a. Tablespace, digunakan untuk merelasikan dan menyatukan objek database menjadi satu kesatuan.

b. Segment adalah kumpulan dari satu atau beberapa extents c. Extents adalah block data yang saling berdekatan

d. Blocks adalah bagian terkecil dari storage (i.e : windows=> 4kb)

Gambar 2.3 Struktur logical oracle

2.7.2 Struktur Physical

a. Datafile, digunakan untuk menyimpan data dari object database (mis : table,

index, dll)

b. Redo log files, digunakan untuk menyimpan semua perubahan data yang dibutuhkan pada proses recovery (memperbaiki perubahan2 yang belum ditulis pada datafile)

c. Control file, berisi informasi berupa konfigurasi, lokasi data redo log files, datafile.

2.8 Struktur Instance

Oracle Instance terdiri dari Memory dan Background process. Oracle

menggunakan shared memory untuk pengoprasian database server, yang dibagi dalam struktur memory yang disebut sebagai SGA (System Global Area/Shared

Global Area) dan PGA (Program Global Area/Private Global Area).

SGA (System Global Area/Shared Global Area) adalah area berupa shared memory yang digunakan untuk untuk menyimpan data atau konfigurasi

yang mengendalikan system. Bila sebuah oracle instance di-startup, maka system melakukan alokasi memory untuk SGA dan dikelola sampai instance tersebut tidak dibutuhkan lagi (Dalam keadaan shutdown), PGA terdiri dari :

a. Database Buffer Cache, memory yg dialokasikan untuk menyimpan data sementara dari datafile atau data yang baru tetapi belum melalui commit.

Buffer cache memilik 3 tipe, yaitu :

Free buffers : Buffer yang kosong dan tidak ada block data didalamnya.

Ketika oracle membaca data dari disk(datafile) maka free buffer akan menyimpan data tersebut sehingga akan berubah menjadi dirty buffer

Pinned buffers : Block data yang ada dalam buffers sedang mengalami

proses perubahan

b. Redo Log Buffer, berisi informasi yang mencatat semua perubahan yang terjadi pada database secara otomatis dan cepat. Data ini di catat ke redo

log secepat mungkin, karena akan digunakan untuk tujuan recovery.

c. Shared Pool, menyimpan informasi seperti data dictionary, sql structure,

library dan lainnya. Informasi yang disimpan antara lain :

1. User information seperti privilege (hak/ijin akses)

2. Integrity constraints

3. Nama table, view, tipe data

4. Informasi tentang alokasi memory yang digunakan untuk schema object

d. Library cache, terdiri dari shared SQL areas, privates SQL areas, PL/SQL

procedures, package dan control structures seperti locks dan library cache handles.

Shared SQL areas, berisi informasi untuk mengeksekusi instruksi SQL

dan instruksi ini disimpan, dan bila terjadi query yang sama maka system mengalokasikan request tersebut ke lokasi memory yang sama.

e. Data Dictonary Cahce, berisi koleksi struktur table, view, dan referensi ke

f. Large Pool adalah memory yang digunakan untuk menyediakan alokasi

memory yang besar untuk spesifik operasi database seperti backup dan restore.

g. Java Pool adalah memory yang dialokasikan untuk proses yang berbasis java.

PGA (Program Global Area/Private Global Area) adalah area pada memory yang berisi data untuk setiap proses yang terjadi pada database dan area

ini tidak dipakai bersama(non-share) yang terdiri dari :

a. Stack Space, memory yg dialokasikan untuk menyimpan data dari variable dan arrays

b. Session Information, memory yg dialokasikan untuk menyimpan data tentang session yang terjadi pada database seperti user koneksi.

c. Sort Area, memory yg dialokasikan untuk menyimpan data dari proses

sorting. Perintah SQL yang termasuk proses sort adalah : CREATE

INDEX, DISTINCT, ORDER BY, GROUP BY, UNION, INTERSACT, dan MINUS.

SCA (Software Code Area) adalah area pada memory yang dialokasikan

untuk menyimpan perintah atau code yang sedang dijalankan. Memory ini biasanya digunakan oleh oracle tools dan utilities seperti : SQL*Forms, SQL*Plus, etc.

2.9 Proses Background

a. PMON (Process Monitor)

1. Melakukan rollback untuk transaksi yang dibatalkan 2. Membersihkan proses yang berakhir tidak normal

3. Mengaktifkan kembali shared_server dan dispatcher(Proses yang mengatur penjadwalan eksekusi proses oracle) bila mengalami

error.

4. Membebaskan resource SGA yang dialokasikan pada process yang gagal.

b. SMON (System Monitor) berfungsi menjalankan instance recovery secara otomatis, mengatur memory segment dan menggabungkan free

area memory yang berdekatan (garbage collector)

c. LGWR (Log Writer) berfungsi menulis semua data block pada buffer ke log file pada saat :

1. Terjadi proses commit 2. Terjadi Checkpoint

3. Setiap 3 detik 4. Log buffer penuh

d. CKPT (Check Point) berfungsi menjaga konsistensi data dengan membuat check point, sehingga bila terjadi crash, maka kondisi

database dapat di kembalikan ke kondisi pada saat check point terakhir

di buat. Proses checkpoint adalah menulis semua perubahan (updating) yang terjadi antara begin transaction dan commit.

e. DBWR(Database Writer) berfungsi menulis semua data block pada buffer cache ke datafile pada saat terjadi commit

2.10 Oracle Data Guard

Oracle Data Guard memastikan ketersediaan data, perlindungan data, dan

penyelamatan data untuk database perusahaan. Data Guard menyediakan suatu pelayanan menyeluruh untuk membuat, memelihara, mengatur, dan memonitor satu atau lebih standby database agar production database dapat terhindar dari kerusakan dan kehilangan data. Data Guard memelihara standby database sebagai duplikasi dari transaksi pada production database. Disaat database produksi tidak tersedia oleh sebab yang direncakan maupun tidak direncanakan,

data guard dapat memindahkan/merubah standby database menjadi production database, meminimalisasi waktu downtime.

2.11 Standby Database

Standby database menjamin bahwa data yang dimiliki tidak akan hilang

ketika pada data terjadi kegagalan di database oracle. Ketika primary database mengalami gangguan, maka koneksi aplikasi dapat dipindahkan ke standy

database yang sudah disiapkan. Selama primary database dalam perbaikan, maka

semua pemakai aplikasi masih dapat melakukan transaksi secara normal menggunakan standby database tersebut yang sudah menjadi primary database yang baru. Jika primary database yang lama sudah dapat diaktifkan kembali,

maka koneksi dari pemakai aplikasi dapat dipindahkan kembali ke primary

database yang lama.

Pada teknologi ORAC apabila terjadi kegagalan pada salah satu instance, maka instance yang lain dapat segera langsung menggantikannya tanpa terjadi gangguan pada semua pemakai aplikasi. Untuk standby database tetap dibutuhkan beberapa penanganan khusus untuk mengaktifkan standby database menjadi

primary database yang baru sehingga seluruh pemakai aplikasi dapat melakukan

transaksi pada primary database yang baru tersebut.

Pada tahap pemindahan diperlukan waktu beberapa detik untuk mengaktifkan standby database menjadi primary database. Proses perpindahan dari primary database ke standby database disebut sebagai SWITCH OVER. Sedangkan jika dari standby database ke primary database disebut sebagai SWITCH BACK.

2.11.1 Physical Standby Database

Physical standby database bekerja dengan cara melakukan sinkronisasi

redo yang di-generated oleh primary database melalui media recovery. Sedangkan redo dikirimkan melalui protokol oracle net.

Dengan menggunakan media recovery tersebut dapat dipastikan bahwa

physical standby akan melakukan proses penyalinan redo data secara block-per-block dari primary database ke standby database. Sehingga setiap transaksi yang

dilakukan pada primary database akan selalu tercatat pada standby database dan akan mencegah hilangnya data.

2.11.2 Logical Standby Database

Pada konfigurasi logical standby database, redo yang di-generated oleh

primary database akan dikonversi menjadi sebuah transaksi SQL dan akan

dijalankan pada standby database. Dengan logical standby database pemakai dapat mengakses standby database secara read-only. Hal ini sangat bermanfaat apabila ingin melakukan proses reporting dilakukan pada standby database secara terpisah.

Tetapi, tentu saja ada beberapa keterbatasan yang dimiliki oleh oracle, yaitu adanya beberapa tipe data yang tidak didukung oleh logical standby

database. Jika anda mempunyai sebuah table yang mempunyai tipe data yang

tidak didukung oleh logical standby database, maka sebaiknya Anda harus menggunakan konfigurasi physical standby database. Untuk itu periksa kembali tipe-tipe data yang dapat didukung oleh logical standby database.

SQL> select owner, table_name 2 from dba_logstdby_unsuported 3 group by owner, table_name no rows selected

SQL>

Jika tidak ditemukan beberapa table dari query diatas, berarti Anda dapat membuat logical standby database.

Gambar 2.4 Konfigurasi Tipikal Data Guard [Referensi:Oracle 10g Online Documentation,2006]

2.12 Data Guard Services

Cara kerja Data Guard dalam mengatur transmisi redo data, meng-aplikasikan redo data , dan melakukan perubahan ke database:

1. Redo Transport Services

Mengatur transfer redo data dari database produksi ke satu atau lebih standby database sebagai archive log.

2. Log Apply Services

Meng-aplikasikan redo data pada standby database untuk mengatur sinkronisasi transaksi dengan primary database.

3. Role Transitions

Merubah role/aturan sebuah database dari standby database mejadi

primary database, atau dari primary database menjadi standby database menggunakan operasi dari switchover maupun failover.

2.12.1 Redo Transport Services

Redo Transport Services mengatur secara otomatis proses transfer redo data dari database produksi ke standby database dengan langkah-langkah sebagai

berikut :

1. Mentransmisikan redo data dari primary database ke standby

database di dalam konfigurasi.

2. Mengatur proses pada archived redo log file saat terjadi kegagalan pada jaringan.

3. Mendeteksi secara otomatis archived redo log files yang hilang maupun rusak pada standby database dan menggantikan secara otomatis archived redo log files dari primary database atau dari

standby database lainnya.

2.12.2 Log Apply Services

Redo data di transmisikan/duplikasi dari primary database dengan cara

menulis di standby database kedalam standby redo log files, kemudian diarsipkan/disimpan kedalam archived redo log files. Log apply services secara otomatis menjaga konsistensi redo data pada standby database dengan redo data pada primary database, dan juga mengijinkan pembacaan data dengan mode

Gambar 2.5 Update otomatis pada physical standby database [Referensi:Oracle 10g Online Documentation,2006]

2.12.3 Role Transitions

Sebuah database oracle beroperasi pada satu dari dua role yaitu primary atau standby. Dengan menggunakan data guard , kita dapat merubah role tersebut dengan menggunakan operasi switchover ataupun failover.

Switchover dipastikan tidak terdapat data yang hilang. Ini digunakan

untuk penggantian role yang direncanakan untuk proses pemeliharaan pada

primary database. Failover terjadi saat primary database tidak tersedia, failover

disebabkan terjadi kerusakan pada primary database dan resiko kehilangan data tetaplah ada dan seorang DBA dapat mengatur data guard untuk memastikan tidak terjadi kehilangan data.

2.13 Keuntungan/Kelebihan Data Guard

1. Pencegahan kerusakan, perlindungan data, dan ketersediaan data.

Data guard memberikan solusi efisien untuk ketersediaan data dan

pencegahan kerusakan data, mudah untuk mengatur proses

switchover dan failover untuk mengganti role antara primary database dan standby database, meminimalisir waktu downtime primary database.

2. Perlindungan data yang lengkap. Data guard dapat memastikan tidak terjadi kehilangan data, standby database menjaga dari kerusakan data dan kesalahan user. Kerusakan storage primary database tidak berpengaruh kepada standby database.

3. Penggunaan resource system secara efisien. Standby database ter-update melalui redo data yang diterima dari primary database dan

dapat digunakan untuk kegiatan lain seperti backups, reporting, dan penarikan data yang akan mengurangi penggunaan CPU dan I/O

Cycles pada primary database.

4. Deteksi otomatis perbedaan data. Jika koneksi terputus antara

primary dan standby database, redo data yang di-generated pada primary database tidak dapat dikirimkan ke standby database, saat

koneksi tersambung kembali, archived redo log files yang tidak terkirim akan dideteksi secara otomatis oleh data guard dan akan mengirimkannya ke standby database. Standby database melakukan sinkronisasi dengan primary database tanpa campur tangan DBA.

5. Perubahan role otomatis. Saat fungsi fast-start failover di aktifkan, dataguard broker secara otomatis melakukan failover untuk

melakukan sinkronisasi standby database saat terjadi kerusakan pada

primary database tanpa campur tangan dari DBA.

2.14 Oracle Real Application Clusters

Oracle Real Application Clusters (RAC) merupakan suatu teknologi clustering database Oracle ke dalam suatu shared storage system device dan

dapat digunakan bersama-sama menggunakan database oracle oleh beberapa komputer / server secara simultan. Teknologi ini memungkinkan suatu pengelolaan database yang terpusat dan terstruktur dengan rapi, sehingga akan sangat memudahkan seorang DBA dalam melakukan tugas-tugasnya. Konsep yang diketengahkan dari pemodelan Clustering ini, juga memungkinkan adanya

handsover yang cepat dan otomatis apabila terjadi kegagalan sistem atau failover

dari server satu ke server lainnya. Fungsi lainnya adalah dapat berfungsi sebagai

load balancer dari penggunaan database secara bersama-sama dalam sebuah

sistem yang komplek dan besar. Selain itu dari sisi budgeting IT, tidak diperlukan

upgrade system hardware secara keseluruhan apabila database yang ditangani

sudah sangat besar, yaitu dengan cara menambahkan node server baru tanpa mengganggu aktivitas database yang sedang berjalan, sehingga dari sisi IT

2.15 Integrated Clusterware Management

Oracle RAC memberikan solusi manajemen clusterware yang terintegrasi secara lengkap pada semua platform dimana Oracle Database berjalan. Kegunaan

clusterware ini termasuk mekanisme untuk konektifitas cluster, pemesanan dan

penguncian, kontrol cluster dan recovery, dan workload management.

Gambar 2.6 Manajemen clusterware terintegrasi pada RAC [Referensi:Oracle 10g Online Documentation,2006]

Integrated clusterware management in Oracle RAC menawarkan

kelebihan-kelebihan sebagai berikut:

1. Berbiaya rendah, tidak ada tambahan biaya untuk RAC. 2. Dukungan vendor tunggal

3. Kemudahan dalam instalasi, konfigurasi, dan pemeliharaan dengan

menggunakan Oracle Database Management tools. 4. Memiliki fungsi yang konsisten terhadap semua platform.

2.16 Single System Image Management

Oracle Enterpise Manager 10g telah menjadi sebuah sistem yang

mendukung single system image management dari database cluster. Halaman

cluster database dari Enterprise Manager memperlihatkan kesatuan monitoring

dari beberapa node instance.

Dari halaman cluster database kita dapat :

1. Melihat status keseluruhan sistem, misal jumlah nodes pada cluster

database dan status terakhir setiap node.

2. Melihat alert/tanda peringatan semua instance.

3. Memonitor performance seluruh instance dan membandingkan satu sama lain.

4. Memonitor statistik cache cluster (misal: global buffer gets).

5. Melakukan operasi cluster database termasuk melakukan operasi

backup dan recovery, menghidupkan dan mematikan instance.

6. Memonitor perangkat cluster dan platform sistem operasi, hal ini sangat berguna saat cluster digunakan pada banyak database.

Gambar 2.7 Single system image Cluster Database untuk Oracle RAC

[Referensi:Oracle 10g Online Documentation,2006]

2.17 Automatic Workload Management

Dengan Oracle database 10g, application workloads dapat didefinisikan sebagai service sehingga dapat di atur dan dikontrol secara tersendiri. DBA mengatur sumber daya proses yang dialokasikan untuk setiap service selama dalam operasi normal dan dalam kondisi tidak normal/terjadi kegagalan. Pengukuran performa di-tracking oleh service dan diset secara otomatis untuk menghasilkan alert/pesan kesalahan. Alokasi sumber daya CPU diatur untuk

service menggunakan Resource Manager. Oracle tools dan fasilitas seperti job schedulel, parallel query juga menggunakan service untuk mengatur workloads

mereka. Dengan oracle 10g, alokasi sumber daya proses ke service dapat dilakukan secara otomatis. Setiap instance dari Oracle RAC dapat dialokasikan untuk proses servis tunggal maupun banyak servis saat diperlukan.

2.18 Workload Monitoring

Oracle Automatic Workload Repository mengatur performa untuk RAC

dan instance database tunggal. Respon time, penggunaan CPU, dan pengukuran lain dikumpulkan secara otomatis oleh service.

2.19 Fast Connection Fail-Over

Oracle RAC mendeteksi ketika instances mati dan ketika hidup kembali, sistem pendeteksi mengirimkan sinyal UP dan DOWN kepada aplikasi perantara sehingga prosedur recovery otomatis dapat dijalankan. Hal ini lebih efisien dibandingkan menggunakan pendeteksian melalui jaringan (seperti TCP/IP

timeouts). Ketika terjadi kegagalan atau kerusakan, transaksi yang dilakukan oleh

aplikasi akan dihentikan dan transaksi akan di rolled back ke kondisi awal sebelum terjadi transaksi, kemudian aplikasi akan mencoba untuk meminta layanan service kembali. Sinyal UP membuka kembali koneksi dan melakukan

BAB III

ANALISA KEBUTUHAN & PERANCANGAN SISTEM DRP DENGAN TEKNOLOGI RAC DAN DATA GUARD

Pada bab ini akan dijelaskan mengenai analisa kebutuhan dan perancangan sistem DRP yang High Availability beserta konfigurasi yang diperlukan dalam pembuatan RAC sebagai primary database dan Data Guard sebagai standby

database.

3.1 Analisa Kebutuhan

1. User General Requirement

Kebutuhan yang ditetapkan oleh user adalah sebuah sistem database yang memiliki karakteristik availability dimana suatu aplikasi, layanan, atau fungsi dapat tersedia pada saat user membutuhkannya. Dimana sistem tersebut harus memiliki kemampuan-kemapuan untuk melakukan :

1. Kecepatan deteksi kesalahan/kegagalan dari suatu sistem.

2. Perbaikan yang cepat, dengan downtime maksimal yang telah ditetapkan

3. Operasi perbaikan yang otomatis. 4. Melindungi dari kehilangan data. 2. User Downtime Requirement

Kebutuhan yang ditetapkan oleh user adalah sebuah sistem database yang dapat memenuhi kriteria maksimal downtime yang telah ditetapkan dengan mempertimbangkan penyebab/alasan dari downtime yang direncanakan maupun

tidak direncanakan.

Tabel 3.1 Penyebab dan maksimal downtime yang ditetapkan user

Kategori Tipe Deskripsi Contoh Max

Downtime Tidak

direncanakan

Kerusakan komputer/server

Pada saat server database mengalami kerusakan sehingga database tidak tersedia dan tidak dapat diakses

Kerusakan database Kerusakan OS Kerusakan dari oracle instance

Kerusakan dari kartu jaringan

< 5 detik

Kerusakan media penyimpanan data

Pada saat media penyimpanan dari data mengalami kerusakan

sehingga data tidak dapat diakses

Kerusakan disk drive Kerusakan disk controller Kerusakan storage < 5 menit Kesalahan manusia Pada saat melakukan tindakan illegal baik disengaja maupun tidak yang menyebabkan kerusakan/kehilan gan data Menghapus objek database Kekeliruan merubah data Penghilangan data < 5 menit

Kerusakan data Pada saat h/w maupun s/w menyebabkan data tidak dapat diakses dan ditulis oleh database

OS atau driver media penyimpanan, disk controller atau kerusakan volume manager menyebabkan disk tidak dapat dibaca dan ditulis.

< 5 menit

Kerusakan/kehanc uran lokasi

Pada saat lokasi server database mengalami kerusakan/kehancu ran besar Kerusakan jaringan total Bencana/bencana alam Aksi terorisme < 5 menit

Direncanakan Perubahan system Pada saat merencanakan untuk melakukan pengembangan sistem, operasi perawatan sistem Menambah/memindah kan server Menambah/memindah kan node pada cluster Menambah/memindah kan disk drive Merubah konfigurasi parameter

Upgrade/patching s/w

< 5 menit

yang dapat digunakan adalah dengan mengkombinasikan teknologi RAC dengan teknologi Data Guard.

Tabel 3.2 Solusi Oracle High availability untuk downtime tidak direncanakan dengan menggunakan RAC dan Data Guard

Tipe Solusi Keuntungan Waktu perbaikan

Kerusakan komputer RAC Perbaikan kerusakan node dan instance secara otomatis

Tidak ada downtime

Data Guard Fast start failover dan fast connection failover

Detik – 5 menit

Kerusakan storage Data Guard Fast start failover dan fast connection failover

Detik – 5 menit

RAC dengan ASM Mirroring dan balance data

Tidak ada downtime Kesalahan manusia Data Guard Fast start failover dan

fast connection failover

Detik – 5 menit

Data corrupt Data Guard Validasi otomatis block redo sebelum diapply,

memindahkan ke standby database

Detik – 5 menit

Kerusakan lokasi Data Guard Fast start failover dan fast connection failover

Detik – 5 menit

Tabel 3.3 Solusi Oracle High availability untuk downtime direncanakan dengan menggunakan RAC dan Data Guard

Tipe Solusi Waktu perbaikan

Upgrade sistem dan perangkat

RAC Tidak ada downtime OS upgrade RAC Tidak ada downtime Patching RAC Tidak ada downtime

Data Guard Detik – menit CRS upgrades RAC Tidak ada downtime Upgrade sistem dan

cluster

Data Guard Detik – menit

availability/ketersediaan RAC dengan kemampuan perlindungan data dari Data Guard, dapat menyediakan arsitektur paling menyeluruh untuk mengurangi downtime yang direncanakan serta menjaga, mendeteksi, dan memperbaiki dari downtime yang tidak direncanakan.

RAC memberikan beberapa keuntungan :

1. Kemampuan untuk memperbaiki secara cepat dari kerusakan komputer dan

instance.

2. Cepat dan otomatis dalam melakukan relokasi dan failover.

3. Kemampuan untuk melakukan load balancing

4. Fleksibel untuk meningkatkan kemampuan dengan menambah perangkat tanpa melakukan downtime atau perubahan pada aplikasi.

Data Guard memberikan beberapa keuntungan :

1. Pencegahan kerusakan, perlindungan data, dan ketersediaan data. Data guard memberikan solusi efisien untuk ketersediaan data dan pencegahan kerusakan data, mudah untuk mengatur proses switchover dan failover untuk mengganti

role antara primary database dan standby database, meminimalisir waktu downtime primary database.

2. Perlindungan data yang lengkap. Data guard dapat memastikan tidak terjadi kehilangan data, standby database menjaga dari kerusakan data dan kesalahan

user. Kerusakan storage primary database tidak berpengaruh kepada standby database.

melalui redo data yang diterima dari primary database dan dapat digunakan untuk kegiatan lain seperti backups, reporting, dan penarikan data yang akan mengurangi penggunaan CPU dan I/O Cycles pada primary database.

4. Deteksi otomatis perbedaan data. Jika koneksi terputus antara primary dan

standby database, redo data yang di-generated pada primary database tidak

dapat dikirimkan ke standby database, saat koneksi tersambung kembali,

archived redo log files yang tidak terkirim akan dideteksi secara otomatis oleh data guard dan akan mengirimkannya ke standby database. Standby database

melakukan sinkronisasi dengan primary database tanpa campur tangan DBA. 5. Perubahan role otomatis. Saat fungsi fast-start failover di aktifkan, dataguard

broker secara otomatis melakukan failover untuk melakukan sinkronisasi standby database saat terjadi kerusakan pada primary database tanpa campur

tangan dari DBA.

Tabel 3.4 Waktu downtime yang diperlukan untuk kerusakan tidak direncanakan

Tipe RAC Data Guard RAC + Data Guard Kerusakan komputer Tidak ada downtime Detik – 5 menit Tidak ada downtime Kerusakan storage Tidak ada downtime Tidak ada downtime Tidak ada downtime Kerusakan data Hitungan jam Detik – 5 menit Detik – 5 menit Kerusakan lokasi Jam – Hari Detik – 5 menit Detik – 5 menit

Tabel 3.5 Waktu downtime yang diperlukan untuk kerusakan direncanakan

Tipe RAC Data Guard RAC + Data Guard Perubahan sistem Tidak ada downtime Tidak ada downtime Tidak ada downtime Upgrade sistem Tidak ada downtime Detik – 5 menit Tidak ada downtime Upgrade cluster Menit – jam Detik – 5 menit Detik – 5 menit Migrasi storage Tidak ada downtime Tidak ada downtime Tidak ada downtime Patching database Tidak ada downtime Detik – 5 menit Tidak ada downtime Perubahan data Tidak ada downtime Tidak ada downtime Tidak ada downtime

Tabel 3.6 Analisa level aplikasi/resource

Definisi Kritis Max. Downtime Aplikasi/Resource Strategi

Essential < 5 menit Data base DBRPT RAC + Data Guard

Critical < 1 jam - -

Important < 1 hari - -

Non-critical > 1 hari - -

3.2 Perancangan arsitektur sistem dengan RAC dan Data Guard

Pada perancangan sistem ini akan dibangun dua buah node untuk arsitektur RAC-nya dan menggunakan satu buah server sebagai physical standby database.

A. SPESIFIKASI HARDWARE

Spesifikasinya sebagai berikut : IBM p5 510 Express – 3 unit

Processor : 2-way IBM 64 bit POWER 5+/1.9GHz/1.9MB L2/36MB L3 Memory : 8GB DDR2 SDRAM 528MHz

Internal Storage : 2x 146GB 15K rpm Ultra320 SCSI HDD

Storage Contr : Dual channel Ultra320 SCSI controller with RAID daughter card Network Cont : Dual port gigabit Ethernet

B. SPESIFIKASI SOFTWARE

Oracle Database 10g Release 2 Edisi : Enterprise Edition Base Release : 10.2.0.1 Patch Installed : 10.2.0.4

Platform : Linux Redhat Enterprise Advanced Server 4 Feature : Oracle Data Guard / Standby Database

C. KONFIGURASI DISK

Konfigurasi Disk minimal yang harus disediakan untuk implementasi RAC yang bisa di shared ke semua server yang menjadi member RAC adalah sebagai berikut

Kegunaan Jumlah Ukuran Nama Partisi

(opsional) Oracle Clusterware Clusterware Engine (tidak di share ) 1 untuk tiap server 10000m /oracle/crs Cluster Registry 2 100m ora_ocr_raw[n]_100m Voting Disk 3 20m ora_vote_raw[n]_20m

Oracle Database RDBMS Engine (tidak di share ) 1 untuk tiap server 10000 /oracle/rdbms SYSTEM tablespace: 1 500m [dbname]_system_raw_500m SYSAUX tablespace 1 300 + (jumlah instance * 250) [dbname]_sysaux_raw_800m UNDOTBSn tablespace [Jumlah Instance] 500m [dbname]_undotbs[n]_raw_5 00m

TEMP tablespace 1 _250m [dbname]_temp_raw_250m

EXAMPLE tablespace

1

160m [dbname]_example_raw_160 m

USERS tablespace 1 _120m [dbname]_users_raw_120m

online redo log files _{2 *} number of instances 120m [dbname]_redo[n]_[m]_raw_ 120m control files 2 110m [dbname]_control[n]_raw_11 0m Server parameter file 1 5m [dbname]_spfile_raw_5m Password file 1 _5m [dbname]_pwdfile_raw_5m

Keadaan darurat :

Keadaan darurat adalah situasi/kondisi di luar normal sebagai akibat adanya peristiwa-peristiwa yang secara langsung atau tidak langsung mempengaruhi pelaksanaan tugas perusahaan dan terjadi di luar kekuasaan dan kemampuan perusahaan untuk mengatasinya sehingga satuan kerja operasional tidak dapat melaksanakan tugasnya di tempat yang semestinya selama jangka waktu yang tidak tertentu. Peristiwa-peristiwa tersebut meliputi antara lain: bencana alam, kebakaran, huru-hara, gangguan jaringan komunikasi dan/atau peraturan yang dikeluarkan pemerintah. Dalam keadaan kegiatan operasional tidak dapat dilakukan di primary-site, setelah dinyatakan dalam kondisi darurat sebagaimana diatur dalam Sistem Pemulihan Teknologi Informasi Dalam Keadaan Darurat Perusahaan, kegiatan operasional dialihkan ke DRC-Site.

Keadaan darurat digolongkan atas:

1. Keadaan Darurat I ( Sistem Komputer )

Pada kondisi darurat seperti ini diasumsikan salah satu node dari RAC mengalami kerusakan/down sehingga kegiatan operasional akan tetap dilaksanakan oleh user dengan menggunakan node lainnya yang tidak mengalami kerusakan. Sementara akses ke server aplikasi dan server database masih menggunakan Primary Site.

Gambar 3.2 Kondisi keadaan darurat I

2. Keadaan Darurat II ( Sistem Komputer )

Pada kondisi darurat ini diasumsikan PC Client, Server Aplikasi dan Server Database yang ada di lingkungan Primary site tidak dapat diakses/digunakan. Sehingga kegiatan operasional akan dilaksanakan oleh user dengan menggunakan backup PC Client yang telah disiapkan di DRC-Site. Dari sisi sistem aplikasi komputer yang ada akan dilakukan proses switch over/failover untuk memindahkan bisnis operasional dari primary site ke backup site.

BAB IV

IMPLEMENTASI DAN PENGUJIAN

Pada bab ini penulis akan melakukan implementasi dan pengujian mengenai Disaster Recovery System yang dijalankan dengan teknologi RAC dan

Data Guard menggunakan standby database server.

4.1 Instalasi Oracle RAC

Langkah-langkah :

1. Instalasi dan konfigurasi linux/unix

Pada tahap ini dilakukan instalasi paket-paket yang diperlukan untuk instalasi oracle serta pembuatan mountpoint yang diperlukan oleh oracle.

2. Konfigurasi linux untuk oracle

Pada tahap ini dilakukan pembuatan user dan group untuk oracle, membuat directory untuk oracle, melakukan konfigurasi parameter kernel, melakukan setting shell limits dan profile untuk user oracle.

3. Mempersiapkan Shared Disk

Pada tahap ini dilakukan pembuatan partisi untuk clusterware dan ASM

4. Instalasi Oracle Clusterware (CRS)

Pada tahap ini dilakukan instalasi CRS pada setiap node RAC, agar setiap node tersebut dapat menjadi sebuah SID database.