Execute to Parse % in AWR

dear all
I'm getting Execute to Parse % : -18.02 in my AWR report (with minus)
Is it a bad thing and why it is below 0 ?
thanks
john

user8779435 wrote:
dear all
I'm getting Execute to Parse % : -18.02 in my AWR report (with minus)
Is it a bad thing and why it is below 0 ?
As a general rule, ratios are a waste of space - they can't give you any quantitative information unless you are prepared to examine the underlying statistics.
The best you can say is that a negative ratio (in an AWR) report is unexpected - you could argue that a negative ratio is either "bad" or the result of a reporting bug, but "bad" and "worth worrying about" aren't necessarily the same thing.
This value is simply pointing out that the number of parse calls that are being counted is roughly 18% than the number of execute calls, and normally you might expect to do at least one execution of every statement you parse.
Check the "Instance Activity" for 'parse count' and 'execute count' to get a better idea of how much activity you are looking at.
Check "SQL ordered by parse count" to see if you can find statements which (for example) are parse twice for each execute, and if these statements come close to accounting for the difference you see in the numbers in the "instance activity". (There used to be some front-end environment that managed to send two parse calls per execute - but I can't remember the details off-hand, though I recall it was a simple configuration change to fix it.)
There are other parts of the report that will tell you whether the extrac parse calls are worth pursuing at present: e.g. the "time model" statistics allow you to compare time spent in parsing with total DB time; the "instance activity" statistics show you the CPU time spent parsing - one of the numbers used to generate the ratio "% Non-Parse CPU:"
Regards
Jonathan Lewis

Similar Messages

Low Execute to Parse % and high soft parse %

Hello Folks
I am working on oracle 10g release2 on HP-UX
After going through awr reports observed it have low Execute to Parse % but high soft parse % (Instance Efficiency Percentages)
so cannot say issue with less use of bind variables,then what is cause of Execute to Parse %
searched sites like ask.tom,burselon counsulting etc as usual they had given generic/diplomatic(escaping) replies on this
like due to problem in application code,ineffecient sharing ,due to problem in database parameters etc
without any clear indication for cause and solution like if some database parameters not set properly then should say which database parameters can be checked,cause due to more parsing and less execution
please share if you had faced such issue and any suggestions to solve this
examples why this could happen ,like possibilities in application code
Thanks

Load Profile
                                          Per Second       Per Transaction
               Redo size:             11,685.79              3,660.98
               Logical reads:             71,445.74             22,382.86
               Block changes:                 70.89                 22.21
               Physical reads:                 58.63                 18.37
               Physical writes:                  2.80                  0.88
               User calls:                652.93                204.55
               Parses:                 48.39                 15.16
               Hard parses:                  0.33                  0.10
               Sorts:                  6.90                  2.16
               Logons:                  0.23                  0.07
               Executes:                 52.71                 16.51
               Transactions:                  3.19
            % Blocks changed per Read:    0.10    Recursive Call %:    30.48
            Rollback per transaction %:    2.57       Rows per Sort:    29.66
    Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
             Buffer Nowait %: 100.00       Redo NoWait %: 100.00
             Buffer Hit   %:   99.92    In-memory Sort %: 100.00
             Library Hit   %:   98.47        Soft Parse %:   99.32
             Execute to Parse %:    8.19         Latch Hit %:   99.63
             Parse CPU to Parse Elapsd %:   89.90     % Non-Parse CPU:   99.62There rdbms performs approximately 48 soft parse per second ,Soft Parse % and Library Hit very close to 99 it means there main part of sql are shared.Also here user calls similar high per second but executions less,however you should be try minimizing soft parsing.I do not know exactly for which interval you get this report but Execute to Parse % indicate that when executing query oracle can not find early cursor handles(open or closed) but it can find sql text and plan information from shared pool according hash values,in this case oracle perform soft parse again.In your case you also investigate shared pool size/fragmentation.To avoid little Execute to Parse % you can increase SESSION_CACHED_CURSORS or implement CURSOR_SPACE_FOR_TIME.So refer documentation and find how to use these parameters.

What is Execute to Parse % and how to tune it when it lower?

What is Execute to Parse % and how to tune it when it is lower?

Gjohn wrote:
What is Execute to Parse % and how to tune it when it is lower?If you don't know what it is, how are you going to decide that you need to tune it.
Here's a little information on how pointless it can be to get too worried about that particular "Instance Efficiency" percentage in Statspack and the AWR: http://jonathanlewis.wordpress.com/2006/12/27/analysing-statspack-2/
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
"There's no sense in being precise when you don't even know what you're talking about"
John von Neumann

Execute to Parse的意义

网友的提问：
AWR 中的"Execute to Parse"指标有何意义？

Execute to Parse 指标反映了执行解析比
其公式为 1-(parse/execute) , 目标为100% 及接近于只执行而不解析
在oracle中解析往往是执行的先提工作，但是通过游标共享可以解析一次执行多次，执行解析可能分成多种场景：
1.hard coding => 硬编码代码硬解析一次，执行一次，则理论上其执行解析比为 1:1 ，则理论上Execute to Parse =0 极差，且soft parse比例也为0%
2.绑定变量但是仍软解析=》软解析一次，执行一次，这种情况虽然比前一种好但是执行解析比(这里的parse，包含了软解析和硬解析)仍是1:1，理论上Execute to Parse =0 极差，但是soft parse比例可能很高
3. 使用静态SQL、动态绑定、session_cached_cursor、open cursors等技术实现的解析一次，执行多次，执行解析比为N:1，则 Execute to Parse= 1- (1/N) 执行次数越多 Execute to Parse越接近100% ，这种是我们在OLTP环境中喜闻乐见的！
通俗地说 soft parse反映了软解析率，而软解析在oracle中仍是较昂贵的操作，我们希望的是解析1次执行N次，如果每次执行均需要软解析，那么虽然soft parse%=100% 但是parse time仍可能是消耗DB TIME的大头。
Execute to Parse反映了执行解析比，Execute to Parse和soft parse% 都很低那么说明却是没有绑定变量，而如果 soft parse% 接近99% 而Execute to Parse 不足90% 则说明没有执行解析比低，需要通过静态SQL、动态绑定、session_cached_cursor、open cursors等技术减少软解析。
Edited by: Maclean Liu on 2012-8-22 下午7:35
Edited by: Maclean Liu on 2012-8-22 下午7:38

Execute to parse ratio is 49 any problem

Hi ,
execute to parse ratio is 49 any problem ?

I assume you're looking at a Statspack or AWR report?
First, it's important to understand what the Parse to Execute ratio is.
It's calculated as:
round(100*(1-:prse/:exe),2)So, the idea is, for a given SQL statement, in the ideal world, you parse it once, and execute it many times. If you do that, your Parse to Execute ratio will tend towards 100%. 100% is a "perfect score".
As you parse more and more, relative to executions, the ratio will fall. If you parse once per execution, your Parse to Execute ratio will go to 0%. That's not good, but, it could actually be even worse than that. Some brain dead applications actually do more parses than executions. If that happens, your Parse to Execute ratio will go negative.
So, is 49 "bad"? What is bad? Well, that depends. While it's true that any Parse to Execute ratio that's less than the high 90s could potentially be improved, the question really is how much will that benefit your system?
So, you need to ask yourself some questions. First, do you even have a performance probem? If not, then any effort spent tuning the system is almost certainly a waste of time. If you do have a performance problem, you should be profiling the critical business processes, to analyze and understand where they are spending their time. If one or more, poor performing, critical business processes is spending excessive time on parsing, then it may be worth looking at what's going on.
In general, ratios such as Parse to Execute, buffer cache hit, etc, are almost never useful in isolation. However, if all you have is an AWR or Statspack report, and you're trying to understand if the Parse to Execute ratio needs attention, then you should look at a few other numbers in the report. Look at the Top 5 Timed events; do any of them have anything to do with parsing? If not, then parsing is probably not an issue. Look at % Non-Parse CPU; if it's very high, say in the 90s, then almost certainly parsing is not a significant issue, so who cares about the Parse to Execute ratio?
Finally, if you do think that, in your case, Parse to Execute ratio is a problem, it's important to know that the only way to improve it is by reducing the number of parses or increase the numbers of executions. And, the only way to change number of parses or number of executions, is by changing the client program. There is no instance level adjustment or parameter that will have any effect on that statistic.
Hope that helps you understand how to interpret that statistic,
-Mark

Execute to Parse %

Hi All,
while i am checking AWR Report i am getting Execute to Parse %: -0.79
When i check cursor_sharing parameter it is set to EXACT
In my view shall i switch it to force or not

Vikas Kohli wrote:
Load Profile
     Per Second     Per Transaction
Redo size:     175,185.67     252,714.86
Logical reads:     11,961.83     17,255.59
Block changes:     183.62     264.89
Physical reads:     333.09     480.50
Physical writes:     18.18     26.22
User calls:     4.53     6.54
Parses:     21.03     30.34
Hard parses:     0.01     0.01
Sorts:     0.66     0.95
Logons:     0.07     0.11
Executes:     20.87     30.10
Transactions:     0.69
% Blocks changed per Read:     1.54     Recursive Call %:     92.84
Rollback per transaction %:     2.30     Rows per Sort:     ########I beleive you have shared it for 1hr time. Looking at this Hard parsing is not an issue. So more then half of your problem is solved here. Next you can check how about the soft parsing.
Have you looked at thead : execute to parse ratio is 49 any problem ?
Also please check whats the ration for % Non-Parse CPU ? If its high, near to 90 then parsing is not a problem for you. HOPE This Help

Performance Issue: Wait event "log file sync" and "Execute to Parse %"

In one of our test environments users are complaining about slow response.
In statspack report folowing are the top-5 wait events
Event Waits Time (cs) Wt Time
log file parallel write 1,046 988 37.71
log file sync 775 774 29.54
db file scattered read 4,946 248 9.47
db file parallel write 66 248 9.47
control file parallel write 188 152 5.80
And after runing the same application 4 times, we are geting Execute to Parse % = 0.10. Cursor sharing is forced and query rewrite is enabled
When I view v$sql, following command is parsed frequently
EXECUTIONS PARSE_CALLS
SQL_TEXT
93380 93380
select SEQ_ORDO_PRC.nextval from DUAL
Please suggest what should be the method to troubleshoot this and if I need to check some more information
Regards,
Sudhanshu Bhandari

Well, of course, you probably can't eliminate this sort of thing entirely: a setup such as yours is inevitably a compromise. What you can do is make sure your log buffer is a good size (say 10MB or so); that your redo logs are large (at least 100MB each, and preferably large enough to hold one hour or so of redo produced at the busiest time for your database without filling up); and finally set ARCHIVE_LAG_TARGET to something like 1800 seconds or more to ensure a regular, routine, predictable log switch.
It won't cure every ill, but that sort of setup often means the redo subsystem ceases to be a regular driver of foreground waits.

Execute to Parse % is very low!!..need assistance

HI,
While looking in the statspack report, I found that under Instance efficiency area
the percentage for 'Execute to parse' is 10.35% and rest of the percentage are as following:
Buffer Nowait %: 99.89 Redo NoWait %: 100.00
Buffer Hit %: 92.57 In-memory Sort %: 99.98
Library Hit %: 99.86 Soft Parse %: 99.74
Execute to Parse %: 10.35 Latch Hit %: 99.88
Parse CPU to Parse Elapsd %: 81.74 % Non-Parse CPU: 96.19
12040171 parses (31500 hard parses), 13430267 executions
As per me, it is due to the high number of parsing compares to execution. Could anyone tell me that having a percentage for 'Exection to Parse" as above is considered ok? Is there any standard percentage for this parameter that a database should achieve?
Thanks
Ratheesh

I am not sure lack of binding is the problem here
Library Hit %: 99.86 Soft Parse %: 99.74
Execute to Parse %: 10.35 Latch Hit %: 99.88
12040171 parses (31500 hard parses), 13430267 executionsLibrary hit is 99.86 which shows the SQL is being shared and reused, hard parses that you would get if binds are not being used is low, soft parse however is high.
Could be just ref cursor usage
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:904605517791
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:865497961356
Or an application is forcing a parse
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:4032595293314
Whatever the reason, it means you should leave cursor_sharing set to exact, as it will not positively affect the parse ratio, but can still have all the drawbacks already mentioned.

Statspack report, execute to parse %

Hi guys,
I am finding the Execute to Parse ratio very low in a database. What is the desired percentage for this. And its significance.
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 99.99
Buffer Hit %: 99.92 In-memory Sort %: 99.95
Library Hit %: 97.68 Soft Parse %: 95.13
Execute to Parse %: 9.38 Latch Hit %: 99.99
Parse CPU to Parse Elapsd %: 95.38 % Non-Parse CPU: 96.90
Thanks
KHAL

What is the desired percentage for this ?Depends a lot on your database usage. For an OLTP database, this should be generally speaking much higher. For a datawarehouse, it is less important.
But what really matters is the general database performance evaluated by its users: it is OK or slow or very slow ?
See http://asktom.oracle.com/pls/ask/f?p=4950:8:2765691383260886028::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:4032595293314 to see what you can get and what you cannot get with these numbers.

Need to find sql/users that is parsing but NEVER executing

hello all,
I have been trying to figure out how to find sql or user who are pharse sql but not executing them. thats becoz my execute to prase % in my AWR report is negative. meaning someone is parsing statements and NEVER executing them. They are just chewing up your CPU, latching the shared pool, killing your performance.
which is not a good thing and i want to find out what user is doing that or what SID or what sql is diong whats its doing. How can i find that out. Any querys out there to do that or ?? THANKS
this is 10.2.0.3 on AIX. and here is part of AWR
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %: 100.00       Redo NoWait %: 100.00
            Buffer Hit   %:   80.74    In-memory Sort %:   99.10
            Library Hit   %:   92.95        Soft Parse %:   91.24
         Execute to Parse %: -31.89         Latch Hit %:   99.99
Parse CPU to Parse Elapsd %:   87.32     % Non-Parse CPU:   99.92
Edited by: user630084 on Mar 13, 2009 7:51 AM

true i can use that, I am getting about 8 rows out of it and there are about 100+ connections as of now. But here is the thing. As the app use only one schema(lets call it scott). Everybody login thru that schema (scott/tiger)...so that 87 rows that i am getting..all of them are parsing_schema_name=scott and parsing_user_id=55 ..........but i need those 8 users SID...so i can pin point...hey u are the one who is just prasing and not executing...if you know what i mean...so i need that SID...i got the parsing_schema_name and parsing_user_id...but need the SID...so how can i get that ???

High library cache load lock waits in AWR

Hi All,
Today i faced a significant performance problem related to shared pool. I made some observations, thought it would be a nice idea to share them with Oracle experts. Please feel free to add your observations/recommendations and correct me where i am wrong.
Here are the excerpts from AWR report created for the problem timing. Database server is on 10.2.0.3 and running with 2*16 configuration. DB cache size is 4,000M and shared pool size is of 3008M.
Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 9994 29-Jun-09 10:00:07 672 66.3
End Snap: 10001 29-Jun-09 17:00:49 651 64.4
Elapsed:   420.70 (mins)
DB Time:   4,045.34 (mins)   -- Very poor response time visible from difference between DB time and elapsed time.
Load Profile
Per Second Per Transaction
Redo size: 248,954.70 23,511.82
Logical reads: 116,107.04 10,965.40
Block changes: 1,357.13 128.17
Physical reads: 125.49 11.85
Physical writes: 51.49 4.86
User calls: 224.69 21.22
Parses: 235.22 22.21
Hard parses: 4.83 0.46
Sorts: 102.94 9.72
Logons: 1.12 0.11
Executes: 821.11 77.55
Transactions: 10.59   -- User calls and Parse count are almost same, means most of the calls are for parse. Most of the parses are soft. Per transaction 22 parses are very high figure.
-- Not much disk I/O activity. Most of the reads are being satisfy from memory.
Instance Efficiency
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 99.92 In-memory Sort %: 100.00
Library Hit %: 98.92 Soft Parse %: 97.95
Execute to Parse %: 71.35 Latch Hit %: 99.98
Parse CPU to Parse Elapsd %: 16.82 % Non-Parse CPU: 91.41 -- Low execute to parse ratio denotes CPU is significantly busy in parsing. Soft Parse% showing, most of the parse are soft parses. It means we should concentrate on soft parsing activity.
-- Parse CPU to Parse Elapsed % is quite low, means some bottleneck is there related to parsing. It could be a side-effect of huge parsing pressure. Like CPU cycles are not available.
Shared Pool Statistics
Begin End
Memory Usage %: 81.01 81.92
% SQL with executions>1: 88.51 86.93
% Memory for SQL w/exec>1: 86.16 86.76 -- Shared Pool memory seems ok (in 80% range)
-- 88% of the SQLs are repeating ones. It's a good sign.
Top 5 Timed Events
Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
library cache load lock 24,243 64,286 2,652 26.5 Concurrency
db file sequential read 1,580,769 42,267 27 17.4 User I/O
CPU time   33,039   13.6
latch: library cache 53,013 29,194 551 12.0 Concurrency
db file scattered read 151,669 13,550 89 5.6 User I/O Problem-1: Contention on Library cache: May be due to under-sized shared pool, incorrect parameters, poor application design, But since we already observed that most of the parses are soft parses and shared pool usgae in 80%, seems problem related to holding cursors. open_cursors/session_cached_cursors are red flags.
Problem-2: User I/O, may be due to poor SQLs, I/O sub-system, or poor physical design (wrong indexes are being used as DB file seq reads)
Wait Class
Wait Class Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn
Concurrency 170,577 44.58 109,020 639 0.64
User I/O 2,001,978 0.00 59,662 30 7.49
System I/O 564,771 0.00 8,069 14 2.11
Application 145,106 1.25 6,352 44 0.54
Commit 176,671 0.37 4,528 26 0.66
Other 27,557 6.31 2,532 92 0.10
Network 6,862,704 0.00 696 0 25.68
Configuration 3,858 3.71 141 37 0.01
Wait Events
Event Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn
library cache load lock 24,243 83.95 64,286 2652 0.09
db file sequential read 1,580,769 0.00 42,267 27 5.91
latch: library cache 53,013 0.00 29,194 551 0.20
db file scattered read 151,669 0.00 13,550 89 0.57
latch: shared pool 25,403 0.00 12,969 511 0.10
log file sync 176,671 0.37 4,528 26 0.66
enq: TM - contention 1,455 90.93 3,975 2732 0.01 Instance Activity Stats
opened cursors cumulative 5,290,760 209.60 19.80
parse count (failures) 6,181 0.24 0.02
parse count (hard) 121,841 4.83 0.46
parse count (total) 5,937,336 235.22 22.21
parse time cpu 283,787 11.24 1.06
parse time elapsed 1,687,096 66.84 6.31 Latch Activity
library cache 85,042,375 0.15 0.43 29194 304,831 7.16
library cache load lock 257,089 0.00 1.20 0 69,065 0.00
library cache lock 41,467,300 0.02 0.07 6 2,714 0.07
library cache lock allocation 730,422 0.00 0.44 0 0
library cache pin 28,453,986 0.01 0.16 8 167 0.00
library cache pin allocation 509,000 0.00 0.38 0 0 Init.ora parameters
cursor_sharing= EXACT
open_cursors= 3000
session_cached_cursors= 0
-- open_cursors value is too high. I have checked that maximum usage by a single session is 12%.
-- session_cached_cursors are 0 causing soft parsing. 500/600 is good number to start with.
cursor_sharing exact may cause hard parses. But here, hard parsing is comparatively small, we can ignore this.
From v$librarycache
NAMESPACE             GETS    GETHITS GETHITRATIO       PINS PINHITRATIO    RELOADS INVALIDATIONS
SQL AREA            162827      25127 .154317159 748901435 .999153087     107941         81886-- high invalidation count due to DDL like activities.
-- high reloads due to small library cache.
-- hit ratio too small.
-- Need to pin frequently executed objects into library cache.
P.S. Same question asked on Oracle_L, but due to formatting reasons, pasing duplicate contents here.
Regards,
Neeraj Bhatia
Edited by: Neeraj.Bhatia2 on Jul 13, 2009 6:51 AM

Thanks Charles. I really appreciate your efforts to diagnose the issue.
I agree with you performance issue is caused by soft parsing, which can be solved by holding cursors (session_cached_cursors). It may be due to oversized shared pool, which is causing delay in searching child cursors.
My second thought is, there is large number of reloads, which can be due to under-sized shared pool, if invalidation activities are not going (CBO statistics collection, DDL etc), cursors are being flushed frequently.
CPU utilization is continuously high (above 90%). Pasting additional information from same AWR report.
Namespace                Get Requests       Pct Miss        Pin Requests         Pct Miss      Reloads        Invalidations
BODY                       225,345               0.76            4,965,541            0.15           5,533           0
CLUSTER                   1,278                  1.41            2,542                  1.73           26                0
INDEX                       5,982                  9.31            13,922                7.35           258               0
SQL AREA                  141,465              54.10           27,831,235         1.21           69,863          19,085 Latch Miss Sources
Latch Name             Where                                         NoWait Misses                 Sleeps             Waiter Sleeps
library cache lock       kgllkdl: child: no lock handle             0                                   8,250                   5,792 Time Model Statistics
Statistic Name                                                                           Time (s)                               % of DB Time
sql execute elapsed time                                                           206,979.31                                      85.27
PL/SQL execution elapsed time                                                    94,651.78                                      39.00
DB CPU                                                                                     33,039.29                                      13.61
parse time elapsed                                                                      22,635.47                                       9.33
inbound PL/SQL rpc elapsed time                                                  14,763.48                                       6.08
hard parse elapsed time                                                               14,136.77                                       5.82
connection management call elapsed time                                        1,625.07                                       0.67
PL/SQL compilation elapsed time                                                        760.76                                       0.31
repeated bind elapsed time                                                               664.81                                       0.27
hard parse (sharing criteria) elapsed time                                             500.11                                       0.21
Java execution elapsed time                                                              252.95                                       0.10
failed parse elapsed time                                                                   167.23                                       0.07
hard parse (bind mismatch) elapsed time                                             124.11                                       0.05
sequence load elapsed time                                                                23.34                                        0.01
DB time                                                                                   242,720.12
background elapsed time                                                             11,645.52
background cpu time                                                                      247.25 According to this DB CPU is 65% utilization (DB CPU + Background CPU / Total Available CPU seconds). While at the same time DB host was 95% utilized (confirmed from DBA_HIST_SYSMETRIC_SUMMARY).
Operating System Statistics
Statistic                                         Total
BUSY_TIME                             3,586,030
IDLE_TIME                              1,545,064
IOWAIT_TIME                              22,237
NICE_TIME                                           0
SYS_TIME                                  197,661
USER_TIME                              3,319,452
LOAD                                                 11
RSRC_MGR_CPU_WAIT_TIME                  0
PHYSICAL_MEMORY_BYTES          867,180
NUM_CPUS                                           2

Blank awr report shown in oracle standars edition 11g (11.2.0.1.0)

Hi, friends ..
I am using Oracle 11g standars edition(11.2.0.1.0) on solaris 10 platform.I do have a very strange probleem..when iam trying to capture awr report i am getting a blank
awr report contain ing nothing...like below section
---------------------------------------------------------------------------->
WARNING: Since the DB Time is less than one second, there was minimal foreground activity in the snapshot period. Some of the percentage values will be invalid.
WORKLOAD REPOSITORY report for
DB Name DB Id Instance Inst num Startup Time Release RAC
DISDB 771054785 disdb 1 30-Dec-10 10:12 11.2.0.1.0 NO
Host Name Platform CPUs Cores Sockets Memory (GB)
dissemination-new Solaris Operating System (x86-64) .00
Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 1 30-Dec-10 11:30:21
End Snap: 2 30-Dec-10 12:30:52
Elapsed: 60.51 (mins)
DB Time: 0.00 (mins)
Report Summary
Cache Sizes
Begin End
Buffer Cache: M M Std Block Size: K
Shared Pool Size: 0M 0M Log Buffer: K
Load Profile
Per Second Per Transaction Per Exec Per Call
DB Time(s): 0.0 0.0 0.00 0.00
DB CPU(s): 0.0 0.0 0.00 0.00
Redo size:
Logical reads: 0.0 1.0
Block changes: 0.0 1.0
Physical reads: 0.0 1.0
Physical writes: 0.0 1.0
User calls: 0.0 1.0
Parses: 0.0 1.0
Hard parses:
W/A MB processed: 0.0 0.0
Logons:
Executes: 0.0 1.0
Rollbacks:
Transactions: 0.0
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: Redo NoWait %:
Buffer Hit %: In-memory Sort %:
Library Hit %: Soft Parse %:
Execute to Parse %: 0.00 Latch Hit %:
Parse CPU to Parse Elapsd %: % Non-Parse CPU:
Shared Pool Statisitics Not Available
Top 5 Timed Foreground Events
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
DB CPU 0 100.00
Host CPU (CPUs: Cores: Sockets: )
Load Average Begin Load Average End %User %System %WIO %Idle
Instance CPU
%Total CPU %Busy CPU %DB time waiting for CPU (Resource Manager)
Memory Statistics
Begin End
Host Mem (MB):
SGA use (MB):
PGA use (MB):
% Host Mem used for SGA+PGA:
Main Report
Report Summary
Wait Events Statistics
SQL Statistics
Instance Activity Statistics
IO Stats
Buffer Pool Statistics
Advisory Statistics
Wait Statistics
Undo Statistics
Latch Statistics
Segment Statistics
Dictionary Cache Statistics
Library Cache Statistics
Memory Statistics
Streams Statistics
Resource Limit Statistics
Shared Server Statistics
init.ora Parameters
Back to Top
Wait Events Statistics
Time Model Statistics
Operating System Statistics
Operating System Statistics - Detail
Foreground Wait Class
Foreground Wait Events
Background Wait Events
Wait Event Histogram
Wait Event Histogram Detail (64 msec to 2 sec)
Wait Event Histogram Detail (4 sec to 2 min)
Wait Event Histogram Detail (4 min to 1 hr)
Service Statistics
Service Wait Class Stats
Back to Top
Time Model Statistics
No data exists for this section of the report.
Back to Wait Events Statistics
Back to Top
Operating System Statistics
No data exists for this section of the report.
Back to Wait Events Statistics
Back to Top
Operating System Statistics - Detail
No data exists for this section of the report.
Back to Wait Events Statistics
Back to Top
Foreground Wait Class
s - second, ms - millisecond - 1000th of a second
ordered by wait time desc, waits desc
%Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0
Captured Time accounts for % of Total DB time .00 (s)
Total FG Wait Time: (s) DB CPU time: .00 (s)
Wait Class Waits %Time -outs Total Wait Time (s) Avg wait (ms) %DB time
DB CPU 0 100.00
Back to Wait Events Statistics
Back to Top
Foreground Wait Events
No data exists for this section of the report.
Back to Wait Events Statistics
Back to Top
Background Wait Events
No data exists for this section of the report.
Back to Wait Events Statistics
Back to Top
Wait Event Histogram
No data exists for this section of the report.
Back to Wait Events Statistics
Back to Top
Wait Event Histogram Detail (64 msec to 2 sec)
No data exists for this section of the report.
Back to Wait Events Statistics
Back to Top
Wait Event Histogram Detail (4 sec to 2 min)
No data exists for this section of the report.
Back to Wait Events Statistics
Back to Top
Wait Event Histogram Detail (4 min to 1 hr)
No data exists for this section of the report.
Back to Wait Events Statistics
Back to Top
Service Statistics
No data exists for this section of the report.
Back to Wait Events Statistics
Back to Top
Service Wait Class Stats
No data exists for this section of the report.
Back to Wait Events Statistics
Back to Top
SQL Statistics
SQL ordered by Elapsed Time
SQL ordered by CPU Time
SQL ordered by User I/O Wait Time
SQL ordered by Gets
SQL ordered by Reads
SQL ordered by Physical Reads (UnOptimized)
SQL ordered by Executions
SQL ordered by Parse Calls
SQL ordered by Sharable Memory
SQL ordered by Version Count
Complete List of SQL Text
Back to Top
SQL ordered by Elapsed Time
No data exists for this section of the report.
Back to SQL Statistics
Back to Top
SQL ordered by CPU Time
No data exists for this section of the report.
Back to SQL Statistics
Back to Top
SQL ordered by User I/O Wait Time
No data exists for this section of the report.
Back to SQL Statistics
Back to Top
SQL ordered by Gets
No data exists for this section of the report.
Back to SQL Statistics
Back to Top
SQL ordered by Reads
No data exists for this section of the report.
Back to SQL Statistics
Back to Top
SQL ordered by Physical Reads (UnOptimized)
No data exists for this section of the report.
Back to SQL Statistics
Back to Top
SQL ordered by Executions
No data exists for this section of the report.
Back to SQL Statistics
Back to Top
SQL ordered by Parse Calls
No data exists for this section of the report.
Back to SQL Statistics
Back to Top
SQL ordered by Sharable Memory
No data exists for this section of the report.
Back to SQL Statistics
Back to Top
SQL ordered by Version Count
No data exists for this section of the report.
Back to SQL Statistics
Back to Top
Complete List of SQL Text
No data exists for this section of the report.
Back to SQL Statistics
Back to Top
Instance Activity Statistics
Instance Activity Stats
Instance Activity Stats - Absolute Values
Instance Activity Stats - Thread Activity
Back to Top
Instance Activity Stats
No data exists for this section of the report.
Back to Instance Activity Statistics
Back to Top
Instance Activity Stats - Absolute Values
No data exists for this section of the report.
Back to Instance Activity Statistics
Back to Top
Instance Activity Stats - Thread Activity
No data exists for this section of the report.
Back to Instance Activity Statistics
Back to Top
IO Stats
IOStat by Function summary
IOStat by Filetype summary
IOStat by Function/Filetype summary
Tablespace IO Stats
File IO Stats
Back to Top
IOStat by Function summary
No data exists for this section of the report.
Back to IO Stats
Back to Top
IOStat by Filetype summary
No data exists for this section of the report.
Back to IO Stats
Back to Top
IOStat by Function/Filetype summary
No data exists for this section of the report.
Back to IO Stats
Back to Top
Tablespace IO Stats
No data exists for this section of the report.
Back to IO Stats
Back to Top
File IO Stats
No data exists for this section of the report.
Back to IO Stats
Back to Top
Buffer Pool Statistics
Buffer Pool Statistics
Checkpoint Activity
Back to Top
Buffer Pool Statistics
No data exists for this section of the report.
Back to Buffer Pool Statistics
Back to Top
Checkpoint Activity
No data exists for this section of the report.
Back to Buffer Pool Statistics
Back to Top
Advisory Statistics
Instance Recovery Stats
MTTR Advisory
Buffer Pool Advisory
PGA Aggr Summary
PGA Aggr Target Stats
PGA Aggr Target Histogram
PGA Memory Advisory
Shared Pool Advisory
SGA Target Advisory
Streams Pool Advisory
Java Pool Advisory
Back to Top
Instance Recovery Stats
No data exists for this section of the report.
Back to Advisory Statistics
Back to Top
MTTR Advisory
No data exists for this section of the report.
Back to Advisory Statistics
Back to Top
Buffer Pool Advisory
No data exists for this section of the report.
Back to Advisory Statistics
Back to Top
PGA Aggr Summary
No data exists for this section of the report.
Back to Advisory Statistics
Back to Top
PGA Aggr Target Stats
No data exists for this section of the report.
Back to Advisory Statistics
Back to Top
PGA Aggr Target Histogram
No data exists for this section of the report.
Back to Advisory Statistics
Back to Top
PGA Memory Advisory
No data exists for this section of the report.
Back to Advisory Statistics
Back to Top
Shared Pool Advisory
No data exists for this section of the report.
Back to Advisory Statistics
Back to Top
SGA Target Advisory
No data exists for this section of the report.
Back to Advisory Statistics
Back to Top
Streams Pool Advisory
No data exists for this section of the report.
Back to Advisory Statistics
Back to Top
Java Pool Advisory
No data exists for this section of the report.
Back to Advisory Statistics
Back to Top
Wait Statistics
Buffer Wait Statistics
Enqueue Activity
Back to Top
Buffer Wait Statistics
No data exists for this section of the report.
Back to Wait Statistics
Back to Top
Enqueue Activity
No data exists for this section of the report.
Back to Wait Statistics
Back to Top
Undo Statistics
Undo Segment Summary
Undo Segment Stats
Back to Top
Undo Segment Summary
No data exists for this section of the report.
Back to Undo Statistics
Back to Top
Undo Segment Stats
No data exists for this section of the report.
Back to Undo Statistics
Back to Top
Latch Statistics
Latch Activity
Latch Sleep Breakdown
Latch Miss Sources
Mutex Sleep Summary
Parent Latch Statistics
Child Latch Statistics
Back to Top
Latch Activity
No data exists for this section of the report.
Back to Latch Statistics
Back to Top
Latch Sleep Breakdown
No data exists for this section of the report.
Back to Latch Statistics
Back to Top
Latch Miss Sources
No data exists for this section of the report.
Back to Latch Statistics
Back to Top
Mutex Sleep Summary
No data exists for this section of the report.
Back to Latch Statistics
Back to Top
Parent Latch Statistics
No data exists for this section of the report.
Back to Latch Statistics
Back to Top
Child Latch Statistics
No data exists for this section of the report.
Back to Latch Statistics
Back to Top
Segment Statistics
Segments by Logical Reads
Segments by Physical Reads
Segments by Physical Read Requests
Segments by UnOptimized Reads
Segments by Optimized Reads
Segments by Direct Physical Reads
Segments by Physical Writes
Segments by Physical Write Requests
Segments by Direct Physical Writes
Segments by Table Scans
Segments by DB Blocks Changes
Segments by Row Lock Waits
Segments by ITL Waits
Segments by Buffer Busy Waits
Back to Top
Segments by Logical Reads
Total Logical Reads: 1
Captured Segments account for 4.6E+06% of Total
Owner Tablespace Name Object Name Subobject Name Obj. Type Logical Reads %Total
SYS SYSTEM I_SYSAUTH1 INDEX 15,008 1500800.00
SYS SYSTEM I_OBJ2 INDEX 4,752 475200.00
SYS SYSTEM TAB$ TABLE 2,176 217600.00
SYS SYSTEM I_JOB_NEXT INDEX 1,856 185600.00
SYS SYSTEM SYS_C00646 INDEX 1,664 166400.00
Back to Segment Statistics
Back to Top
Segments by Physical Reads
Total Physical Reads: 1
Captured Segments account for 400.0% of Total
Owner Tablespace Name Object Name Subobject Name Obj. Type Physical Reads %Total
SYS SYSAUX WRH$_SYSMETRIC_SUMMARY_INDEX INDEX 3 300.00
SYS SYSTEM KOTAD$ TABLE 1 100.00
Back to Segment Statistics
Back to Top
Segments by Physical Read Requests
Total Physical Read Requests: 1
Captured Segments account for 400.0% of Total
Owner Tablespace Name Object Name Subobject Name Obj. Type Phys Read Requests %Total
SYS SYSAUX WRH$_SYSMETRIC_SUMMARY_INDEX INDEX 3 300.00
SYS SYSTEM KOTAD$ TABLE 1 100.00
Back to Segment Statistics
Back to Top
Segments by UnOptimized Reads
Total UnOptimized Read Requests: 1
Captured Segments account for 400.0% of Total
Owner Tablespace Name Object Name Subobject Name Obj. Type UnOptimized Reads %Total
SYS SYSAUX WRH$_SYSMETRIC_SUMMARY_INDEX INDEX 3 300.00
SYS SYSTEM KOTAD$ TABLE 1 100.00
Back to Segment Statistics
Back to Top
Segments by Optimized Reads
No data exists for this section of the report.
Back to Segment Statistics
Back to Top
Segments by Direct Physical Reads
No data exists for this section of the report.
Back to Segment Statistics
Back to Top
Segments by Physical Writes
Total Physical Writes: 1
Captured Segments account for 1.1E+04% of Total
Owner Tablespace Name Object Name Subobject Name Obj. Type Physical Writes %Total
SYSMAN SYSAUX MGMT_METRICS_RAW_PK INDEX 27 2700.00
SYS SYSAUX WRH$_SYSMETRIC_HISTORY TABLE 16 1600.00
SYS SYSAUX WRH$_SYSMETRIC_HISTORY_INDEX INDEX 16 1600.00
SYSMAN SYSAUX MGMT_SYSTEM_PERF_LOG_IDX_01 INDEX 9 900.00
SYS SYSAUX SMON_SCN_TIME TABLE 9 900.00
Back to Segment Statistics
Back to Top
Segments by Physical Write Requests
Total Physical Write Requestss: 1
Captured Segments account for 5.1E+03% of Total
Owner Tablespace Name Object Name Subobject Name Obj. Type Phys Write Requests %Total
SYSMAN SYSAUX MGMT_METRICS_RAW_PK INDEX 11 1100.00
SYS SYSAUX SMON_SCN_TIME TABLE 9 900.00
SYSMAN SYSAUX MGMT_SYSTEM_PERF_LOG_IDX_01 INDEX 6 600.00
SYSMAN SYSAUX MGMT_CURRENT_METRICS_PK INDEX 4 400.00
SYS SYSTEM I_JOB_NEXT INDEX 2 200.00
Back to Segment Statistics
Back to Top
Segments by Direct Physical Writes
No data exists for this section of the report.
Back to Segment Statistics
Back to Top
Segments by Table Scans
Total Table Scans: 1
Captured Segments account for 900.0% of Total
Owner Tablespace Name Object Name Subobject Name Obj. Type Table Scans %Total
SYS SYSTEM I_OBJ2 INDEX 9 900.00
Back to Segment Statistics
Back to Top
Segments by DB Blocks Changes
% of Capture shows % of DB Block Changes for each top segment compared
with total DB Block Changes for all segments captured by the Snapshot
Owner Tablespace Name Object Name Subobject Name Obj. Type DB Block Changes % of Capture
SYS SYSTEM I_JOB_NEXT INDEX 896 58.95
SYSMAN SYSAUX MGMT_METRICS_RAW_PK INDEX 160 10.53
SYSMAN SYSAUX MGMT_CURRENT_METRICS_PK INDEX 112 7.37
SYS SYSAUX SMON_SCN_TIME TABLE 80 5.26
SYSMAN SYSAUX MGMT_SYSTEM_PERF_LOG_IDX_01 INDEX 64 4.21
Back to Segment Statistics
Back to Top
Segments by Row Lock Waits
No data exists for this section of the report.
Back to Segment Statistics
Back to Top
Segments by ITL Waits
No data exists for this section of the report.
Back to Segment Statistics
Back to Top
Segments by Buffer Busy Waits
No data exists for this section of the report.
Back to Segment Statistics
Back to Top
Dictionary Cache Stats
No data exists for this section of the report.
Back to Top
Library Cache Activity
No data exists for this section of the report.
Back to Top
Memory Statistics
Memory Dynamic Components
Memory Resize Operations Summary
Memory Resize Ops
Process Memory Summary
SGA Memory Summary
SGA breakdown difference
Back to Top
Memory Dynamic Components
No data exists for this section of the report.
Back to Memory Statistics
Back to Top
Memory Resize Operations Summary
No data exists for this section of the report.
Back to Memory Statistics
Back to Top
Memory Resize Ops
No data exists for this section of the report.
Back to Memory Statistics
Back to Top
Process Memory Summary
No data exists for this section of the report.
Back to Memory Statistics
Back to Top
Back to Memory Statistics
Back to Top
SGA breakdown difference
No data exists for this section of the report.
Back to Memory Statistics
Back to Top
Streams Statistics
Streams CPU/IO Usage
Streams Capture
Streams Capture Rate
Streams Apply
Streams Apply Rate
Buffered Queues
Buffered Queue Subscribers
Rule Set
Persistent Queues
Persistent Queues Rate
Persistent Queue Subscribers
Back to Top
Streams CPU/IO Usage
No data exists for this section of the report.
Back to Streams Statistics
Back to Top
Streams Capture
No data exists for this section of the report.
Back to Streams Statistics
Back to Top
Streams Capture Rate
No data exists for this section of the report.
Back to Streams Statistics
Back to Top
Streams Apply
No data exists for this section of the report.
Back to Streams Statistics
Back to Top
Streams Apply Rate
No data exists for this section of the report.
Back to Streams Statistics
Back to Top
Buffered Queues
No data exists for this section of the report.
Back to Streams Statistics
Back to Top
Buffered Queue Subscribers
No data exists for this section of the report.
Back to Streams Statistics
Back to Top
Rule Set
No data exists for this section of the report.
Back to Streams Statistics
Back to Top
Persistent Queues
No data exists for this section of the report.
Back to Streams Statistics
Back to Top
Persistent Queues Rate
No data exists for this section of the report.
Back to Streams Statistics
Back to Top
Persistent Queue Subscribers
No data exists for this section of the report.
Back to Streams Statistics
Back to Top
Resource Limit Stats
No data exists for this section of the report.
Back to Top
Shared Server Statistics
Shared Servers Activity
Shared Servers Rates
Shared Servers Utilization
Shared Servers Common Queue
Shared Servers Dispatchers
Back to Top
Shared Servers Activity
No data exists for this section of the report.
Back to Shared Server Statistics
Back to Top
Shared Servers Rates
No data exists for this section of the report.
Back to Shared Server Statistics
Back to Top
Shared Servers Utilization
No data exists for this section of the report.
Back to Shared Server Statistics
Back to Top
Shared Servers Common Queue
No data exists for this section of the report.
Back to Shared Server Statistics
Back to Top
Shared Servers Dispatchers
No data exists for this section of the report.
Back to Shared Server Statistics
Back to Top
init.ora Parameters
No data exists for this section of the report.
Back to Top
Dynamic Remastering Stats
No data exists for this section of the report.
Back to Top
End of Report
---------------------------------------------->>
here intresting is that i also can't have the memory section view also.i trien to clear awr repositary and recreate it..bounce database,also tried taking different snap value.But does notmake any change.can u tell me why tha happening..and how can i get a good awr report.

Hi there,
I have covered this in my blog entry on the subject. Check that link out for more licensing information and other resources.
The problem you are experiencing is caused by the fact that AWR is part of the DIAGNOSTIC and TUNING packs of Oracle 11g, which as of 11g is no longer a standard feature of the database but rather an optional extra which must be licensed in addition to your default Oracle Standard Edition package. In terms of the licensing, you just need to license it as an optional extra so that you will actually be using it legally, and then you can go ahead and enable it.
While it may be an additional licensed item, it is actually installed on your DB by default, but is just not enabled. So, once you have cleared the licensing issue, you will be free to enable diagnostics by setting the new database parameter, CONTROL_MANAGEMENT_PACK_ACCESS. You can do this by running the following as a dba:
<pre>alter system set control_management_pack_access="DIAGNOSTIC+TUNING" scope=both;</pre>
After running this command, your database will start accumulating diagnostic information. Note that you will need to wait until new snapshots are created in which the new diagnostic information will be available. I found that although most of the information became available after setting CONTROL_MANAGEMENT_PACK_ACCESS, it was only once the database was restarted that all of the information became available. I have seen many people reporting similar behavior.
Old snapshots will obviously continue to give the errors because they did not have the diagnostic information available at the time.

User I/O and db file parallel read is high in AWR report

Hi,
We have one performance issue during a job execution.
From the awr report we have identified one query with a table having millions of records causing problems and then we had also fine tuned that query by changing it's code and by using the optmizer hints. It is being executed in plsql batches. After fine tuning, On the first batch execution(first 5000 records) the query is taking only 5 mins, but on the consecutive batches it is consuming more time( more than 30 mins).
From the awr report I got the statistics as
Release : 11.2.0.2.0
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 85.44 In-memory Sort %: 99.98
Library Hit %: 99.76 Soft Parse %: 99.15
Execute to Parse %: 88.91 Latch Hit %: 100.00
Parse CPU to Parse Elapsd %: 87.32 % Non-Parse CPU: 98.65
The buffer hit % is good. On each batch execution it is taking different set of records.
Top 5 Timed Foreground Events
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
db file parallel read 120,485 42,540 353 89.60 User I/O
DB CPU 3,794 7.99
db file sequential read 145,074 606 4 1.28 User I/O
db file scattered read 70,030 556 8 1.17 User I/O
direct path write temp 12,423 21 2 0.04 User I/O
So the I/O is our main concern since that query contains one table with millions of records.
Host CPU (CPUs: 24 Cores: 24 Sockets: 4)
Load Average Begin Load Average End %User %System %WIO %Idle
1.40 1.45 0.6 0.3 3.7 99.0
Load is also normal.
From the Time model statistics , sql execute elapsed time is 98.27% of db time and only 7.99% is that of DB CPU.
Memory Statistics
Begin End
Host Mem (MB): 64,318.0 64,318.0
SGA use (MB): 30,720.0 30,720.0
PGA use (MB): 488.2 497.1
% Host Mem used for SGA+PGA: 48.52 48.54
Both the size of sga_max_size and sga_target are 32,212,254,720(32gb) bytes and that of
pga_aggregate target is 629,145,600(600mb)
from this it is evident that the memory is still available(so increase in memory size is not an option).
The sql statistics for that query shows like that
Elapsed Time (s) Executions Elapsed Time per Exec (s) %Total %CPU %IO SQL Id SQL Text
44,950.03 55 817.27 94.67 6.99 94.72 79dgmrxh4kv74 SELECT /*+ index(cdr_data cdr_...
I can't understand whether the problem is in the database side or with the query?
If the problem is with the query, then how it has been executed in 5 mins for the first batch ?
(all the batches are having 5000 records each).
And how can we reduce the db file parallel read ?
Your valuable advice will be greatly appreciated.
Thanks in advance
Manoj Kumar N

"db file parallel read" is likely to be associated with something like index prefetching.
See:
http://www.freelists.org/post/oracle-l/RE-Calculating-LIOs,11
http://aprakash.wordpress.com/2012/05/29/index-range-scan-and-db-file-scattered-read-as-session-wait-event/
http://jonathanlewis.wordpress.com/2006/12/15/index-operations/
Tune the SQL.
Review the execution plan.
Check whether the statistics are accurate.
Review whether the index hint (and others that we can't see) is appropriate.

Negative Values of Library Cache Hit Ratio in AWR Report

Hi all,
We are getting Negative values of Library cache hit ratio in AWR Report of 11g(11.2.0.3) with Solaris[tm] OE (64-bit).
Please suggest us why it shows negative value.
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: 99.87 Redo NoWait %: 99.99
Buffer Hit %: 92.17 In-memory Sort %: 100.00
Library Hit %: -3,321.23 Soft Parse %: 81.95
Execute to Parse %: 92.88 Latch Hit %: 95.11
Parse CPU to Parse Elapsd %: 87.25 % Non-Parse CPU: 81.39
Regards,
Madhan
Edited by: user12078989 on Jul 25, 2012 7:40 AM

Hi Aman,
DB not restarted during this time.. we don't have production access. we will get awr report automatically from customer daily. also i am getting issue in our local environment v$rowcache view gets values is negative for dc_users and dc_tablespaces parameter may be it's related production issue...

Oracle 11g R2 - AWR Section UnOptimized Read Reqs / Optimized Read Reqs

Hello guys,
using Oracle 11g R2 more and more i have checked out the new AWR and its sections.
I have found some section lke this
SQL ordered by Physical Reads (UnOptimized)DB/Inst: SID/sid Snaps: 20296-202
-> UnOptimized Read Reqs = Physical Read Reqts - Optimized Read Reqs
-> %Opt   - Optimized Reads as percentage of SQL Read Requests
-> %Total - UnOptimized Read Reqs as a percentage of Total UnOptimized Read Reqs
-> Total Physical Read Requests:         151,508
-> Captured SQL account for   25.3% of Total
-> Total UnOptimized Read Requests:         151,508
-> Captured SQL account for   25.3% of Total
-> Total Optimized Read Requests:               1
-> Captured SQL account for    0.0% of TotalWhat the heck is "Optimized Read Reqs" and "UnOptimized Read Reqs"? These terms are used very often right now in AWR of Oracle 11g R2.
Does anyone know what this term means and how it is defined? Don't find any information on web and documentation.
Thanks guys!

Hello,
If my guess is close than "Buffer Hit" (Instance Efficiency Percentages) could be as low as 0% from this report.No it isn't ... check it here:
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %:   99.96       Redo NoWait %: 100.00
            Buffer Hit   %:   99.50    In-memory Sort %: 100.00
            Library Hit   %:   99.09        Soft Parse %:   89.55
         Execute to Parse %:   95.93         Latch Hit %:   98.93
Parse CPU to Parse Elapsd %:   68.68     % Non-Parse CPU:   98.81Sometimes i wonder why oracle introduces such new terms / measurements without documenting it.
Regards

Execute to Parse % in AWR

Similar Messages

Maybe you are looking for