Pak Tomi, Yang dimaksud dengan Application Partitioning itu bagaimana? ada URL yang bisa saya baca, terus untu aplikasi, aplikasi tsb bisa berjalan dengan sangat cepat di non-rac (konfigurasi HW sama dengan HW RAC) dan saya sudah test. dan itu berjalan tanpa hambatan sama sekali
-- Tks & Best regards, Andi EP IT Engineer mailto:[EMAIL PROTECTED] Tuesday, March 13, 2007, 5:53:58 PM, you wrote: > 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 >
