Jurnal PETIR Vol. 8 No. 2 September 2015 | 133
IMPLEMENTASI DAN PENGUJIAN
KINERJA ORACLE 10g REAL APLICATION CLUSTER (RAC)
PADA SISTEM OPERASI SUN SOLARIS 10
Gatot Budi Santoso; Yanuar Indra Wirawan
Jurusan Teknik Informatika Fakultas Teknologi Industri Universitas Trisakti Jl Kiai tapa No 1 Grogol, jakarta Barat 11410
e-mail : bulish@gmail.com, gbs@trisakti.ac.id
A b s t r a c t
During the implementation of database system, needs of getting fast, accurate and high-availability data, has become major clauses for the implementation of “high-high-availability” system. Oracle 10g RAC is a clustered database solution that requires a two or more node hardware configuration capable of working together under a clustered operating system. A clustered hardware solution is managed by cluster management software, usually provided by the hardware vendor. The operating system is also responsible for providing access to the shared disk subsystems. Parameters that used for the performance testing and analyzing of Oracle 10g Real Application Cluster are the cpu idle, free memory, SGA, buffer cache, and shared pool. As result for the performance testing and analyzing, it can be concluded that Oracle 10g Real Application Cluster was really good for the implementation of “high-availability system” concept. But it all depends to the analysis for its system.
Keywords: RAC, cluster, instance, shared disk subsystems.
A b s t r a k
Di dalam implementasi sistem database, kebutuhan akan data yang cepat, akurat dan dengan tingkat ketersediaan yang tinggi menjadi sebuah persyaratan utama untuk penerapan konsep “high availability system”. Oracle 10g Real Application Cluster (RAC) adalah sebuah solusi database ter-cluster yang memerlukan dua atau lebih konfigurasi node hardware dan dapat bekerja sama di bawah sebuah sistem operasi yang ter-cluster. Sebuah solusi hardware diatur oleh software manajemen cluster, yang biasanya diberikan oleh vendor hardware tersebut. Sistem operasi juga bertanggung jawab dalam memberikan akses terhadap media penyimpanan yang dipakai bersama-sama. Terdapat beberapa yang digunakan dalam pengujian dan analisa kinerja Oracle 10g Real Application Cluster ini yaitu penggunaan redo log buffer, persentase efisiensi instant, aktifitas library cache,dan buffer pool. Sebagai hasil dari pengujian dan analisa kinerja, dapat disimpulkan bahwa pada dasarnya Oracle 10g Real Application Cluster sangat baik untuk penerapan konsep “high-availability system”. Akan tetapi itu semua sangat bergantung pada baik buruknya analisis kinerja sistem itu sendiri.
Kata kunci : RAC, cluster, instance, shared disk subsystems
1. Pendahuluan
Efektifitas, efisiensi, dan produktivitas sumber daya manusia merupakan tantangan utama yang dihadapi oleh suatu organisasi. Suatu perusahaan terkadang membutuhkan suatu sistem komputasi dengan tingkat keter-sediaan yang tinggi atau yang lebih dikenal
dengan sebutan “high-availability system”.
Apabila sistem komputasi ini mengalami
kegagalan dan membutuhkan waktu dalam hitungan jam atau hari untuk bisa kembali beroperasi,maka perusahaan tersebut akan mengalami kerugian dengan jumlah besar. Sistem komputasi tersebut tidak dapat ber-toleransi terhadap kegagalan walaupun hanya membutuhkan waktu 1 (satu) detik saja untuk kembali beroperasi. Terlebih lagi di dalam implementasi sistem database, kebu-tuhan akan data yang cepat, akurat dan
134 | Jur dengan menjadi penerap Ora banyak base Ma pun Ora Object System rapkan desain tional [A Ora arsitektu nen utam struktur dalam s redo lo passwor 2 (dua) Area (SG Dan ke yang ter G Ora memory proses-p untuk m Sebuah kan han Rea diartikan rasi sing Dalam karena beberap perbeda proses b bahan, oleh in perbeda rnal PETIR Vol. 8 tingkat k i sebuah p pan konsep “ acle Datab contoh dari anagement acle lebih su Relational (ORDBMS) konsep pe object-orien Alapati 2005] acle 10g D ur yang terd ma, pertama yang berbe sistem oper og, archive rd. Kedua s area memo
GA) dan Pro
etiga masin
rdiri dari use
Gambar 1. Ars acle Instan System G proses back mengatur d instance da
nya untuk sat
al Applicati n sebagai p gle-instance konsepnya, RAC adala pa instanceO aan di dala background dan pengg nstance-insta aan kompon 8 No. 2 Septemb ketersediaan persyaratan “high availa ase 10g a teknologi R System (RD uka menyeb Database dikarenaka enggabunga nted dengan ]. Database Se
diri dari beb a struktur fi entuk file-file rasi seperti ed redo lo struktur mem ory, yaitu ogram Glob ng-masing s
er, server dan
sitektur Oracle nce terdiri Global Area kground ya database [ apat berjala tu database ion Cluster penambahan yang biasa , hal ini b ah sebuah k Oracle. Teta m manajem d tambahan gunaan reso ance terkait nen yang er 2015 n yang tin utama un ability system adalah sek Relational Da DBMS), wal butnya seba Managem an telah me an dari mo n model re erver mem berapa kom isik merupak e yang ada control, da og, parame mory terdiri d System Glo bal Area (PG struktur pro n backgroun e Instance dari struk a (SGA) d ang digunak Alapati 20 an dan digu e. (RAC) da n dari konfi [Vallath 200 benar adan komposisi d api ada bany men kompon n, file-file ta ource bersa t, belum l digunakan nggi ntuk m”. kian ata- lau-agai ment ene-odel ela-miliki mpo-kan a di ata, eter, dari obal GA). oses nd. ktur dan kan 05]. una-apat igu-03]. nya dari nyak nen, am-ama lagi di da ling sem ga tida file G da file log ma tan file sed sto ha arc ata pel arc sha 2. 2.1 (RA sya sya per me tas bu nod kom kas ber sei yan jug lam sistem gkungan ha Di dalam mua databa i instance. T ak di-shared e tersebut ma Gambar 2. Da Seperti y tabase files es, data files g files, passw asing-masing
npa di-share
e disimpan dangkan red orage. Khusu nya ditulis o chived redo au shared. T laksanaan chived redo ared storage Metodolo Analisis K Oracle 1 AC) dalam aratan utam aratan ini m rangkat ja edia penyimp Sebuah sinya memb ah kompute de dari RA mputer terse si yang ide rjalan di at imbang [Va ng dijadika ga harus m m operasi ardware yang m lingkung
ase files di-s
Tetapi ada f d, setiap ins asing-masin atabase files d RAC. yang terliha
yang di-sha
dan server word file da g instance ed. Passwor di node-n do log files us untuk arc
oleh satu ins
log files b Tetapi, untuk
operasi rec
log files seb
e. gi Penelitian Kebutuhan 10g Real A implementa ma yang ha meliputi aspe ringan, sis panan.. sistem RAC butuhkan pa r yang berti AC itu send ebut harus entik, agar tasnya dapa allath 2003]. an node-nod memenuhi p untuk me g ter-cluster gan RAC, shared anta file-file terte stance mem ng [Vallath 2 di dalam kon at pada ga ared adala parameter f an alert log f digunakan rd file dan nya masing disimpan d chived redo stance. Peny bisa di stora k kemudaha covery dan baiknya disi n Application asinya mem arus dipenu ek perangk stem opera C dalam im aling sedikit indak sebag diri. Dan k mempunya r sistem RA pat berjalan Komputer-k de RAC itu persyaratan endukung . hampir ar berba-ntu yang miliki file-2003]. figurasi ambar 2, h control file. Redo file untuk n sendiri alert log g-masing, di shared log files impanan age lokal an dalam backup, impan di Cluster miliki per-uhi. Per-at keras, asi, dan mplemen-t 2 (dua) gai node- komputer-i speskomputer-ifkomputer-i- spesifi-AC yang dengan komputer u sendiri minimal
sebagai dengan an 1 GB sebesar terakhir untuk in gantung Sist semua Oracle 1 sistem o nya. Beb oleh Or [Whalen Enterpris Enterpris kedua S versi ya versi yan Server 2 RAC me penyimp oleh selu Media storage storage Attached Network utama, disediak media voting di Jari gunakan yang dig luan imp kan 3 network untuk m kin terja penulis d Gam i berikut [W ukuran 512 B (atau dua 400 MB p ruang disk nstalasi per g pada tipe i tem RAC tid
sistem op 10g RAC re operasi saja berapa siste racle 10g n 2005] y se Linux 3 se Linux 4 a Suse Linux E ng lebih ba ng lebih ba 2000 atau ver embutuhkan panan data uruh node R penyimpan [Whalen 20 dapat meng d Storage (N k (SAN). D ada 3 (tiga kan denga penyimpan
isk dan data
ingan yang n protocol gunakan ad plementasi s (tiga) netw ini tidak t meminimalisk adi. Desain dapat diliha mbar 3. Desai Whalen 200 MB, Swap a kali ukura pada direk k hingga m rangkat luna instalasi. dak dapat di perasi. Khu elease 2, ha yang dapa em operasi y RAC relea yaitu pertam update 4 atau versi ya Enterprise S aru, ketiga S
aru, dan kee rsi yang leb sebuah mek yang dapat RAC secara b nan ini d 005]. Implem ggunakan k NAS) ataupu Dan sebaga a) partisi di an fungsi-fu nan untuk a base [Valla digunakan TCP/IP. Ke dalah kelas C sistem, penu work ID. M erhubung s kan ganggua jaringan ya at pada gam in Jaringan Im 05] yaitu R space beruk n RAM), rua ktori /tmp d mencapai 4 ak Oracle, iinstalasikan ususnya un anya bebera t menjalank yang diduku ase 2 ada ma Red H dan Red H ang lebih ba Server 9.0 a Solaris 10 a empat Windo ih baru. Sist kanisme me t dipergunak bersama-sam isebut sha mentasi sha konsep Netw un Storage A ai persyara sk yang ha ungsi seba file-file OC ath 2006]: penulis me las alamat C. Untuk kep ulis menggu Masing-mas satu sama l an yang mu ang digunak mbar 3 beriku mplementasi RAM kur-ang dan GB ter-n di ntuk apa kan-ung alah Hat Hat aru, atau atau ows tem edia kan ma. ared ared work Area atan arus agai CR, eng-t IP per- una-sing lain ung-kan ut. ba wo kan me ga me Ko RA me but kom den AM Ha da kom (Pr Ha Un yan Ca seb kom ter alt dig pen aka lun ope lisi me sis kom da nya pen bu da Ne pa me 9.0 ant gra ker me per imp kan 10. Sol me Jurnal P Pada gam hwa networ ork ID 143.46 n network I enggunakan mbar 3 jug enggunakan mputer 1 da AC, dan k enjadi shared Spesifikas t ialah perta mputer kom ngan spesif MD Athlon X arddisk : 15 G n kedua ko mputer raki rosesor : AM arddisk : 40 G ntuk mengh ng ada, pe ategory 5. buah switch mputer yang hubung ke c Dalam im ernatif piliha gunakan. U nulis harus an digunaka nak RAC be erasi yang is yang tela emilih Solar tem opera mputer nod n 2 dengan a adalah si ngoperasian ku manual ri situs peng Untuk keb twork File S da komput enggunakan 0 dan deng taranya ada atis, memb ras kompute emberikan k rangkat ke plementasi s n perangka 2.0.2 dan O laris x86. erupakan rel PETIR Vol. 8 No. mbar 3 di rk pertama 6.x.x, networ ID 10.x.x.x n network ID a dapat dil n 3 (tiga) an 2 merupa omputer 3 d storage. si dari komp ama kompu mputer rak ikasi masing XP 1500+, GB dan kart omputer 3 itan yang m D Duron 100 GB dan Kart hubungkan nulis mengg Penulis ju h 8 port, s g ada di netw client. mplementasi an perangka Untuk keb memilih s an, karena p ergantung pa mendukung ah dilakuka ris 10 upd asi yang de-node RAC n dasar pert stem operas nnya relatif sangat leng gembangnya butuhan sha System (NF ter 3, penu n sistem ope gan dasar alah sistem butuhkan r er yang rel ompatibilita eras yang sistem RAC, at lunak O Oracle Data Kedua pe lease2 dari O . 2 September 20 i atas jelas mengguna rk kedua me dan networ D 192.168.10 lihat bahwa ) buah k akan node-n digunaka puter-kompu uter 1 dan 2 kitan yang g-masing (P Memory : tu jaringan : merupakan memiliki sp 00, Memory tu jaringan : komputer-k gunakan ka uga meng sehingga k twork pertam sistem RAC at lunak yan butuhan m sistem opera pemilihan p ada platform gnya. Deng an, akhirnya date 11/06 digunakan C yaitu kom timbangan d si ini bersifa f lebih mud gkap dapat a (www.sun.c ared storage FS) yang di ulis memili erasi Red H r pertimban m operasi ini resource p latif lebih k as yang baik digunakan , penulis me Oracle Clu abase 10.2.0 erangkat lu Oracle 10g. 015 | 135 s terlihat akan net- engguna-rk ketiga .x. Pada a penulis komputer. node dari n untuk uter terse-2 adalah identik Prosesor : 768 MB, 3 buah). n sebuah pesifikasi: : 512 MB, 2 buah). komputer abel UTP gunakan komputer-ma dapat C, banyak ng dapat mendasar, asi yang erangkat m sistem gan ana-a penulis sebagai n untuk mputer 1 diantara-at grdiantara-atis, dah dan diunduh com). e dengan gunakan ih untuk Hat Linux ngan di-i bersdi-ifat erangkat kecil dan k dengan n. Untuk engguna-usterware 0.2 untuk unak ini
136 | Jurnal PETIR Vol. 8 No. 2 September 2015
Setiap komputer yang menjadi node RAC
harus mendaftarkan alias-alias (nama host)
seluruh anggota node. Alias-alias tersebut
terbagi menjadi 3 (tiga), yaitu:
1. Alias untuk koneksi jaringan public.
2. Alias untuk koneksi jaringan private
interkoneksi.
3. Alias untuk Virtual IP (VIP).
4. Alias untuk shared storage.
Penulis mengkonfigurasikan alias-alias
tersebut dengan menambahkan entry-entry di
dalam file ipnodes dan hosts pada yang ada
pada direktori /etc/inet. File ipnodes dan hosts
dibuat identik, yang isinya yaitu:
1. Komputer 1: 127.0.0.1 localhost 143.46.43.100 rac1 loghost 10.0.0.1 rac1-priv 143.46.43.104 rac1-vip 192.168.10.100 rac1-data 143.46.43.101 rac2 10.0.0.2 rac2-priv 143.46.43.105 rac2-vip 192.168.10.150 storage 2. Komputer 2: 127.0.0.1 localhost 143.46.43.101 rac2 loghost 10.0.0.2 rac2-priv 143.46.43.105 rac2-vip 192.168.10.200 rac2-data 143.46.43.100 rac1 10.0.0.1 rac1-priv 143.46.43.104 rac1-vip 192.168.10.151 storage 2.2. Parameter Kinerja
Pengujian kinerja suatu sistem RAC melibatkan beberapa langkah terpisah yang menghasilkan suatu hasil akhir. Hasil akhir pengujian tersebut dapat berupa informasi ataupun rekomendasi bagaimana parameter-parameter hasil akhir seharusnya bernilai. Langkah-langkah pengujian kinerja yang dilakukan penulis terbagi menjadi penetapan parameter uji, pengujian dan pemonitoran parameter uji serta terakhir analisa hasil pengujian
Penetapan parameter-parameter dalam pengujian kinerja suatu sistem sangatlah penting, karena parameter-parameter tersebut akan menjadi dasar dalam melakukan analisa kinerja. Penetapan parameter
peng-ujian kinerja mempunyai istilah “Performance
Metric” [Whalen 2005]. Metric dalam hal ini
adalah nilai-nilai yang dapat diukur sebagai takaran bagaimana baik dan buruknya kinerja suatu sistem. Ada dua macam metrik yang digunakan dalam penelitiaan ini yaitu sistem operasi dan database. Sistem operasi terdiri dari utilisasi CPU dan memori sementara database terdiri atas penggunaan
SGA, buffer cache dan share pool.
Keseluruh-an parameter ini telah penulis tuKeseluruh-angkKeseluruh-an dalam tulisan sebelumnya (PETIR edisi maret 2015).
Dalam tulisan kali ini penulis akan mencoba mengamati pengaruh parameter
data base yang lain yaitu redo log buffer,
instance efficiency percentages, aktifitas
library cache dan buffer pool. Dalam
melaku-kan pengujian kinerja RAC, penulis memper-timbangkan hal-hal apa saja yang dapat mempengaruhi metric-metric yang telah ditetapkan sebagai parameter uji. Berdasar-kan teori yang telah dibahas sebelumnya, metric-metric yang telah ditetapkan, secara keseluruhan sangat dipengaruhi oleh
perin-tah-perintah SQL (seperti “select”, “insert”,
“update”, dan “commit”) dan banyaknya
jumlah data. Maka untuk keperluan pengujian dan analisa penulis melakukan pengujian dengan membandingkan hasil uji sistem pada
saat idle dan pada saat diberikan beban kerja
berupa pelaksanaan perintah-perintah SQL
yang mempengaruhi metric-metric yang telah
ditetapkan..
Penulis menggunakan tool-tool dari
sis-tem operasi dan Oracle untuk mendapatkan
data-data metric hasil pengujian. Tool sistem
operasi yang digunakan oleh penulis yaitu
vmstat. Tool tersebut digunakan untuk
mem-buat statistik dari penggunaan cpu dan
memory oleh RAC. Untuk mendapatkan
data-data metricdatabase hasil pengujian, penulis
meng-generateAutomatic Workload Repository
(AWR) dari masing-masing instance yaitu rac1
dan rac2.
Analisa terhadap shared pool merupakan
prioritas utama karena apabila shared pool
mengalami load ulang ke dalam memory
terhadap perintah yang pernah dieksekusi
(cache miss), dampak terhadap performa
keseluruhan akan lebih terasa bila
dibanding-kan dengan cache miss yang dialami oleh
buffer cache.
Dalam pelaksanaan analisa terhadap
shared pool, penulis berkonsentrasi pada
library cache, karena secara algoritma data
berumur dengan apabila mendap cache m maka ra cache p shared p dedikasi terbatas menyeba lebih be Ora library c dengan dilihat p Unt cache, p terlihat s Ora yang ba bernilai Ras buffer di r lebih pe data dict tuning terh patkan rasio miss) yang asio cache pasti terpen pool terlalu ikan sumbe snya space abkan pen sar. acle membe cache (librar nilai di at pada AWR se tuk penguku penulis juga sebagai beri acle juga m
agus dari buf
di atas 90% sio yang d i dalam AWR endek bila tionary cac hadap librar o cache hit ( bagus sud hit dari d uhi juga. A u kecil, serv er daya yan yang ters ngkonsumsia erikan syara ry hit) yang tas 90%. R eperti beriku uran efisien a mengguna ikut: memberikan ffer cache (b %. igunakan u R adalah: dibandingk che. Sehing ry cache un (kebalikan d dah terpenu data diction Apabila uku ver harus m ng ada kare sedia. Hal an CPU ya at rasio un bagus ada asio ini da ut: nsi dari bu kan AWR ya n syarat ra buffer hit) ha untuk redo kan gga ntuk dari uhi, nary uran men-ena ini ang ntuk alah apat uffer ang asio arus log ole me 90% 2.3 seb da me kin me RA pen Sk bek saa yan pen diim 1. 2. Jurnal P Untuk red eh paramet emberikan s %. 3 Metode P Seperti belumnya, a pat berupa etric yang
nerja itu send embandingk AC bekerja nulis memb enario perta kerja, dan s at RAC da ng penulis ngujian kine mplementas Membuat nama “in Kolom p dengan ti 10 karakt “dua” de berjumlah Menyiapk “insert”, “ yang tel tersebut d ber-extens di sebuah tersebut a a. File in “inser “comm yang kali. b. File up “upda “comm yang (serib PETIR Vol. 8 No. do log buffe er Redo No syarat harus engujian yang t analisis kine pengukura diujikan. diri bisa dila kan nilai-nila dan pada buat dua s ama dilakuk skenario ked alam keada lakukan erja dari sist sikan ialah:
sebuah tab ndra” dan m pertama di
ipe data num ter. Kolom engan tipe h 10 karakter kan perint update” dan lah dibuat dibuat ke d sion .sql ya h komputer c adalah: nsert.sql, ber rt into indra v mit;” diulang seb pdate.sql, be ate indra set
mit;”
juga diula u) kali.
. 2 September 20
fer yang diw
NoWait, Ora s bernilai le telah dis erja yang d an terhadap Metode p akukan deng ai metric pa saat idle. U skenario pe kan pada s dua dilakuk aan idle. P dalam me stem RAC ya bel. Tabel i memiliki dua iberi nama mber dan b kedua dibe data varch r. tah opera n “select” pa t. Perintah dalam 4 (em ang akan di client. Isi da risikan perin values(1,'1'); banyak 1000 erisikan per t satu=2;” ang sebany 015 | 137 wakilkan acle juga ebih dari sebutkan dilakukan p metric-pengujian gan cara ada saat Untuk itu engujian. saat RAC kan pada Persiapan elakukan ang telah ini diberi a kolom. a “satu” berjumlah eri nama har2 dan si SQL ada tabel -perintah mpat) file ijalankan ari file-file ntah: ;” 0 (seribu) rintah: yak 1000
138 | Jurnal PETIR Vol. 8 No. 2 September 2015
c. File select.sql, berisikan perintah:
“select * from indra;”
yang juga diulang sebanyak 1000 (seribu) kali.
d. File kombinasi.sql, berisikan
perintah:
“insert into indra values(1,'1');” “commit;”
“update indra set satu=2;” “commit;”
“select * from indra;” “commit;”
yang juga diulang sebanyak 1000 (seribu) kali.
3. Membuat koneksi menggunakan
kom-puter client dengan konfigurasi
TNS-Names: SRVINDRA1 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = 143.46.43.100) (PORT = 1521) ) (ADDRESS = (PROTOCOL = TCP) (HOST = 143.46.43.101) (PORT = 1521) ) (LOAD_BALANCE = yes) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = srvindra1) ) )
Lalu untuk membedakan antara sistem pada saat dilakukan operasi SQL dan pada
saat idle, penulis melakukan penjadwalan
pengujian. Penjadwalan yang dilakukan ialah satu jam pertama untuk pengujian sistem dengan menjalankan perintah SQL yang telah dibuat dan satu jam kedua untuk pengujian
sistem yang berada dalam keadaan idle.
Untuk melakukan pengukuran metric
database, penulis menggunakan Automatic
Workload Repository (AWR) yang diambil dari
masing-masing instance dari node-node yang
ada di dalam RAC.
2.4. Hasil Pengujian 2.4.1 Skenario Pertama
1. Persentasi efisiensi instance
Persentasi efisiensi antara kedua
instance dapat dilihat pada AWR berikut:
rac1 :
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: 100.00 Buffer Hit %: 99.85 Library Hit %: 89.77 Execute to Parse %: -0.36 Parse CPU to Parse Elapsd %: 38.76 Redo NoWait %: 100.00 In-memory Sort %: 100.00 Soft Parse %: 93.62 Latch Hit %: 100.00 % Non-Parse CPU: 92.01
Shared Pool Statistics Begin End Memory Usage %: % SQL with executions>1: % Memory for SQL w/exec>1: 78.06 53.33 90.18 81.27 76.97 92.47 rac2 :
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: 99.99 Buffer Hit %: 99.97 Library Hit %: 92.92 Execute to Parse %: 6.63 Parse CPU to Parse Elapsd %: 36.58 Redo NoWait %: 100.00 In-memory Sort %: 100.00 Soft Parse %: 97.02 Latch Hit %: 100.00 % Non-Parse CPU: 96.01
Shared Pool Statistics Begin End Memory Usage %: % SQL with executions>1: % Memory for SQL w/exec>1: 83.36 50.17 87.91 85.94 79.63 86.70
2. Aktifitas Librari Cache
Statistik aktivitas Library Cache RAC dan
non-RAC dapat dilihat pada AWR berikut:
rac1 :
Library Cache Activity DB/Inst: INDRA/indra1 Snaps: 2-3
-> "Pct Misses" should be very low Namespace Get Requests Pct Miss Pin Requests Pct Miss
Re-loads Invali- dations BODY CLUSTER INDEX SQL AREA TABLE/ PROCEDURE TRIGGER 23 44 21 447 1,070 8 30.4 0.0 57.1 64.9 25.4 50.0 103 85 21 19,229 4,840 8 13.6 2.4 100. 0 7.0 22.9 50.0 6 2 9 717 261 0 0 0 0 2 0 0
Library Cache Activity (RAC) DB/Inst: INDRA/indra1 Snaps: 2-3
Namespace GES Lock Requests GES Pin Requests GES Pin Releases GES Inval Requests GES Invali- Dations CLUSTER INDEX TABLE/ PROCEDURE 85 21 2,917 0 12 277 0 0 0 0 12 129 0 0 0
Jurnal PETIR Vol. 8 No. 2 September 2015 | 139 rac2 :
Library Cache Activity DB/Inst: INDRA/indra2 Snaps: 2-3
-> "Pct Misses" should be very low Namespace Get
Requests Pct Miss Pin Requests Pct Miss Reloads Invali- dations BODY CLUSTER INDEX SQL AREA TABLE/ PROCEDURE TRIGGER 529 21 21 690 1,083 18 0.8 0.0 57.1 61.9 24.7 38.9 639 73 24 18,956 3,619 105 1.9 1.4 87.5 3.7 25.1 8.6 8 1 9 228 267 2 0 0 0 0 0 0
Library Cache Activity (RAC) DB/Inst: INDRA/indra2 Snaps: 2-3
Namespace GES Lock
Requests GES Pin Requests GES Pin Releases GES Inval Requests GES Invali- dations CLUSTER INDEX TABLE/ PROCEDURE 73 24 1,512 0 12 177 0 0 0 0 12 84 0 0 0 3. Buffer Pool
Statistik Buffer Pool yang didapat oleh
penulis bisa dilihat pada AWR berikut:
rac1 :
Buffer Pool Statistics DB/Inst: INDRA/indra1 Snaps: 2-3
-> Standard block size Pools D: default, K: keep, R: recycle -> Default Pools for other block sizes: 2k, 4k, 8k, 16k, 32k
P Number of Buffers
Pool
Hit% Buffer Gets Physical Reads Physical Writes Free Buff Wait Writ Comp Wait Busy Waits D 13,664 100 508,710 872 2,362 0 0 0 rac2 :
Buffer Pool Statistics DB/Inst: INDRA/indra2 Snaps: 2-3 -> Standard block size Pools D: default, K: keep, R: recycle
-> Default Pools for other block sizes: 2k, 4k, 8k, 16k, 32k
P Number of Buffers Pool Hit% Buffer Gets Physical Reads Physical Writes Free Buff Wait Writ Comp Wait Busy Waits D 13,664 100 1,550,288 409 16,632 0 0 177 2.4.2 Skenario Kedua
1. Persentasi efisiensi instance
Persentasi efisiensi antara kedua
instance dapat dilihat pada AWR berikut:
rac1 :
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: 99.00 Buffer Hit %: 99.60 Library Hit %: 88.64 Execute to Parse %: 53.67 Parse CPU to Parse Elapsd %: 36.58 Redo NoWait %: 100.00 In-memory Sort %: 100.00 Soft Parse %: 87.36 Latch Hit %: 100.00 % Non-Parse CPU: 22.78
Shared Pool Statistics Begin End Memory Usage %:
% SQL with executions>1: % Memory for SQL w/exec>1:
81.27 76.97 92.47 84.11 81.22 94.25 rac2 :
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: 100.99 Buffer Hit %: 99.71 Library Hit %: 89.30 Execute to Parse %: 50.85 Parse CPU to Parse Elapsd %: 55.17
Redo NoWait %: 100.00 In-memory Sort %: 100.00 Soft Parse %: 86.64 Latch Hit %: 100.00 % Non-Parse CPU: 17.72 Shared Pool Statistics Begin End Memory Usage %:
% SQL with executions>1: % Memory for SQL w/exec>1:
85.94 79.63 86.70 88.74 74.55 92.57
2. Aktifitas Librari Cache
Statistik aktivitas Library Cache RAC dan
non-RAC dapat dilihat pada AWR berikut:
rac1 :
Library Cache Activity DB/Inst: INDRA/indra1 Snaps: 3-4
-> "Pct Misses" should be very low Namespace Get Reque
sts Pct
Miss Pin Requests Pct Miss Reloads Invali- dations BODY CLUSTER INDEX SQL AREA TABLE/ PROCEDURE 23 44 21 447 1,070 30.4 0.0 57.1 64.9 25.4 103 85 21 19,229 4,840 13.6 2.4 100.0 7.0 22.9 5 2 25 339 367 0 0 0 2 0
Library Cache Activity (RAC) DB/Inst: INDRA/indra1 Snaps: 3-4
Namespace GES Lock Reque sts GES Pin Reque sts GES Pin
Releases GES Inval Requests GES Invali- Dations CLUSTER INDEX TABLE/ PROCEDURE 37 78 2,092 0 12 39 0 0 0 0 0 32 0 0 0 rac2 :
Library Cache Activity DB/Inst: INDRA/indra2 Snaps: 3-4
-> "Pct Misses" should be very low Namespace Get
Requests Pct Miss Pin Requests Pct Miss Reloads Invali- Dations BODY CLUSTER INDEX SQL AREA TABLE/ PROCEDURE TRIGGER 604 38 46 1,239 1,268 12 0.5 0.0 0.0 5.7 2.3 0.0 726 90 129 13,549 5,463 111 3.0 2.2 22.5 7.3 20.2 1.8 19 2 29 485 482 2 0 0 0 0 0 0
Library Cache Activity (RAC) DB/Inst: INDRA/indra2 Snaps: 3-4 Namespace GES Lock
Requests GES Pin Requests GES Pin Releases GES Inval Requests GES Invali- dations CLUSTER INDEX TABLE/ PROCEDURE 90 129 2,318 0 0 55 0 0 0 0 0 44 0 0 0 3. Buffer Pool
Statistik Buffer Pool yang didapat oleh
140 | Jurnal PETIR Vol. 8 No. 2 September 2015 rac1 :
Buffer Pool Statistics DB/Inst: INDRA/indra1 Snaps: 3-4 -> Standard block size Pools D: default, K: keep, R: recycle -> Default Pools for other block sizes: 2k, 4k, 8k, 16k, 32k
P Number of Buffers
Pool
Hit% Buffer Gets Physical Reads Physical Writes Free Buff Wait Writ Comp Wait Busy Waits D 13,664 100 61,223 240 525 0 0 5 rac2 :
Buffer Pool Statistics DB/Inst: INDRA/indra2 Snaps: 3-4
-> Standard block size Pools D: default, K: keep, R: recycle -> Default Pools for other block sizes: 2k, 4k, 8k, 16k, 32k
P Number of Buffers
Pool
Hit% Buffer Gets Physical Reads Physical Writes Free Buff Wait Writ Comp Wait Busy Waits D 14,148 100 134,917 413 693 0 0 2
2.5 Analisa Hasil Pengujian
Dapat dilihat dari statistik di atas bahwa
efisiensi instanse yang ditunjukan oleh buffer
hit dan library hit lebih banyak dialami oleh
rac2 ( walaupun hanya beda sekitar 3% ). Dan bila dibandingkan antara hasil pengujian pada satu jam pertama dan pengujian satu jam kedua, efisiensi instan antara kedua
instan tanpa mengalami perubahan nilai
yang signifikan.
Data statistik penggunaan Library Cache
yang ada pada AWR menunjukan bahwa
cache miss lebih banyak dialami oleh rac1.
Hal ini menandakan bahwa perintah-perintah SQL lebih banyak dijalankan di rac1. Pada
saat pengujian kedua cache miss tetap masih
banyak dialami oleh rac1.
Sementara data Buffer Pool Hit
menun-jukkan bahwa kedua instance mempunyai
kinerja yang bagus. Hal ini ditandai dengan
nilai rasio 100 % di kedua instance. Keadaan
ini terus berlangsung sampai pengujian kedua.
Dari hasil analisa yang telah disebutkan, penulis menyimpulkan bahwa sistem RAC yang diuji memang sangat handal dalam
menerapkan konsep “high-availability
sys-tem”. Walaupun di dunia nyata, setelah
imple-mentasi selesai dan sebelum database
digu-nakan, sebaiknya dilakukan tuning terhadap
sistem dengan menggunakan metode analisa
kinerja yang telah dilaksanakan di dalam penelitian ini.
3. Kesimpulan
1. Pengimplementasian RAC sangat
membutuhkan ketelitian dan perencana-an yperencana-ang matperencana-ang, karena sperencana-angat beresiko terhadap hilangnya data.
2. Hasil pengujian persentase instant yaitu
buffer hit untuk node pertama 99,8% dan
node kedua 99,97%. CPU idle minimum
sebesar 99,6% untuk node pertama dan
99,71% untuk node kedua.
3. Hasil pengujian free memory maksimum
untuk node pertama sebesar 267884 KB
dan node kedua sebesar 281346 KB. Free
memory minimum sebesar 201842 KB dan
node kedua sebesar 211624 KB.
4. Hasil pengujian SGA menunjukkan nilai
205520896 di kedua node.
5. Nilai pengujian buffer cache minimum
untuk node pertama sebesar 108 MB dan
node kedua sebesar 112 MB. Untuk
peng-ujian buffer cache maksimum sebesar
112 MB untuk node pertama dan 116 MB
untuk node kedua.
6. Pengujian shared pool menunjukkan nilai
maksimum 76 MB dan 72 MB untuk node
kedua. Nilai minimum untuk node
pertama sebesar 72 MB dan 68 MB untuk
node kedua.
7. Sistem RAC yang diuji memang sangat
handal dalam menerapkan konsep “
high-availability system”.
DAFTAR PUSTAKA
Alapati, Sam R. 2005. Expert Oracle Database
10g Administration. Apress.
Powell, Gavin. 2007. Oracle performance
Tuning for 10g R2. Second Editon. Digital
Press.
Vallath, Murali. 2003. Real Aplication Clusters.
Digital Press.
Vallath, Murali. 2006. Oracle 10g RAC Grid,
Service & Clustering. Digital Press.
Whalen, Edward. 2005. Oracle Database 10g
