Atau dengan ADDM akan lebih complit lagi termasuk saran tuning yang di rekomendasikan.
regards, sambi On 3/14/07, Tomi Wijanto <[EMAIL PROTECTED]> wrote: > > Dari EM bisa. > Kalau gak salah ada di tab 'performance', lalu pilih > link 'Snapshots'. > > Kalau mau manual dari sqlplus, tinggal jalankan script > awrrpt.sql di $ORACLE_HOME/rdbms/admin. > > > regards, > tomi > > --- Andi EP <[EMAIL PROTECTED] <milis%40ogs-id.com>> wrote: > > > Pak Tomi, > > > > untuk pemakain AWR ini cukup dari EM nya atau ada > > sql script yang > > harus saya eksekusi? > > Thx atas bantuan nya. > > > > > > -- > > Tks & Best regards, > > Andi EP > > IT Engineer > > mailto:[EMAIL PROTECTED] <milis%40ogs-id.com> > > > > > > > > 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] <milis%40ogs-id.com>> 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] <milis%40ogs-id.com> > > >> > > >> > > > > > > > > __________________________________________________________ > > > Sucker-punch spam with award-winning protection. > > > Try the free Yahoo! Mail Beta. > > > > > > http://advision.webevents.yahoo.com/mailbeta/features_spam.html > > > > > > > > > > > > > > > > > > > ------------------------ Yahoo! Groups Sponsor > > > > > > -- > > -----------I.N.D.O - O.R.A.C.L.E--------------- > > Keluar: [EMAIL PROTECTED]<indo-oracle-unsubscribe%40yahoogroups.com> > > Website: http://indo-oracle.blogspot.com > > Mirror: http://indooracle.wordpress.com > > ----------------------------------------------- > > > > Bergabung dengan Indonesia Thin Client User Groups, > > Terminal Server, Citrix, New Moon Caneveral, di: > > http://indo-thin.blogspot.com > > Yahoo! Groups Links > > > > > > > > > > > > __________________________________________________________ > Sucker-punch spam with award-winning protection. > Try the free Yahoo! Mail Beta. > http://advision.webevents.yahoo.com/mailbeta/features_spam.html > > > [Non-text portions of this message have been removed]
