salah satu cara, ya pakai application partitioning. biasanya long query digunakan utk report. so jika anda punya 3 nodes, yg dua pakai untuk transaksi harian (OLTP) dan jadikan node 3 sebagai node backup failover. dan untuk report dedikasikan di node 3 aja, tapi dengan catatan failover ke salah satu node diatas.
kalau bisa sih, upload top consumer dan most top wait event nya apa. karena ada spesifik wait event utk GCS & GES. regards ujang On 3/13/07, 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?
