Walaupun RAC memiliki overhead di level cache-fusion, tapi tidak berarti masalah database Anda karena overhead tsb (kecuali kalau bisa dibuktikan bahwa database Anda berjalan dengan normal pada database non-RAC).
Dari pengalaman, masalah utama seringkali terletak di SQL. Artinya, tuning sql akan membawa dampak perbaikan terbesar. Full table scans yg tidak semestinya dan index yg tidak selektif adalah musuh besar bagi RAC. Kalau Anda suspect problem utama di interconnect, coba cek wait event yg namanya didahului 'global cache' di report statspack (kalau 9i) atau AWR (10g), apakah wait event tsb berada di dalam 'top 5'?. Di 10g AWR, report yg berhubungan dengan RAC lebih lengkap. Misalnya utk mengetahui berapa persen data yg diakses dari remote-node, cek di bagian 'Global Cache Efficiency Percentages', bandingkan besarnya nilai 'remote cache' dibandingkan 'local cache'. Apabila aktifitas cache-fusion sangat tinggi, dan network interconnect sudah mencukupi, terkadang performance bisa ditingkatkan dengan melakukan 'application partitioning'. Intinya adalah, setiap user/session/module aplikasi yg mengakses subset data yang sama, selalu terhubung ke instance yg sama. Dgn demikian diharapkan jumlah block yg perlu dikirim antar instance menjadi berkurang. Overhead cache-fusion adalah konsekuensi dari pemakaian RAC. Apabila secara hardware sudah bagus (bandwidth minimal 1Gbps, latency kecil), biasanya overheadnya juga sangat kecil. Seringkali RAC dikambinghitamkan padahal belum tentu aplikasi ybs juga berjalan dengan baik di non-rac. regards, tomi --- Andi EP <[EMAIL PROTECTED]> wrote: > Pak Tomi, > > salah cara yang paling efektif untuk mengatasi > overhead Oracle RAC > pake apa? soal nya kalau saya baca article2 di > internet bunyi nya spt > dibawah ini > "The most important aspects of RAC tuning are the > monitoring and tuning of the > global services directory processes. The processes > in the Global Service Daemon > (GSD) communicate through the cluster interconnects. > If the cluster interconnects > do not perform properly, the entire RAC structure > will suffer no matter how well > everything else is tuned. The major processes of > concern are the Global Enqueue > Services (GES) and Global Cache Services (GCS) > processes. > > kesimpulan saya sementara adalah membenahi > interconnect di level OS > (saya pakai Linux RHEL 4.3 X86_64) dan kemudian > menambahkan nilai > berikut di /etc/sysctl.conf > > net.core.tcp_rmem=108544 > net.core.rmem_max=108544 > net.ipv4.tcp_rmem=4096 87380 4194304 > net.ipv4.tcp_wmem=4096 16384 4194304 > > tapi ini juga masih belum menolong untuk transfer > rate di cache > fusion, sehinga ketika ada aplikasi yang query nya > besar dan komplek > aplikasi berjalan dengan sangat lambat. > any idea? > > -- > Tks & Best regards, > Andi EP > IT Engineer > mailto:[EMAIL PROTECTED] > > ____________________________________________________________________________________ Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html
