mencermati "execute to parse", dimana kalkulasinya diambil dari perbandingan parses/executions, parses disini adalah soft parse maupun hard parse:
100*(1-(1,076.18/2,074.36)) = 48.12 dari situ diperkiraan terjadi "tidak efisien" pada shared pool, apatah karena: - tidak menggunakan bind variable, namun ini hanya sedikit impact, buktinya angka hard parse tidak begitu tinggi. - parameter session_cached_cursor kurang memadai. sehingga terlalu banyak soft parses. - namun demikian jika melihat top 5 wait event, silahkan cek di metalink, dulu di 10.2.0.3 pernah menemukan bugs yg berelasi dgn "cursor: pin S wait on X". so, apply patch dulu baru cek lagi apakah shared pool masih bermasalah ataukah ndak.... -- thanks and regards ujang | oracle dba | mysql dba http://ora62.wordpress.com On Tue, Mar 10, 2009 at 2:49 PM, Andes Febrian <[email protected]> wrote: > Halo pak ujang, maaf baru bisa bales, berikut saya paste awr report nya, > mohon di liat2, Thanks. btw, mau tanya jg, klo istilah2 yg ada di top 5 > event, apa siy artinya ? Many thanks. > > DB NameDB IdInstanceInst numReleaseRACHost ITTDB1135347846ITTDB110.2.0.3.0NO > ITTDB > > > Snap IdSnap TimeSessionsCursors/Session Begin Snap:1874310-Mar-09 09:00:05 > 258 19.8 End Snap:1874410-Mar-09 10:00:11516 14.7 Elapsed: 60.10 (mins) DB > Time: 647.52 (mins) > > Report Summary > > Cache Sizes > > > BeginEnd > > Buffer Cache: 2,860M 2,860MStd Block Size: 8K Shared Pool Size: > 5,252M5,252MLog > Buffer: 6,104K > > Load Profile > > > Per SecondPer Transaction Redo size: 143,421.18 3,968.22 Logical > reads:160,750.904,447.70 Block > changes: 405.14 11.21 Physical reads: 208.17 5.76 Physical writes: > 154.924.29 User > calls: 1,688.73 46.72 Parses: 1,076.18 29.78 Hard parses: 3.17 0.09 > Sorts:34.440.95 > Logons: 13.23 0.37 Executes: 2,074.36 57.39 Transactions: 36.14 > > % Blocks changed per Read: 0.25Recursive Call %: 55.94 Rollback per > transaction %: 41.85Rows per Sort: 914.74 > > Instance Efficiency Percentages (Target 100%) > > Buffer Nowait %: 100.00Redo NoWait %: 100.00 Buffer Hit %: 99.91In-memory > Sort %: 99.99 Library Hit %: 99.92Soft Parse %: 99.71 Execute to Parse > %:48.12Latch > Hit %: 98.86 Parse CPU to Parse Elapsd %: 10.59% Non-Parse CPU: 96.62 > > Shared Pool Statistics > > > BeginEnd Memory Usage %: 74.11 78.28 % SQL with executions>1: 85.29 81.36 % > Memory for SQL w/exec>1: 98.95 98.60 > > Top 5 Timed Events > > EventWaitsTime(s)Avg Wait(ms)% Total Call TimeWait Class CPU time 16,394 > 42.2 > cursor: pin S wait on X 634,165 6,950 11 17.9Concurrency PX Deq Credit: > send blkd 230,874 6,862 30 17.7Other enq: TX - row lock contention 621 > 1,6882,7184.3 > Application PX qref latch 430,860 1,664 4 4.3Other > > > On Thu, Mar 5, 2009 at 4:37 PM, Ujang Jaenudin > <[email protected]>wrote: > >> bisa dipaste disini awr report sampe bagian top 5 wait event...? >> >> atau bisa cari statistik session cursor cache count, session cursor >> cache hits, cursor cache hits, parse count (total). >> >> kalau ini cara extrim, musti hati2 di environment >> production...analisanya pun butuh waktu :) >> >> alter session set events '10270 trace name context forever, level 10'; >>
