Instance Efficiency Percentages (Target 100%) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ Buffer NOWAIT%: 99.82 Redo NOWAIT%: 100.00 Buffer Hit%: 97.18 in-Memory Sort%: 99.90 Library Hit%: 99.89 Soft Parse%: 99.84 Execute to Parse%: 12.11 Latch Hit%: 99.54 Parse CPU To Parse ELAPSD%: 57.50% Non-Parse CPU: 95.41 Shared Pool Statistics Begin end ------ ------ Memory USAGE: 59.91 60.20% SQL with Executions> 1: 91.78 91.34% Memory for SQL W / EXEC > 1: 99.62 99.62
Execute to Parse = Round (100 * (1-: PRSE /: EXE), 2) PRSE = SELECT VALUE from V $ sysstat where name = 'Parse Count (Total)'; EXE = SELECT VALUE FROM V $ sysstat where name = 'Execute Count';
Quote:
WANGHAI WROTE:
Quote:
Biti_Rainy Wrote: This value is not necessarily contact with BIND VAR. It is recommended that you do it.
If you have not binding, it is also a reason that you can't reuse. If the memory is enough, you can try it, but the root calender still needs bind :)
Even Soft Parse will be statistically subjected to Parse Count, this indicator does not react out several parses for several resolutions of Fast Soft (new Pool in Shared Pool) / Hard (new Pool in Shared Pool). Only use variables in such programs in a similar loop in PL / SQL to avoid a lot of PARSE, this indicator is not necessarily contacted by using bind, add session_cached_cursors to save resources to Fast Soft in a large number of Parse, saving resources
Original reference
http://www.cnoug.org/viewthread.php?tid=1796
