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

Transkripsi

1 ANALISA PERANCANGAN DAN UJI KINERJA SISTEM DRP DENGAN 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 PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS ILMU KOMPUTER UNIVERSITAS MERCU BUANA 2008

2 ABSTRAK 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

3 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. 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 ratarata 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. Keyword : DRP, DRC, RAC, Data Guard, downtime

4 ABSTRACT 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

5 server and database server still use Primary Site. And Examination at condition of 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. Keyword : DRP, DRC, RAC, Data Guard, downtime.

6 i LEMBAR PERNYATAAN Yang bertanda tangan di bawah ini : Nama : GUGUN GUNAWAN NIM : Menyatakan bahwa Tugas Akhir ini adalah hasil buatan sendiri, bukan hasil dari duplikasi kecuali yang tercantum di dalam daftar pustaka. Jakarta, Juli 2008 (GUGUN GUNAWAN)

7 ii LEMBAR PENGESAHAN NAMA : GUGUN GUNAWAN NIM : 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

8 iii 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.

9 iv 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 Penulis

10 v 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 Latar Belakang Identifikasi Masalah Batasan Masalah Tujuan Penelitian Metode Penelitian Sistematika Penulisan. 4 BAB II LANDASAN TEORI Pengertian DRP ( Disaster Recovery Plan Pengertian Availability Alasan Downtime Jenis jenis High Availability Recovery MAA dengan RAC dan Data Guard Arsitektur Oracle. 14

11 vi 2.7 Struktur Database Oracle Struktur Logikal Sruktur Physical Struktur Instance Proses Background Oracle Data Guard Standby Database Physical Standby Database Logical Standby Database Data Guard Services Redo Transport Services Log Apply Services Role Transitions Keuntungan/kelebihan Data Guard Oracle Real Application Cluster Integrated Clusterware Management Single System Image Management Automatic Workload Management Workload Monitoring Fast Connection Fail-Over 31 BAB III ANALISA KEBUTUHAN DAN PERANCANGAN SISTEM DRP DENGAN TEKNOLOGI RAC DAN DATA GUARD Analisa Kebutuhan.. 32

12 vii 3.2 Perancangan arsitektur sistem RAC dan Data Guard Standar Operasi Penanggulangan Keadaan Darurat 40 BAB IV IMPLEMENTASI DAN PENGUJIAN Instalasi Oracle RAC Konfigurasi Raw Device pada Shared Storage Instalasi Clusterware Instalasi Database Engine Membuat Database Membuat Single Instance Physical Standby untuk RAC Mengumpulkan file untuk melakukan backup Konfigurasi Net Service pada Standby Database Membuat Physical Standby Database Konfigurasi Primary Database untuk Data Guard Verifikasi Konfigurasi Data Guard Skenario Pengujian Pengujian Keadaan Darurat I Mengaktifkan instance RAC per node Mengaktifkan/mematikan RAC Database Pengujian TAF Pengujian Keadaan Darurat II Pengujian fail over secara manual Pengujian Proses Transfer File Archive Log.. 83

13 viii BAB V PENUTUP Kesimpulan Saran. 86 DAFTAR PUSTAKA LAMPIRAN L-1

14 ix 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 Gambar 3.3. Kondisi keadaan darurat II

15 x DAFTAR TABEL Tabel 2.1. Penyebab downtime.. 9 Tabel 2.2. Perbandingan jenis-jenis recovery 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 3.6 Analisa level aplikasi/resource.. 37

16 xi Tabel 4.1 Tabel perbandingan waktu downtime darurat I Tabel 4.2 Tabel perbandingan waktu downtime darurat II Tabel 4.3 Tabel perbandingan waktu transfer file archive log... 84

17 1 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

18 2 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

19 3 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.

20 4 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.

21 5 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.

22 6 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 bermacammacam, 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. 6. Lakukan review terhadap metode DRP yang telah diterapkan.

23 7 Kerusakan sistem Sistem Crash Downtime Tidak direncanakan Kerusakan data Kesalahan manusia Data Corrupt Menghapus data Downtime direncanaka n Operasi Rutin Perawatan Rutin Backup Upgrade H/W & S/W 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

24 8 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.

25 9 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 Kerusakan media penyimpanan data Kesalahan manusia Kerusakan data Kerusakan/kehancuran lokasi Pada saat server database mengalami kerusakan sehingga database tidak tersedia dan tidak dapat diakses Pada saat media penyimpanan dari data mengalami kerusakan sehingga data tidak dapat diakses Pada saat melakukan tindakan illegal baik disengaja maupun tidak yang menyebabkan kerusakan/kehilangan data Pada saat h/w maupun s/w menyebabkan data tidak dapat diakses dan ditulis oleh database Pada saat lokasi server database mengalami kerusakan/kehancuran besar Direncanakan Perubahan system Pada saat merencanakan untuk melakukan pengembangan sistem, operasi perawatan sistem Kerusakan database Kerusakan OS Kerusakan dari oracle instance Kerusakan dari kartu jaringan Kerusakan disk drive Kerusakan disk controller Kerusakan storage Menghapus objek database Kekeliruan merubah data Penghilangan data OS atau driver media penyimpanan, disk controller atau kerusakan volume manager menyebabkan disk tidak dapat dibaca dan ditulis. Kerusakan jaringan total Bencana/bencana alam Aksi terorisme Menambah/memindahkan server Menambah/memindahkan node pada cluster Menambah/memindahkan disk drive Merubah konfigurasi parameter Upgrade/patching s/w

26 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 Kerusakan storsge/media penyimpanan Kesalahan manusia Oracle Database dengan RAC Oracle Database dengan Data Guard Oracle Database dengan Streams Fast-Start Fault Recovery Automatic Storage Management Recovery Manager dengan Flash Recovery Area Oracle Database dengan RAC Oracle Database dengan Data Guard Oracle Security Oracle Flashback Oracle Database dengan Data Guard Log Miner Recovery otomatis node dan instance Fast Start Failover dan fast connection failover Replikasi database secara online Tunable dan predictable cache recovery 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 Membatasi akses sebagai pencegahan Mengembalikan data yang hilang Fast Start Failover dan fast connection failover Analisa log/catatan

27 11 Tabel 2.2 Perbandingan jenis-jenis recovery (lanjutan) Tipe Kapabilitas dan feature database Keuntungan Kerusakan data Oracle database dengan Data Guard Direncanakan Perubahan Data Perubahan system Oracle database dengan streams Recovery Manager Oracle database dengan Data Guard Oracle database dengan streams Automatic Storage Management Oracle Database dengan RAC Oracle Database dengan Data Guard Oracle Database dengan Streams Fast Start Failover dan fast connection failover Replikasi database secara online Fully managed database recovery and integration with tape management vendors Fast Start Failover dan fast connection failover Replikasi database secara online 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.

28 12 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.

29 13 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 Tidak ada downtime node dan instance secara otomatis Data Guard Fast start failover dan Detik 5 menit fast connection failover Kerusakan storage Data Guard Fast start failover dan Detik 5 menit fast connection failover RAC dengan ASM Mirroring dan balance Tidak ada downtime data Kesalahan manusia Data Guard Fast start failover dan Detik 5 menit fast connection failover Data corrupt Data Guard Validasi otomatis block Detik 5 menit redo sebelum diapply, memindahkan ke standby database 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 RAC Tidak ada downtime perangkat 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.

30 14 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]

31 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 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 [Referensi:Oracle 10g Online Documentation,2006]

32 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 : Dirty buffers : Block buffer yang perlu ditulis ke datafile

33 17 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 database yang dapat diakses bersama

34 18 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.

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

36 20 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 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,

37 21 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 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-perblock 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.

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

39 23 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, mengaplikasikan 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.

40 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 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 read-only.

41 25 Gambar 2.5 Update otomatis pada physical standby database [Referensi:Oracle 10g Online Documentation,2006] 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.

42 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 terupdate 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.

43 27 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 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 Budgeting, dapat menekan biaya upgrade sistem yang mahal.

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

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

46 30 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.

47 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 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 load balanced kepada seluruh instance RAC yang aktif.

48 32 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