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 01501 - 035
PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS ILMU KOMPUTER UNIVERSITAS MERCU BUANA 2008
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
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
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
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.
i
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
(GUGUN GUNAWAN)
ii
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
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.
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
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……………………………………………… 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.6
Arsitektur Oracle …………………………………………. 14
vi
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.1
Analisa Kebutuhan …………..…………………………… 32
vii
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
4.3
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
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
viii
BAB V PENUTUP………………………………………………………. 85 5.1
Kesimpulan……………………………………………….. 85
5.2
Saran………………………………………………………. 86
DAFTAR PUSTAKA LAMPIRAN ……………………………………………………………… L-1
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 .............................……………. 41
Gambar 3.3.
Kondisi keadaan darurat II …………...………………….. 42
x
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 ……………
Tabel 2.4.
Solusi Oracle High availability untuk downtime direncanakan dengan menggunakan RAC dan Data Guard ……………
Tabel 2.5.
13
13
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 …………………………………………….
Tabel 3.5
36
Waktu downtime yang diperlukan untuk kerusakan yang direncanakan …………………………………………….. 36
Tabel 3.6
Analisa level aplikasi/resource ………………………….. 37
xi
Tabel 4.1
Tabel perbandingan waktu downtime darurat I ……... 77
Tabel 4.2
Tabel perbandingan waktu downtime darurat II ……... 82
Tabel 4.3
Tabel perbandingan waktu transfer file archive log ...... 84
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
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
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.
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.
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.
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.
7
Downtime Tidak direncanakan
Downtime direncanaka n
Kerusakan sistem
Sistem Crash
Kerusakan data
Data Corrupt
Kesalahan manusia
Menghapus data
Operasi Rutin
Backup
Perawatan Rutin
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
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.
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 Tidak direncanakan
Tipe Kerusakan komputer/server
Deskripsi Pada saat server database mengalami kerusakan sehingga database tidak tersedia dan tidak dapat diakses
Kerusakan media penyimpanan data
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
Kesalahan manusia
Kerusakan data
Kerusakan/kehancuran lokasi
Direncanakan
Perubahan system
Pada saat lokasi server database mengalami kerusakan/kehancuran besar Pada saat merencanakan untuk melakukan pengembangan sistem, operasi perawatan sistem
Contoh 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
10 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 Tidak direncanakan
Kapabilitas dan feature database
Keuntungan
Kerusakan komputer
Oracle Database dengan RAC Oracle Database dengan Data Guard
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
Kerusakan storsge/media penyimpanan
Kesalahan manusia
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
11 Tabel 2.2 Perbandingan jenis-jenis recovery (lanjutan) Tipe Kerusakan data
Kapabilitas dan feature database Oracle database dengan Data Guard Oracle database dengan streams Recovery Manager
Direncanakan Perubahan Data
Perubahan system
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
Keuntungan 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.
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.
13 Tabel 2.3 Solusi Oracle High availability untuk downtime tidak direncanakan dengan menggunakan RAC dan Data Guard Tipe Kerusakan komputer
Solusi RAC
Data Guard Kerusakan storage
Data Guard RAC dengan ASM
Kesalahan manusia
Data Guard
Data corrupt
Data Guard
Kerusakan lokasi
Data Guard
Keuntungan Perbaikan kerusakan node dan instance secara otomatis Fast start failover dan fast connection failover Fast start failover dan fast connection failover Mirroring dan balance data Fast start failover dan fast connection failover Validasi otomatis block redo sebelum diapply, memindahkan ke standby database Fast start failover dan fast connection failover
Waktu perbaikan Tidak ada downtime
Detik – 5 menit Detik – 5 menit Tidak ada downtime Detik – 5 menit Detik – 5 menit
Detik – 5 menit
Tabel 2.4 Solusi Oracle High availability untuk downtime direncanakan dengan menggunakan RAC dan Data Guard Tipe Upgrade sistem dan perangkat OS upgrade Patching CRS upgrades Upgrade sistem dan cluster
2.5
Solusi RAC
Waktu perbaikan Tidak ada downtime
RAC RAC Data Guard RAC Data Guard
Tidak ada downtime Tidak ada downtime Detik – menit Tidak ada downtime Detik – menit
Maximum Availability Architecture dengan RAC dan Data Guard MAA
(Maximum
Availability
Architecture)
scalability/skalabilitas dan availability/ketersediaan
mengkombinasikan
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.
14 Tabel 2.5 Waktu downtime yang diperlukan untuk kerusakan tidak direncanakan Tipe Kerusakan komputer Kerusakan storage Kerusakan data Kerusakan lokasi
RAC Tidak ada downtime Tidak ada downtime Hitungan jam Jam – Hari
Data Guard Detik – 5 menit Tidak ada downtime Detik – 5 menit Detik – 5 menit
MAA Tidak ada downtime Tidak ada downtime Detik – 5 menit Detik – 5 menit
Tabel 2.6 Waktu downtime yang diperlukan untuk kerusakan direncanakan Tipe Perubahan sistem Upgrade sistem Upgrade cluster Migrasi storage Patching database Perubahan data
2.6
RAC Tidak ada downtime Tidak ada downtime Menit – jam Tidak ada downtime Tidak ada downtime Tidak ada downtime
Data Guard Tidak ada downtime Detik – 5 menit Detik – 5 menit Tidak ada downtime Detik – 5 menit Tidak ada downtime
MAA Tidak ada downtime Tidak ada downtime Detik – 5 menit Tidak ada downtime Tidak ada downtime Tidak ada downtime
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]
15 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 [Referensi:Oracle 10g Online Documentation,2006]
16 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 : Dirty buffers : Block buffer yang perlu ditulis ke datafile
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
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.
19 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.
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.
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,
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.
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-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.
22 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.
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, 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.
24 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 read-only.
25
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.
26 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 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.
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.
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 Budgeting, dapat menekan biaya upgrade sistem yang mahal.
28 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.
29 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.
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.
31 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 load balanced kepada seluruh instance RAC yang aktif.
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
33 tidak direncanakan. Tabel 3.1 Penyebab dan maksimal downtime yang ditetapkan user Kategori
Tipe
Deskripsi
Contoh
Tidak direncanakan
Kerusakan komputer/server
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/kehilan gan data Pada saat h/w maupun s/w menyebabkan data tidak dapat diakses dan ditulis oleh database
Kerusakan database Kerusakan OS Kerusakan dari oracle instance Kerusakan dari kartu jaringan
Kerusakan media penyimpanan data
Kesalahan manusia
Kerusakan data
Kerusakan/kehanc uran lokasi
Direncanakan
Perubahan system
Pada saat lokasi server database mengalami kerusakan/kehancu ran besar Pada saat merencanakan untuk melakukan pengembangan sistem, operasi perawatan sistem
Max Downtime < 5 detik
Kerusakan disk drive Kerusakan disk controller Kerusakan storage
< 5 menit
Menghapus objek database Kekeliruan merubah data Penghilangan data
< 5 menit
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
< 5 menit
Menambah/memindah kan server Menambah/memindah kan node pada cluster Menambah/memindah kan disk drive Merubah konfigurasi parameter Upgrade/patching s/w
< 5 menit
< 5 menit
Berdasarkan analisa kebutuhan yang di tetapkan oleh user maka teknologi
34 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 Kerusakan komputer
Solusi RAC
Data Guard
Kerusakan storage
Data Guard
RAC dengan ASM Kesalahan manusia
Data Guard
Data corrupt
Data Guard
Kerusakan lokasi
Data Guard
Keuntungan Perbaikan kerusakan node dan instance secara otomatis Fast start failover dan fast connection failover Fast start failover dan fast connection failover Mirroring dan balance data Fast start failover dan fast connection failover Validasi otomatis block redo sebelum diapply, memindahkan ke standby database Fast start failover dan fast connection failover
Waktu perbaikan Tidak ada downtime
Detik – 5 menit
Detik – 5 menit
Tidak ada downtime Detik – 5 menit
Detik – 5 menit
Detik – 5 menit
Tabel 3.3 Solusi Oracle High availability untuk downtime direncanakan dengan menggunakan RAC dan Data Guard Tipe Upgrade sistem dan perangkat OS upgrade Patching CRS upgrades Upgrade sistem dan cluster
Solusi RAC
Waktu perbaikan Tidak ada downtime
RAC RAC Data Guard RAC Data Guard
Tidak ada downtime Tidak ada downtime Detik – menit Tidak ada downtime Detik – menit
Dengan menggabungkan/mengkombinasikan scalability/skalabilitas dan
35 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.
3. Penggunaan resource system secara efisien. Standby database ter-update
36 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 Kerusakan komputer Kerusakan storage Kerusakan data Kerusakan lokasi
RAC Tidak ada downtime Tidak ada downtime Hitungan jam Jam – Hari
Data Guard Detik – 5 menit Tidak ada downtime Detik – 5 menit Detik – 5 menit
RAC + Data Guard Tidak ada downtime Tidak ada downtime Detik – 5 menit Detik – 5 menit
Tabel 3.5 Waktu downtime yang diperlukan untuk kerusakan direncanakan Tipe Perubahan sistem Upgrade sistem Upgrade cluster Migrasi storage Patching database Perubahan data
RAC Tidak ada downtime Tidak ada downtime Menit – jam Tidak ada downtime Tidak ada downtime Tidak ada downtime
Data Guard Tidak ada downtime Detik – 5 menit Detik – 5 menit Tidak ada downtime Detik – 5 menit Tidak ada downtime
RAC + Data Guard Tidak ada downtime Tidak ada downtime Detik – 5 menit Tidak ada downtime Tidak ada downtime Tidak ada downtime
37 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.
Gambar 3.1 Arsitektur RAC dan Data Guard
38 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
39 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
Oracle Clusterware
Oracle Database
3.2.1
Kegunaan
Jumlah
Ukuran
Clusterware Engine (tidak di share ) Cluster Registry Voting Disk RDBMS Engine (tidak di share ) SYSTEM tablespace: SYSAUX tablespace
1 untuk tiap server 2 3 1 untuk tiap server 1
10000m
Nama Partisi (opsional) /oracle/crs
100m 20m 10000
ora_ocr_raw[n]_100m ora_vote_raw[n]_20m /oracle/rdbms
500m
[dbname]_system_raw_500m
1
300 + (jumlah instance * 250)
[dbname]_sysaux_raw_800m
UNDOTBSn tablespace
[Jumlah Instance]
TEMP tablespace
1
EXAMPLE tablespace
1
USERS tablespace
1
online redo log files
2* number of instances
control files
2
Server parameter file
1
Password file
1
500m
250m 160m 120m
[dbname]_undotbs[n]_raw_5 00m [dbname]_temp_raw_250m [dbname]_example_raw_160 m [dbname]_users_raw_120m
120m
[dbname]_redo[n]_[m]_raw_ 120m
110m
[dbname]_control[n]_raw_11 0m
5m 5m
[dbname]_spfile_raw_5m [dbname]_pwdfile_raw_5m
Standar Operasi Penanggulangan Keadaan Darurat
40 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.
41
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.
42
Gambar 3.3 Kondisi keadaan darurat II
43 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. 5. Instalasi Oracle ASM instance
44 Pada tahap ini dilakukan instalasi ASM disalah satu node RAC, agar setiap node RAC dapat saling terhubung dengan shared storage. 6. Instalasi Oracle database software Pada tahap ini dilakukan instalasi Oracle software pada setiap node RAC. 7. Membuat Oracle database Pada tahap ini dilakukan pembuatan database
4.1.1 Konfigurasi Raw Device pada Shared storage 1 – Format Disk root@af-coredb06 # format Searching for disks...done c2t0d3: configured with capacity of 26.51GB c2t0d4: configured with capacity of 26.51GB AVAILABLE DISK SELECTIONS: 0. c1t0d0 <SUN146G cyl 14087 alt 2 hd 24 sec 848> /pci@9,600000/SUNW,qlc@2/fp@0,0/ssd@w2100000087437a73,0 1. c1t1d0 <SUN146G cyl 14087 alt 2 hd 24 sec 848> /pci@9,600000/SUNW,qlc@2/fp@0,0/ssd@w2100000087438659,0 2. c2t0d0
/pci@8,600000/fibre-channel@1/sd@0,0 3. c2t0d1 /pci@8,600000/fibre-channel@1/sd@0,1 4. c2t0d2 /pci@8,600000/fibre-channel@1/sd@0,2 5. c2t0d3 /pci@8,600000/fibre-channel@1/sd@0,3 6. c2t0d4 /pci@8,600000/fibre-channel@1/sd@0,4 7. c2t0d5
45 /pci@8,600000/fibre-channel@1/sd@0,5 8. c2t0d6 /pci@8,600000/fibre-channel@1/sd@0,6 9. c2t0d7 /pci@8,600000/fibre-channel@1/sd@0,7 10. c2t0d8 /pci@8,600000/fibre-channel@1/sd@0,8 11. c2t0d9 /pci@8,600000/fibre-channel@1/sd@0,9 12. c2t0d10 /pci@8,600000/fibre-channel@1/sd@0,a Specify disk (enter its number): 2 selecting c2t0d0 [disk formatted]
FORMAT MENU: … partition
- select (define) a partition table
… !
- execute , then return
quit format> p
2 – Membuat partisi partition> p Current partition table (original): Total disk cylinders available: 1448 + 2 (reserved cylinders) --part/s 0 utk OCR --part/s 1 utk Voting --part/s 6 utk database
Part
Tag
0 unassigned
Flag wm
Cylinders 1 -
11
Size 206.25MB
Blocks (11/0/0)
422400
46 1 unassigned
wu
2
backup
13 -
23
206.25MB
wu
0 - 1447
26.51GB
3 unassigned
wm
0
0
(0/0/0)
0
4 unassigned
wm
0
0
(0/0/0)
0
5 unassigned
wm
0
0
(0/0/0)
0
6 unassigned
wm
7 unassigned
wm
25 - 1444 0
26.00GB 0
(11/0/0)
(1448/0/0) 55603200
(1420/0/0) 54528000 (0/0/0)
partition>label
# chown oracle:dba utk semua raw device
3 – Sign directory kepada user untuk masing-masing node Node 1 dan
Node 2
-----------------------#chown root:dba /dev/rdsk/c2t0d0s0 #chmod 660 /dev/dsk/c2t0d0s0 #chown oracle:dba /dev/rdsk/c2t0d0s1 #chmod 660 /dev/dsk/c2t0d0s1
#vi /etc/system set noexec_user_stack=1 set semsys:seminfo_semmni=100 set semsys:seminfo_semmns=1024 set semsys:seminfo_semmsl=256 set semsys:seminfo_semvmx=32767 set shmsys:shminfo_shmmax=4294967295 set shmsys:shminfo_shmmni=100 set shmsys:shminfo_shmmin=1 set shmsys:shminfo_shmseg=10 set nfssrv:nfs_portmon=1 #vi /etc/hosts.equiv af-coredb07 oracle
422400
0
47 af-coredb06 oracle af-coredb07 root af-coredb06 root
#vi /etc/hosts 127.0.0.1
localhost
10.71.1.40
af-coredb07
10.71.1.39
af-coredb06
10.0.0.11
af-coredb07-priv
10.0.0.10
af-coredb06-priv
10.71.1.201
af-coredb07-vip
10.71.1.202
af-coredb06-vip
4.1.2
loghost
Instalasi Cluster Ware
clusterware
./runinstaler
•
klik Next
•
Klik Next
•
Klik Next
•
specify cluster configuration
•
cluster name : crs
48
•
Klik add, tambahkan node 2: 9 public : af-coredb07 9 private: af-coredb07-priv 9 virtual: af-coredb07-vip
•
specify network interface usage
49
•
Klik edit, pilih IP untuk public dan private 9 ce0 public 9 ce2 private
•
OCR disk location
•
Klik external redundancy 9 /dev/rdsk/c2t0d0s0
•
Voting disk location
•
Klik external redundancy 9 /dev/rdsk/c2t0d0s1
•
Klik Install
•
Installing Oracle Cluster Ware
•
Pada user root jalankan script dimasing - masing node (setelah selesai node 1 jalankan di node 2)
50 # orainstRoot.Sh # root.sh
Jalankan VIP Configuration Assistant •
Setelah manjalankan script diatas, buka console baru # cd apps/oracle/product/10.2.0/crs_1/bin/ # ./vipca
•
Klik Next
51
•
Isi IP Alias, IP Address dan Subnet Mask lalu klik Next
•
Klik Finish
52
•
End Of Installation
53 Periksa cluster $ cd /apps/oracle/product/CRS/bin/ $./crs_stat -t
$cd /apps/oracle/product/CRS/bin $./olsnodes
$ ps -ef|grep crs oracle
2415
2031
0 13:48:43 ?
0:00
/apps/oracle/product/10.2.0/crs_1/bin/evmlogger.bin -o /apps/oracle/product/10. root
1859
1
0 13:48:30 ?
0:02
/apps/oracle/product/10.2.0/crs_1/bin/crsd.bin reboot oracle
1856
1
0 13:48:30 ?
0:00 sh -c sh -c 'ulimit -c unlimited;
cd /apps/oracle/product/10.2.0/crs_1/log/af-c oracle
2031
1856
0 13:48:33 ?
0:00
/apps/oracle/product/10.2.0/crs_1/bin/evmd.bin oracle
2164
2162
0 13:48:35 ?
0:00
/apps/oracle/product/10.2.0/crs_1/bin/ocssd.bin oracle
2160
2025
0 13:48:35 ?
0:00 sh -c /bin/sh -c 'ulimit -c
unlimited; cd /apps/oracle/product/10.2.0/crs_1/log root
2100
2024
0 13:48:33 ?
0:00
/apps/oracle/product/10.2.0/crs_1/bin/oprocd run -t 1000 -m 500 oracle
2162
2160
0 13:48:35 ?
0:00 /bin/sh -c ulimit -c unlimited; cd
/apps/oracle/product/10.2.0/crs_1/log/af-cor oracle
2765
2764
0 13:48:52 ?
0:00
/apps/oracle/product/10.2.0/crs_1/opmn/bin/ons -d oracle 28546 oracle
2764
6268 1
0 14:04:08 pts/4
0:00 grep crs
0 13:48:52 ?
0:00
/apps/oracle/product/10.2.0/crs_1/opmn/bin/ons –d
54 4.1.3 - Install Database Engine -
software only
-
ASM
Global Database Name : rptdb.com
$./runInstaller •
Klik Next
•
Pilih tipe instalasi
•
Klik Enterprise Edition •
Klik Next
55
•
Klik Cluster Installation tambahkan node 2 (af-coredb07)
•
Checking Prerequisite
•
Klik Install database software only
•
Klik Install
56 Pada user root jalankan script dimasing – masing node ( setelah node 1 selesai jalankan di node 2) # root.sh
4.1.4
Membuat database
$ dbca
•
Jika cluster node sudah terbentuk, pada Database Configuration Assistant akan muncul menu : Oracle Application Cluster
57 •
Klik Next
•
Klik Create Database
•
Pilih node yang akan menjadi anggota cluster, klik Next
•
Pilih template Database klik Next
•
Buat nama untuk database, klik Next
•
Klik Next
•
Masukan password sys dan system
•
Pilih Automatic Storage Management
•
Pilih directory untuk pfile
58
•
Buat ASM
•
Buat Listener
•
Buat disk group, klik Create New
•
Disk Group terbentuk
59
•
Buat directori untuk tablespace system pada disk group 1 (+DGROUP01)
•
Buat Database, klik finish
•
Database terbentuk dengan URL untuk Enterprise Manager : http://af-coredb:1158/em
tnsnames.ora pada server
LISTENERS_DBRPT = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = af-coredb06-vip)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = af-coredb07-vip)(PORT = 1521)) ) LISTENERS_RPTDB = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = af-coredb06-vip)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = af-coredb07-vip)(PORT = 1521))
60 ) DBRPT2 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = af-coredb07-vip)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = dbrpt.com) (INSTANCE_NAME = dbrpt2) ) )
DBRPT1 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = af-coredb06-vip)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = dbrpt.com) (INSTANCE_NAME = dbrpt1) ) ) DBRPT = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = af-coredb06-vip)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = af-coredb07-vip)(PORT = 1521)) (LOAD_BALANCE = yes) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = dbrpt.com) ) )
61 $ vi .profile #
This is the default standard profile provided to a user.
#
They are expected to edit it to meet their own needs.
ORACLE_HOME=/apps/oracle/product/10.2.0/db_1;export ORACLE_HOME LD_LIBRARY_PATH=$ORACLE_HOME/lib;export LD_LIBRARY_PATH CRS_HOME=/apps/oracle/product/10.2.0/crs_1;export CRS_HOME PATH=/usr/bin:$ORACLE_HOME/bin:$CRS_HOME/bin
tnsnames.ora pada client LISTENERS_DBRPT = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 10.71.1.39)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = 10.71.1.40)(PORT = 1521)) )
DBRPT2 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 10.71.1.40)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = dbrpt.com) (INSTANCE_NAME = dbrpt2) ) ) DBRPT1 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 10.71.1.39)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = dbrpt.com) (INSTANCE_NAME = dbrpt1) ) )
62 DBRPT = (DESCRIPTION = (LOAD_BALANCE = yes) (FAILOVER=ON) (ENABLE=BROKEN) (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 10.71.1.39)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = 10.71.1.40)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = dbrpt.com) (FAILOVER_MODE=(TYPE=SELECT)(METHOD=BASIC)) ) )
Perintah pada ASM Membuat tablespace create tablespace tablespace_name datafile '+dgroup08/file_name' size 8192M blocksize 32k extent management local uniform size 1048576;
Tambah datafile ALTER TABLESPACE "RPT_ADT_TAB" ADD DATAFILE '+DGROUP05/file_name02' SIZE 8000M AUTOEXTEND ON NEXT 8M MAXSIZE 26500M
ALTER TABLESPACE "RPT_ADT_TAB" ADD DATAFILE '+DGROUP06/file_name03' SIZE 8000M AUTOEXTEND ON NEXT 8M MAXSIZE 26500M
63 4.2
Membuat Single Instance Physical Standby untuk Primary RAC
4.2.1
Mengumpulkan file dan melakukan backup 1. Pada primary node, buat sebuah direktori staging : $ mkdir -p /opt/oracle/stage
2. Buat path yang sama pada host standby : $ mkdir -p /opt/oracle/stage
3. Pada primary node, buat PFILE dari SPFILE pada direktori staging: SQL> CREATE PFILE='/opt/oracle/stage/initPRIMARY.ora' FROM SPFILE;
4. Pada primary node, lakukan backup menggunakan RMAN pada primary
database dan letakkan backup pada staging direktori.
$ rman target / RMAN> BACKUP DEVICE TYPE DISK FORMAT '/opt/oracle/stage/%U' DATABASE PLUS ARCHIVELOG; RMAN>
BACKUP
DEVICE
TYPE
DISK
FORMAT
'/opt/oracle/stage/%U'
CURRENT
CONTROLFILE FOR STANDBY;
5. Letakkan copy dari file listener.ora, tnsnames.ora, dan sqlnet.ora ke direktori staging. $ cp $ORACLE_HOME/network/admin/*.ora /opt/oracle/stage
6. Copy seluruh file pada direktori staging di RAC node ke direktori staging host standby. scp /opt/oracle/stage/*
oracle@host_name:/opt/oracle/stage
64 4.2.2 Konfigurasi Oracle Net Services pada Standby Database 1. Copy file listener.ora, tnsnames.ora, dan sqlnet.ora dari direktori staging di host standby ke direktori $ORACLE_HOME/network/admin di host standby. 2. Modifikasi file listener.ora pada host standby sesuai dengan hostname pada host standby. 3. Modifikasi file tnsnames.ora file pada setiap node, termasuk node – node primary RAC dan host standby, dan diisikan net service names semua primary dan standby.
Konfigurasi file TNS Names Primary Net Service Names
Standby Net Service Names
DBRPT1 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = af-coredb06-vip) (PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = dbrpt.com) (INSTANCE_NAME = dbrpt1) ) )
DBRPT_STBY = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = stby_host1) (PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = dbrpt.com) (INSTANCE_NAME = dbrpt_stby) ) )
DBRPT2 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = af-coredb07-vip) (PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = dbrpt.com) (INSTANCE_NAME = dbrpt2) ) )
65 4.2.3
Membuat Physical Standby Database 1. Untuk mengaktifkan transmisi redo data yang aman, pastikan physical dan standby database menggunakan file password, dan pastikan password untuk user SYS sama persis pada setiap server. $ cd $ORACLE_HOME/dbs $ orapwd file=orapwDBRPT_STBY password=oracle
2. Copy dan rubah PFILE primary database dari area staging di standby host ke direktori $ORACLE_HOME/dbs di standby host. [oracle@boston_host1 stage]$ cp initPRIMARY.ora $ORACLE_HOME/dbs/initSTANDBY.ora
3. Modifikasi file parameter inisialisasi standby database untuk mengganti parameter RAC dengan parameter Data Guard.
Kategori Parameter Parameter RAC
Parameter Data Guard
Sebelum
Sesudah
*.cluster_database=true *.db_unique_name=DBRPT DBRPT1.instance_name=DBRPT1 DBRPT2.instance_name=DBRPT2 DBRPT1.instance_number=1 DBRPT2.instance_number=2 DBRPT1.thread=1 DBRPT2.thread=2 DBRPT1.undo_tablespace=UNDOTBS1 DBRPT2.undo_tablespace=UNDOTBS2 *.remote_listener=LISTENERS_DBRPT DBRPT1.LOCAL_LISTENER=LISTENER_DBRPT_ HOST1 DBRPT2.LOCAL_LISTENER=LISTENER_DBRPT_ HOST2
*.cluster_database=false *.db_unique_name=DBRPT_SBY *.instance_name=DBRPT_STBY *.thread=1 *.undo_tablespace=UNDOTBS1
*.log_archive_config='dg_confi g= (DBRPT_STBY,DBRPT)' *.log_archive_dest_2='service= DBRPT1_SERV valid_for=(online_logfiles,pri mary_role) db_unique_name=DBRPT' *.db_file_name_convert='+DATA/ DBRPT/', '+DATA/DBRPT_STBY/','+RECOVERY /DBRPT', '+RECOVERY/DBRPT_STBY' *.log_file_name_convert='+DATA /DBRPT/', '+DATA/DBRPT_STBY/','+RECOVERY /DBRPT',
66
Parameter lainnya
*.background_dump_dest= $ORACLE_BASE/admin/DBRPT/bdump *.core_dump_dest= $ORACLE_BASE/admin/DBRPT/cdump *.user_dump_dest= $ORACLE_BASE/admin/DBRPT/udump *.audit_file_dest= $ORACLE_BASE/admin/DBRPT/adump *.db_recovery_dest=’+RECOVERY’ *.log_archive_dest_1 = 'LOCATION=+DATA/DBRPT/' *.dispatchers=DBRPTXD
'+RECOVERY/DBRPT_STBY' *.standby_file_management=auto *.fal_server='DBRPT1_SERV','DB RPT2_SERV' *.fal_client='DBRPT_STBY' *.service_names='DBRPT_STBY' *.background_dump_dest= $ORACLE_BASE/admin/DBRPT_STBY/ bdump *.core_dump_dest= $ORACLE_BASE/admin/DBRPT_STBY/ cdump *.user_dump_dest= $ORACLE_BASE/admin/DBRPT_STBY/ udump *.audit_file_dest= $ORACLE_BASE/admin/DBRPT_STBY/ adump *.db_recovery_dest=’+RECOVERY’ *.log_archive_dest_1= 'LOCATION=USE_DB_RECOVERY_FILE _DEST' *.dispatchers=DBRPT_STBYXD
4. Lakukan koneksi ke instance ASM di standby host, dan buat direktori untuk
group
disk
DATA
dengan
nama
yang
sama
dengan
DB_UNIQUE_NAME dari physical standby database. SQL> ALTER DISKGROUP data ADD DIRECTORY '+DATA/DBRPT_STBY';
5. Lakukan koneksi ke physical standby database, dengan kondisi IDLE, dan buat sebuah SPFILE pada disk group DATA standby. SQL> CREATE SPFILE='+DATA/DBRPT_STBY/spfileDBRPT_STBY.ora' FROM PFILE='?/dbs/DBRPT_STBY.ora';
6. Pada direktori $ORACLE_HOME/dbs di host standby., buat PFILE dengan nama initoracle_sid.ora yang berisi pointer ke SPFILE. [oracle@standby_host1 oracle]$ cd $ORACLE_HOME/dbs [oracle@standby_host1 dbs]$ echo "SPFILE='+DATA/DBRPT_STBY/spfileDBRPT_STBY.ora'" > initDBRPT_STBY.ora
67 7. Buat direktori dump di host standby sebagai referensi di file inisialisasi parameter standby. [oracle@standby_host1 oracle]$ mkdir -p $ORACLE_BASE/admin/DBRPT_STBY/bdump [oracle@standby_host1 oracle]$ mkdir -p $ORACLE_BASE/admin/DBRPT_STBY/cdump [oracle@standby_host1 oracle]$ mkdir -p $ORACLE_BASE/admin/DBRPT_STBY/udump [oracle@standby_host1 oracle]$ mkdir -p $ORACLE_BASE/admin/DBRPT_STBY/adump
8. Setelah melakukan setting pada variabel environment di host standby, seperti ORACLE_SID, ORACLE_HOME, dan PATH, jalankan instance physical standby database instance tanpa mounting ke control file. SQL> STARTUP NOMOUNT
9. Dari host standby, duplikasi primary database sebagai standby ke dalam group disk ASM. $ rman target sys/oracle@DBRPT1_SERV auxiliary / RMAN> DUPLICATE TARGET DATABASE FOR STANDBY;
10.Lakukan koneksi ke physical standby database, dan buat redo logs standby untuk mendukung role standby. Redo logs standby harus memiliki ukuran yang sama dengan primary database online logs. (maximum # of logfiles +1) * maximum # of threads
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 5 SIZE 10M, GROUP 6 SIZE 10M, GROUP 7 SIZE 10M; SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 GROUP 8 SIZE 10M, GROUP 9 SIZE 10M,
68 GROUP 10 SIZE 10M;
Statement ini membuat dua member log tiap grup di standby dan tiap member berukuran 10M. satu member di buat pada direktori yang di spesifikasikan oleh inisialisasi parameter DB_CREATE_FILE_DEST , dan member lain di buat pada direktori yang di spesifikasikan oleh inisialisasi parameter DB_RECOVERY_FILE_DEST Periksa nomor dan nomor grup dari redolog dengan .melihat V$LOG: SQL> SELECT * FROM V$LOG;
Periksa
hasil
dari
statetement
sebelumnya
dengan
melihat
V$STANDBY_LOG. SQL> SELECT * FROM V$STANDBY_LOG;
Untuk melihat pembuatan member dengan melihat V$LOGFILE. SQL> SELECT * FROM V$LOGFILE;
11. Jalankan managed recovery dan aplikasikan real-time pada standby database: SQL>
ALTER
DATABASE
RECOVER
MANAGED
STANDBY
DATABASE
USING
CURRENT
LOGFILE DISCONNECT;
4.2.4
Konfigurasi Primary Database untuk Data Guard 1. Konfigurasi parameter primary database untuk men-support role primary dan standby. *.log_archive_config='dg_config=(DBRPT_STBY,DBRPT)' *.log_archive_dest_2='service=DBRPT_STBY valid_for=(online_logfiles,primary_role) db_unique_name=DBRPT_STBY' *.db_file_name_convert='+DATA/DBRPT_STBY/',’+DATA/DBRPT/', ’+RECOVERY/DBRPT_STBY’,’+RECOVERY/DBRPT’
69 *.log_file_name_convert='+DATA/DBRPT_STBY/',’+DATA/DBRPT/', ’+RECOVERY/DBRPT_STBY’,’+RECOVERY/DBRPT’ *.standby_file_management=auto *.fal_server='DBRPT_STBY' DBRPT1.fal_client='DBRPT1_SERV' DBRPT2.fal_client='DBRPT2_SERV' *.service_names=DBRPT
2. Buat standby redo logs di primary database untuk men-support role standby. Ukuran standby redo logs sama dengan ukuran primary database online logs. SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 5 SIZE 10M, GROUP 6 SIZE 10M, GROUP 7 SIZE 10M; SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 GROUP 8 SIZE 10M, GROUP 9 SIZE 10M, GROUP 10 SIZE 10M;
4.2.5
Verifikasi Konfigurasi Data Guard 1. Pada physical standby database, Lihat file yang eksis di archived redo log dengan melihat V$ARCHIVED_LOG SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
2. Pada primary database SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
3. Pada physical standby database, Lihat V$ARCHIVED_LOG untuk memverifikasi redo data yang diterima dan archived di standby
70 database. SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
4.3
Skenario Pengujian Skenario pengujian yang akan dilakukan untuk menguji arsitektur DRP
adalah : 1. Pengujian dilakukan selama 2 hari pada malam hari (23.00 WIB), dimulai pada Minggu 08 Juni 2008 – Senin 09 Juni 2008 karena sistem DRP tersebut hanya dapat dilakukan proses downtime pada malam hari. 2. Pengujian dilakukan pada satu buah sistem/node RAC dan satu buah server dataguard yang menjalankan physical standby database server. 3. Pengujian dilakukan dengan mengacu pada aplikasi/tool SQLPlus, untuk melakukan dan menjalankan perintah-perintah switchover/failover dan untuk mengetahui waktu downtime yang terjadi. 4. Data untuk pengujian tidak menggunakan data sebenarnya dan diletakkan pada storage yang sama dengan data sebenarnya.
71 4.3.1
Pengujian Keadaan Darurat I ( Sistem Komputer/RAC Node ) 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 4.1 Kondisi keadaan darurat I 4.3.1.1 Mengaktifkan instance RAC per-node oracle@node1> srvctl start nodeapps -n dbrpt1 oracle@node1> srvctl start instance -d dbrpt -i dbrpt1 oracle@node2> srvctl start nodeapps -n dbrpt2 oracle@node2> srvctl start instance -d dbrpt -i dbrpt2
72 4.3.1.2 Mengaktifkan/mematikan database RAC oracle@gentic> srvctl start database -d dbrpt oracle@gentic> srvctl stop database -d dbrpt
4.3.1.3 Pengujian Transparent Application Failover (TAF) Pengujian dilakukan dari Non-RAC klien yang terhubung dengan node RAC pada hari Minggu 08 Juni 2008. oracle@klien> ping af-coredb06-vip PING af-coredb06-vip (10.71.1.39) 56(84) bytes of data. 64 bytes from af-coredb06-vip (10.71.1.39): icmp_seq=1 ttl=64 time=2.17 ms 64 bytes from af-coredb06-vip (10.71.1.39): icmp_seq=2 ttl=64 time=1.20 ms
oracle@klien> ping af-coredb07-vip PING af-coredb07-vip (10.71.1.40) 56(84) bytes of data. 64 bytes from af-coredb07-vip (10.71.1.40): icmp_seq=1 ttl=64 time=2.41 ms 64 bytes from af-coredb07-vip (10.71.1.40): icmp_seq=2 ttl=64 time=1.30 ms oracle@klien> tnsping dbrpt TNS
Ping
Utility
for
Linux:
Version
10.2.0.4.0
-
Production
on
10-MAY-2008
11:35:46 Used parameter files: /apps/oracle/product/10.2.0/sqlnet.ora Used TNSNAMES adapter to resolve the alias Attempting
to
contact
(DESCRIPTION
=
(ADDRESS
=
(PROTOCOL
=
TCP)(HOST
=
af-
coredb06-vip) (PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = af-coredb07-vip)(PORT = 1521)) (LOAD_BALANCE = yes) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = DBRPT) (FAILOVER_MODE = (TYPE = SELECT) (METHOD = BASIC) (RETRIES = 180) (DELAY = 5))))OK (0 msec)
Query SQL dapat digunakan untuk memeriksa tipe failover, metode failover, dan jika proses failover terjadi. SQL> COLUMN instance_name FORMAT a13 COLUMN host_name FORMAT a9 COLUMN failover_method FORMAT a15 COLUMN failed_over FORMAT a11 SELECT DISTINCT v.instance_name AS instance_name, v.host_name AS host_name,
73 s.failover_type AS failover_type, s.failover_method AS failover_method, s.failed_over AS failed_over FROM v$instance v, v$session s WHERE s.username = 'SYSTEM';
INSTANCE_NAME HOST_NAME
FAILOVER_TYPE FAILOVER_METHOD FAILED_OVER
------------- ---------------
------------- --------------- -----------
dbrpt2
SELECT
af-coredb07
BASIC
NO
Buat table pada instance dbrpt2 SQL> create table test 2 ( nama varchar2(30)); Table created.
Masukkan data dan lakukan commit SQL> insert into test 2 values 3 ('Gugun Gunawan'); 1 row created. SQL> commit; Commit complete.
Lihat data yang baru saja kita masukkan kedalam table. SQL> select * from test; NAME -----------------------------Gugun Gunawan
SQL> select to_char(sysdate,'dd-mon-yyyy:hh24:mi:ss') from dual; TO_CHAR(SYSDATE,'DD-------------------08-jun-2008:23:08:30
Terlihat, kita terkoneksi dengan instance dbrpt2 yang berjalan pada af-coredb07. Sekarang kita akan mematikan instance ini tanpa memutuskan koneksi dari klien. oracle@node2> srvctl status database -d dbrpt Instance dbrpt1 is running on node af-coredb06 Instance dbrpt2 is running on node af-coredb07 oracle@node2> srvctl stop instance -d dbrpt -i dbrpt2 -o abort oracle@node2> srvctl status database -d dbrpt Instance dbrpt1 is running on node af-coredb06 Instance dbrpt2 is not running on node af-coredb07
74 Sekarang kita lihat kembali session SQL kita pada klien SQL> COLUMN instance_name FORMAT a13 COLUMN host_name FORMAT a9 COLUMN failover_method FORMAT a15 COLUMN failed_over FORMAT a11 SELECT DISTINCT v.instance_name AS instance_name, v.host_name AS host_name, s.failover_type AS failover_type, s.failover_method AS failover_method, s.failed_over AS failed_over FROM v$instance v, v$session s WHERE s.username = 'SYSTEM'; INSTANCE_NAME HOST_NAME ------------- ----------dbrpt1 af-coredb06
FAILOVER_TYPE FAILOVER_METHOD FAILED_OVER ------------- --------------- ----------SELECT BASIC YES
Kita lihat kembali data pada table test. SQL> select * from test; NAME -----------------------------Gugun Gunawan
SQL> select to_char(sysdate,'dd-mon-yyyy:hh24:mi:ss') from dual; TO_CHAR(SYSDATE,'DD-------------------08-jun-2008:23:08:33
Terlihat bahwa telah terjadi proses failover pada session menuju ke instance dbrpt1 di af-coredb06 secara otomatis dan tanpa terjadi downtime sama sekali, dan klien masih dapat melihat data pada database tanpa dipengaruhi oleh kerusakan yang terjadi pada salah satu node. Pengujian kedua dilakukan dari Non-RAC klien yang terhubung dengan node RAC pada hari Senin 09 Juni 2008. oracle@klien> ping af-coredb06-vip PING af-coredb06-vip (10.71.1.39) 56(84) bytes of data. 64 bytes from af-coredb06-vip (10.71.1.39): icmp_seq=1 ttl=64 time=2.19 ms 64 bytes from af-coredb06-vip (10.71.1.39): icmp_seq=2 ttl=64 time=1.35 ms oracle@klien> ping af-coredb07-vip PING af-coredb07-vip (10.71.1.40) 56(84) bytes of data.
75 64 bytes from af-coredb07-vip (10.71.1.40): icmp_seq=1 ttl=64 time=2.48 ms 64 bytes from af-coredb07-vip (10.71.1.40): icmp_seq=2 ttl=64 time=1.36 ms oracle@klien> tnsping dbrpt TNS
Ping
Utility
for
Linux:
Version
10.2.0.4.0
-
Production
on
10-MAY-2008
11:35:46 Used parameter files: /apps/oracle/product/10.2.0/sqlnet.ora Used TNSNAMES adapter to resolve the alias Attempting
to
contact
(DESCRIPTION
=
(ADDRESS
=
(PROTOCOL
=
TCP)(HOST
=
af-
coredb06-vip) (PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = af-coredb07-vip)(PORT = 1521)) (LOAD_BALANCE = yes) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = DBRPT) (FAILOVER_MODE = (TYPE = SELECT) (METHOD = BASIC) (RETRIES = 180) (DELAY = 5))))OK (0 msec)
Query SQL dapat digunakan untuk memeriksa tipe failover, metode failover, dan jika proses failover terjadi. SQL> COLUMN instance_name FORMAT a13 COLUMN host_name FORMAT a9 COLUMN failover_method FORMAT a15 COLUMN failed_over FORMAT a11 SELECT DISTINCT v.instance_name AS instance_name, v.host_name AS host_name, s.failover_type AS failover_type, s.failover_method AS failover_method, s.failed_over AS failed_over FROM v$instance v, v$session s WHERE s.username = 'SYSTEM';
INSTANCE_NAME HOST_NAME
FAILOVER_TYPE FAILOVER_METHOD FAILED_OVER
------------- ---------------
------------- --------------- -----------
dbrpt2
SELECT
af-coredb07
Masukkan data dan lakukan commit SQL> insert into test 2 values 3 ('Herry Saputra'); 1 row created. SQL> commit; Commit complete.
BASIC
NO
76 Lihat data yang baru saja kita masukkan kedalam table. SQL> select * from test; NAME -----------------------------Gugun Gunawan Herry Saputra
SQL> select to_char(sysdate,'dd-mon-yyyy:hh24:mi:ss') from dual; TO_CHAR(SYSDATE,'DD-------------------09-jun-2008:23:24:15
Terlihat, kita terkoneksi dengan instance dbrpt2 yang berjalan pada af-coredb07. Sekarang kita akan mematikan instance ini tanpa memutuskan koneksi dari klien. oracle@node2> srvctl status database -d dbrpt Instance dbrpt1 is running on node af-coredb06 Instance dbrpt2 is running on node af-coredb07 oracle@node2> srvctl stop instance -d dbrpt -i dbrpt2 -o abort oracle@node2> srvctl status database -d dbrpt Instance dbrpt1 is running on node af-coredb06 Instance dbrpt2 is not running on node af-coredb07
Sekarang kita lihat kembali session SQL kita pada klien SQL> COLUMN instance_name FORMAT a13 COLUMN host_name FORMAT a9 COLUMN failover_method FORMAT a15 COLUMN failed_over FORMAT a11 SELECT DISTINCT v.instance_name AS instance_name, v.host_name AS host_name, s.failover_type AS failover_type, s.failover_method AS failover_method, s.failed_over AS failed_over FROM v$instance v, v$session s WHERE s.username = 'SYSTEM'; INSTANCE_NAME HOST_NAME ------------- ----------dbrpt1 af-coredb06
FAILOVER_TYPE FAILOVER_METHOD FAILED_OVER ------------- --------------- ----------SELECT BASIC YES
Kita lihat kembali data pada table test. SQL> select * from test; NAME -----------------------------Gugun Gunawan Herry Saputra
77 SQL> select to_char(sysdate,'dd-mon-yyyy:hh24:mi:ss') from dual; TO_CHAR(SYSDATE,'DD-------------------09-jun-2008:23:24:17
Terlihat bahwa telah terjadi proses failover pada session menuju ke instance dbrpt1 di af-coredb06 secara otomatis dan tanpa terjadi downtime sama sekali, dan klien masih dapat melihat data pada database tanpa dipengaruhi oleh kerusakan yang terjadi pada salah satu node. Tabel 4.1 Tabel perbandingan waktu downtime
4.3.2
Hari/Tanggal
Node
Node failover
Waktu downtime
Minggu/08 Juni 2008
af-coredb07
af-coredb06
00:00:03
Senin/09 Juni 2008
af-coredb07
af-coredb06
00:00:02
Pengujian Keadaan Darurat II ( Sistem Komputer/2 RAC Node ) 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.
78
Gambar 4.2 Kondisi keadaan darurat II 4.3.2.1 Pengujian Failover secara Manual ke Physical Standby Database Pengujian dilakukan dari Non-RAC klien yang terhubung dengan node RAC pada hari Minggu 08 Juni 2008. oracle@klien> ping af-coredb06-vip PING af-coredb06-vip (10.71.1.39) 56(84) bytes of data. 64 bytes from af-coredb06-vip (10.71.1.39): icmp_seq=1 ttl=64 time=2.11 ms 64 bytes from af-coredb06-vip (10.71.1.39): icmp_seq=2 ttl=64 time=1.14 ms oracle@klien> ping af-coredb07-vip PING af-coredb07-vip (10.71.1.40) 56(84) bytes of data. 64 bytes from af-coredb07-vip (10.71.1.40): icmp_seq=1 ttl=64 time=2.34 ms 64 bytes from af-coredb07-vip (10.71.1.40): icmp_seq=2 ttl=64 time=1.23 ms oracle@klien> tnsping dbrpt TNS
Ping
Utility
for
Linux:
Version
10.2.0.4.0
-
Production
on
10-MAY-2008
11:35:46 Used parameter files: /apps/oracle/product/10.2.0/sqlnet.ora Used TNSNAMES adapter to resolve the alias Attempting
to
contact
(DESCRIPTION
=
(ADDRESS
=
(PROTOCOL
=
TCP)(HOST
=
af-
coredb06-vip) (PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = af-coredb07-vip)(PORT = 1521)) (LOAD_BALANCE = yes) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = DBRPT)
79 (FAILOVER_MODE = (TYPE = SELECT) (METHOD = BASIC) (RETRIES = 180) (DELAY = 5))))OK (0 msec)
Sekarang kita lihat kembali session SQL kita pada klien dan melihat table test
SQL> select * from test; NAME -----------------------------Gugun Gunawan Herry Saputra SQL> select to_char(sysdate,'dd-mon-yyyy:hh24:mi:ss') from dual; TO_CHAR(SYSDATE,'DD-------------------08-jun-2008:23:10:26
Sekarang kita akan mematikan ke dua instance ini, sehingga ke dua buah node RAC tidak akan berfungsi kembali. oracle@node2> srvctl status database -d dbrpt Instance dbrpt1 is running on node af-coredb06 Instance dbrpt2 is running on node af-coredb07 oracle@node2> srvctl stop instance -d dbrpt -i dbrpt2 -o abort oracle@node2> srvctl stop instance -d dbrpt -i dbrpt1 -o abort oracle@node2> srvctl status database -d dbrpt Instance dbrpt1 is not running on node af-coredb06 Instance dbrpt2 is not running on node af-coredb07
Sekarang kita lihat kembali session SQL kita pada klien dan melihat table test SQL> select * from test; * ERROR at line 1: ORA-03113: end-of-file on communication channel
Terlihat bahwa klien sudah tidak dapat melakukan koneksi ke database, disebabkan sudah tidak terdapat instance untuk melayani permintaan dari klien. Langkah – langkah untuk melakukan failover ke Standby Database 1. Menghentikan status standby database secara paksa dari physical standby: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE;
80 2. Konversikan physical standby database menjadi role production/primary: SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
3. Buka database primary baru: SQL> ALTER DATABASE OPEN;
Sekarang kita lihat kembali session SQL kita pada klien dan melihat table test
SQL> select * from test; NAME -----------------------------Gugun Gunawan Herry Saputra SQL> select to_char(sysdate,'dd-mon-yyyy:hh24:mi:ss') from dual; TO_CHAR(SYSDATE,'DD-------------------08-jun-2008:23:10:30
Pengujian kedua dilakukan dari Non-RAC klien yang terhubung dengan node RAC pada hari Senin 09 Juni 2008. oracle@klien> ping af-coredb06-vip PING af-coredb06-vip (10.71.1.39) 56(84) bytes of data. 64 bytes from af-coredb06-vip (10.71.1.39): icmp_seq=1 ttl=64 time=2.18 ms 64 bytes from af-coredb06-vip (10.71.1.39): icmp_seq=2 ttl=64 time=1.17 ms oracle@klien> ping af-coredb07-vip PING af-coredb07-vip (10.71.1.40) 56(84) bytes of data. 64 bytes from af-coredb07-vip (10.71.1.40): icmp_seq=1 ttl=64 time=2.45 ms 64 bytes from af-coredb07-vip (10.71.1.40): icmp_seq=2 ttl=64 time=1.23 ms oracle@klien> tnsping dbrpt TNS
Ping
Utility
for
Linux:
Version
10.2.0.4.0
-
Production
on
10-MAY-2008
11:35:46 Used parameter files: /apps/oracle/product/10.2.0/sqlnet.ora Used TNSNAMES adapter to resolve the alias Attempting
to
contact
(DESCRIPTION
=
(ADDRESS
=
(PROTOCOL
=
TCP)(HOST
=
af-
coredb06-vip) (PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = af-coredb07-vip)(PORT = 1521)) (LOAD_BALANCE = yes) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = DBRPT)
81 (FAILOVER_MODE = (TYPE = SELECT) (METHOD = BASIC) (RETRIES = 180) (DELAY = 5))))OK (0 msec)
Sekarang kita lihat kembali session SQL kita pada klien dan memasukkan data baru serta melihat table test SQL> insert into test 2 values 3 ('Darmawan Wicaksono'); 1 row created. SQL> commit; Commit complete.
SQL> select * from test; NAME -----------------------------Gugun Gunawan Herry Saputra Darmawan Wicaksono SQL> select to_char(sysdate,'dd-mon-yyyy:hh24:mi:ss') from dual; TO_CHAR(SYSDATE,'DD-------------------09-jun-2008:23:40:13
Sekarang kita akan mematikan ke dua instance ini, sehingga ke dua buah node RAC tidak akan berfungsi kembali. oracle@node2> srvctl status database -d dbrpt Instance dbrpt1 is running on node af-coredb06 Instance dbrpt2 is running on node af-coredb07 oracle@node2> srvctl stop instance -d dbrpt -i dbrpt2 -o abort oracle@node2> srvctl stop instance -d dbrpt -i dbrpt1 -o abort oracle@node2> srvctl status database -d dbrpt Instance dbrpt1 is not running on node af-coredb06 Instance dbrpt2 is not running on node af-coredb07
Sekarang kita lihat kembali session SQL kita pada klien dan melihat table test SQL> select * from test; * ERROR at line 1: ORA-03113: end-of-file on communication channel
Terlihat bahwa klien sudah tidak dapat melakukan koneksi ke database, disebabkan sudah tidak terdapat instance untuk melayani permintaan dari klien.
82 Langkah – langkah untuk melakukan failover ke Standby Database 1. Menghentikan status standby database secara paksa dari physical standby: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE;
2. Konversikan physical standby database menjadi role production/primary: SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
3. Buka database primary baru: SQL> ALTER DATABASE OPEN;
Sekarang kita lihat kembali session SQL kita pada klien dan melihat table test
SQL> select * from test; NAME -----------------------------Gugun Gunawan Herry Saputra Darmawan Wicaksono SQL> select to_char(sysdate,'dd-mon-yyyy:hh24:mi:ss') from dual; TO_CHAR(SYSDATE,'DD-------------------09-jun-2008:23:40:16
Tabel 4.2 Tabel perbandingan waktu downtime Hari/Tanggal
Primary
Node failover
Waktu downtime
Minggu/08 Juni 2008
Dbrpt
dbrpt_stby
00:00:04
Senin/09 Juni 2008
Dbrpt
dbrpt_stby
00:00:03
83 4.3.3
Pengujian Proses Transfer File Archive ke Standby Database Pada pengujian ini akan dilakukan proses switch logfile secara manual
pada primary database, sehingga file archived log yang baru akan ditransfer menuju standby database dan terlihat berapa lama waktu yang diperlukan untuk proses tersebut per file archived log. Pada primary database jalankan query untuk melakukan proses switch log file secara manual : SQL> ALTER SYSTEM SWITCH LOGFILE;
System altered
SQL> SELECT max(sequence#) FROM v$archived_log;
MAX(SEQUENCE#) -------------43031
SQL> select to_char(sysdate,'dd-mon-yyyy:hh24:mi:ss') from dual; TO_CHAR(SYSDATE,'DD-------------------09-jun-2008:23:50:12
Kemudian pada standby database jalankan query untuk mengetahui sequence number archive log yang terakhir diterima oleh standby database. SQL> SELECT max(sequence#) FROM v$archived_log;
MAX(SEQUENCE#) -------------43031
84 SQL> select to_char(sysdate,'dd-mon-yyyy:hh24:mi:ss') from dual; TO_CHAR(SYSDATE,'DD-------------------09-jun-2008:23:50:29
Dari beberapa kali pengujian dengan melakukan proses switch logfile secara manual di dapatkan bahwa rata-rata waktu yang diperlukan untuk proses tersebut < 20 detik. Tabel 4.3 Tabel perbandingan waktu transfer file archive log Hari/Tanggal
Primary
Secondary
Waktu Transefer
Senin/09 Juni 2008
23:50:12
23:50:29
00:00:17
Senin/09 Juni 2008
23:50:35
23:50:51
00:00:16
Senin/09 Juni 2008
23:51:14
23:51:32
00:00:18
Dari seluruh pengujian yang dilakukan, arsitektur high availability yang di inginkan telah terpenuhi dimana waktu proses pengiriman log file rata-rata < 20 detik serta ketersediaan data dan maksimal downtime yang ditetapkan untuk melakukan recovery rata-rata < 3.5 detik, melebihi dari user requirement yaitu < 5 menit. Dan dengan arsitektur ini didapatkan efisiensi dari segi biaya dimana pada standy site hanya menggunakan single instance serta interkoneksi jaringan standar karena proses transfer file sangat kecil.
85 BAB V PENUTUP
Pada bab Penutup dari laporan Tugas Akhir ini, dapat diambil kesimpulan dan saran berdasarkan analisa dan pengujian kinerja High Availability Database System dengan teknologi RAC dan Data Guard dengan metode Single Instance Physical Standby Database, yang dapat bermanfaat bagi Penulis dan Pembaca.
5.1
Kesimpulan Dari seluruh rangkaian uji kinerja RAC dan Data Guard yang telah
dilakukan maka dapat ditarik kesimpulan yaitu: 1. Dengan arsitektur ini didapatkan waktu downtime, baik yang direncanakan maupun tidak direncanakan kurang dari maksimal downtime 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. 2. Dengan arsitektur ini didapatkan proses pengiriman log file ke standby database dengan rata-rata berukuran 20 MB memerlukan waktu < 20 detik.
86 3. Dengan dilakukan prosedur backup pada standby database didapatkan tingkatan availabity yang lebih baik, dimana untuk melakukan backup data sebesar +/- 500 GB, diperlukan waktu +/- 10 jam dalam kondisi shutdown, tanpa harus mengganggu kinerja dari primary database.
5.2
Saran Beberapa saran di akhir dari laporan Tugas Akhir ini antara lain : 1. Disarankan untuk menggunakan arsitektur RAC Instance for Physical Standby Database Server, agar didapatkan kondisi standby site yang sama persis dengan primary site sehingga apabila terjadi kondisi darurat II (primary site tidak dapat diakses) maka masih mampu lagi merecovery kondisi darurat I (salah satu node RAC mengalami kerusakan), dengan konsekuensi penambahan biaya untuk pengadaan server. 2. Disarankan untuk menggunakan aplikasi pihak ketiga untuk melakukan proses manajemen RAC dan data guard berbasis GUI, sehingga user mudah dalam memantau dan melakukan proses manajemen terhadap sistem database, dengan konsekuensi penggunaan resource/memori yang lebih besar dan tambahan biaya utnuk pembelian aplikasi pihak ketiga. 3. Disarankan untuk menggunakan spesifikasi perangkat keras yang lebih tinggi sehingga didapatkan kinerja yang lebih baik. 4. Disarankan untuk terus melakukan patching terhadap software dan aplikasi yang digunakan untuk menghindari bug dan error yang ada.
DAFTAR PUSTAKA
Best, Tom. Oracle Database 10g:Administration Workshop II, student guide. California.Oracle University, 2006 Best, Tom. Oracle Database 10g:RAC Admnistration, student guide. California.Oracle University, 2006 Best, Tom. Oracle Database 10g:Data Guard Administration, student guide. California.Oracle University, 2006 Hutabarat, Bernaridho. Panduan Oracle 8i Untuk Administrator Database. Jakarta.Elex Media Komputindo, 2003 Syamsiar, Evara. Administrasi Database Oracle 10g Jakarta.Elex Media Komputindo, 2006 Kusdeni, Deni. “Apakah Metode Terbaik Untuk DRP”. Jakarta 2005 [online], available:http://dkusdeni.blogspot.com/apakah-metode-terbaik-untuk.html dilihat tanggal,10 Juni 2008 Oracle OTN, “Standby Database Concepts”.California 2006[online], available:http://download-oracle.com/docs/cd/B19306_01/server.102/ b14239/concepts.htm, dilihat tanggal, 10 Juni 2008 Oracle OTN, “Standby Database Concepts”.California 2006[online], available:http://download-oracle.com/docs/cd/B19306_01/server.102/ b14239/standby.htm, dilihat tanggal, 10 Juni 2008 Puspo, Heriyanto, “Artikel tentang BCP/DRP”. Jakarta,2006[online], available: http://puspoheriyanto.blogspot.com/2006/10/ artikel-ttg-bcpdrp.html, Dilihat tanggal, 10 Juni 2008
CONFIDENTIAL FILE
Gugun Gunawan
PERSONAL INFORMATION Address Phone Blog E-mail Place/date of Birth Sex Marital Status Religion
: JL. Basuki Rahmat Rt.005/06 No.50 Cipinang Besar Selatan - Jakarta 13410 : (021) 8579056, 988 56950 (Mobile) : www.mercubuana-it.org/roninmorgue : [email protected] : Jakarta / 03rd May 1980 : Male : Single : Moslem
FORMAL EDUCATION • • • •
2001 - 2008 1995 - 1999 1992 - 1995 1986 - 1992
: S1 Mercu Buana University (Information Technology) : Graduate of SMKN 26 Pembangunan Jakarta : Graduate of SLTPN 149 Jakarta : Graduate of SDN 07 Jakarta
INFORMAL EDUCATION • • • • • • •
Oracle Database 10g : Administration Workshop II (Certificate, OCP) Linux System Administrator and Networking Course in LPK Nurul Fikri (Certificate) Linux Network Security Course in Brainmatics IT Training & Consulting (Certificate) .NET Trainee in Mercu Buana University Network Security Trainee in BPK Virtual Private Network Setting and Configuration Trainee in Bidakara CAD 2000 Course in Bina Citra Komputindo (Certificate)
COMPUTING SKILL •
Operating System
•
Office Program
•
Server
•
Programming
: Ms. Windows XP, 2000, Linux RHELAS, Slackware, Solaris, AIX, HPUX : Ms.Excel, Ms.Words, Ms.Power Point, Ms.Access, Ms. Outlook Open Office : Mail Server (Postfix), DNS (BindDNS), Web Server (Apache), Samba Server, Proxy Server (Squid), IP Tables, Shorewall, WebMin, System Administration, IDS, Honey Pot : PHP, Shell programming, SQL Programming
CONFIDENTIAL FILE
• •
Data Base Networking
: Oracle 10g, 9i and SQL Server 2000 Administration : Linux Networking, Windows Networking, VPN
WORK EXPERIENCE March 2008 – present ( Oracle Software Specialist ) PT. Sisindokom Lintas Buana. – Proklamasi Jakarta Div. – Information System • • • • • • • • •
Handling Oracle configuration and installation Handling Oracle Preventive Maintenance Handling Oracle Support Handling Oracle Data Guard configuration and installation Handling Oracle troubleshooting Handling and control Performance Tuning Database Handling to backup and recovery management Handling Oracle patching and upgrading Make report
July 2006 – March 2008 ( Data Base Administrator, Linux System Administrator ) PT. Matahari Putra Prima, Tbk. – Lippo Karawaci Tangerang At Matahari Club Card (MCC) Div. – Data Base and Research Department • • • • • • • • • • • • •
Handling Oracle 10g and SQL Server 2000 Installation Handling to create Database in Database Server Handling to manage Storage, Instance, Service, Configuration File, Log File in Data Base Server Creating Data File, Tablespace and Table in Data Base Server Handling to manage User, Profile, Privilege and Role Handling to update data (import and export data from other Data Base) Creating DTS and job scheduler Handling and control Performance Tuning Database Handling to backup and recovery management Monitoring Data Base with TOAD, Oracle Enterprise Manager and SQL Profiler Handling to manage Linux Server Administration(Red Hat Enterprise Advanced Server) Handling to manage security at Linux Server with Iptables and shorewall Make report to Data Base Manager
January 2006 – February 2006 PT Indotronix, Jakarta • •
Network Setup and Installation at Tanjung Uban, Batam Software Trainee for client
CONFIDENTIAL FILE
May 2005 – October 2005 PT Dreamhome and Digital Design, Jakarta As OJT (On the Job Training) student • • •
Building IMS (Integreted Management System) with PHP and MySQL Building CMS Web Site (with PHP and MySQL) for www.middleedgemedia.com Building CMS Web Site (with PHP and MySQL) for www.perhumas.or.id
February 2005 – April 2005 Badan Pemeriksa Keuangan, Jakarta As OJT (On the Job Training) student at Sub Biro operational jaringan/networking
June 2000 – July 2001 PT Galang Mitra Sejahtera, Jakarta •
Estimator for structure and architecture
August 1999 – May 2000 LPK Bina Citra Komputindo, Jakarta •
Teacher for CAD (Computer Aided Design)
KEY STRANGE • • • • • • •
Able to communicate in English both written and oral Excellent command of computer literate Able to work both as a team member and individual Self motivated, able to set effective priorities and willing to learn Responsible person, hard working, and discipline Trustworthy, dynamic, self-starter, and punctual. Have knowledge about CRM
AFFILIATION • • • •
Jogja Linux Community X-Code Community ( Hacking and Security) as member and writer (X-Code Magazine) Forum Mercubuana IT as administrator and writer Oracle Community (Oraid)
CONFIDENTIAL FILE
ORGANISATION EXPERIENCE •
BEM FTI Mercu Buana University at Research and Technology (2003-2004)
