Oracle Buffer Hit Ratio

I m using this query to find Oracle Buffer Hit ratio .Is this query right.Is there some other way of getting more accurate ratio
select trunc((1-(sum(decode(name,'physical reads',value,0))/(sum(decode(name,'db block gets',value,0)) + (sum(decode(name,'consistent gets',value,0)))))) * 100) from v$sysstat

Asif,
Too bad we couldn't meet when I happened to come to Bdesh coz if we could , we would had talked about the same topic for hours. If you are using this hit ratio as the tuning technique than you are not alone. There are so many dbas who are using hit ratio and loose sleep seeing not to a particular %. It was a method that was given years ago by Oracle reason being that at that time, databases , their loads, they were not too much. But now things have changed so should be the troubleshooting techniques. Search over this forum for the same topic and you would see some "cool" threads where some top-notch experts are talking about the same issue.
Aman....

Similar Messages

Which is a better measure of buffer hit ratio?

which out of these gives a better measure of buffer hit ratio?
consistent gets from cache
db block gets from cache
physical reads cache
or
consistent gets
db block gets
physical reads
from v@sysstat?

Hi,
Well you can always edit your reply.There is a button out there to do that.
About the question,I am not clear with the question.What do you mean by "better measure of hit ratio"?
From the PT guide,
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/memory.htm#i56283
The formula includes all three of them in the calculation,
SELECT NAME, VALUE
FROM V$SYSSTAT
WHERE NAME IN ('db block gets from cache', 'consistent gets from cache', 'physical reads cache');
Using the values in the output of the query, calculate the hit ratio for the buffer cache with the following formula:
1 - (('physical reads cache') / ('consistent gets from cache' + 'db block gets from cache')All three of them are part of the hit ratio.When you wrote the three statistics second time,I am not sure how they were different from the first one.All you did was that you removed "cache" word.
There is no "better measure" statistics in the calculation.All three are there.
If your question had some other meaning than I would appreciate if you rephrase and elaborate it please.
Aman....

Differents values for Buffer Hit Ratio

Hi Everyone!
I have only a buffer_pool(8k) and when I execute this two querys(below). The "Buffer Hit Ratio" results are very different.
Anyone know why does this happen?? I searched on the Internet and find out just V$SYSSTAT gather dates of all buffer pools
while V$BUFFER_POOL_STATISTICS maintains statistics for each buffer pool. But i can't understand why it is so different.
Any suggestion?
Thanks!
SELECT 1- ((p.value - l.value - d.value) / s.value) "Buffer Cache Hit Ratio"
FROM v$sysstat s, v$sysstat l, v$sysstat d, v$sysstat p
WHERE s.name = 'session logical reads'
AND d.name = 'physical reads direct'
AND l.name = 'physical reads direct (lob)'
AND p.name = 'physical reads';
Buffer Cache Hit Ratio
,970655577
SELECT NAME, PHYSICAL_READS, DB_BLOCK_GETS, CONSISTENT_GETS,
1 - (PHYSICAL_READS / (DB_BLOCK_GETS + CONSISTENT_GETS)) "Hit Ratio"
FROM V$BUFFER_POOL_STATISTICS;
Hit Ratio
,584760575
ORACLE VERSION: Oracle Server 9.2.0.8.0
OS: IBM/AIX

See metalink note STATISTIC "cache hit ratio" - Reference Note 33883.1 for the correct formula to use in your calculation.
The ratio is of limited value. In and of itself it tells you nothing about the performance of your database.
There have been numerous threads on the ratio in this forum. You can use search to find them if interested.
HTH -- Mark D Powell --

Low buffer hit ratio

Hi all,
could anyone please let me know how I can improve upon the buffer hit ratio in Oracle 8.0
I have increased my buffer size by 40% in the init.ora parameters but there has been no gain at all in the buffer hit ratio after the system has been bounced and up by 42 hrs so could any let me know..
Thanks
Akkama

Why don't u try pinning the objects accessed frequently - even pinning tables are possible.

Buffer hit ratio

I am using the following:
SELECT ROUND(((1-(SUM(DECODE(NAME, 'physical reads', value, 0)) /
(SUM(DECODE(NAME, 'db block gets', value, 0))+
(SUM(DECODE(NAME, 'CONSISTENT GETS', value, 0))))))*100), 2) || '%' BCHR
FROM V$SYSSTAT
to calculate the buffer hit ratio. This query is returning: -1753.28%
Can someone explain why I am getting this crazy number?
Thanks,
mdp

>>
Many folks misunderstand that bit about "setting your own BHR", and falsely conclude that it's a useless metric. It's not useless.
<<
The buffer cache ratio is useful only when considered in relation to other statistics. The problem is that the majority of users seem to think that that a high ratio value is good and a low ratio value is bad based on absolute values and do not understand that the static is dependent on how SQL plans are being solved. If you measure the ratio when the dominant work on the system is being done via hash joins, full scans that touch the target blocks only once, or make use of PQO during the process you can get a fairly low value, but the system is performing well. On the other had poorly performing SQL can result in a high value for the statistic. The value of the statistics bears no direct relationship to performance of the system and it needs to be emphasized that the ratio must be used in conjunction with other available information. The ratio by itself should be considered useless.
>>
If the BHR was totally useless, why does Oracle continue to include it in OEM alert thresholds, and STATSPACK and AWR reports?
<<
Over the years Oracle has done lots of things that turned out to be wrong so just because Oracle includes the statistics in certain products does not really provide a lot of support for the validity of the statistic. Known errors in the documentation have made it through two full releases. Again it is the misapplication of the statistic that is really at issue. Unfortunately, many poorly written DBA Administration and Tuning books in the past claimed that ratio could be used to measure database performance, and in point of fact the ratio has only a passing relationship to performance depending on the application.
HTH -- Mark D Powell --

Buffer hit ratio (to be negative)

Hi All,
My DB Version: 10.2.0
OS: Windows Server 2003
When i am checking snapshots at peak time and comparing it with one when there is no load on the server the buffer hit ratio (to be negative), the buffer cache is too small and the data in is being aged out before it can be used so it must be retrieved again.
So i just want to know that whether should i increase the value of db_cache_size.
What exactly happens when i do this.

Hi;
DB_CACHE_SIZE specifies the size of the DEFAULT buffer pool for buffers with the primary block size (the block size defined by the DB_BLOCK_SIZE initialization parameter).
The value must be at least 4M * number of cpus * granule size (smaller values are automatically rounded up to this value). A user-specified value larger than this is rounded up to the nearest granule size. A value of zero is illegal because it is needed for the DEFAULT memory pool of the primary block size, which is the block size for the SYSTEM tablespace.
Source:
http://docs.oracle.com/cd/B19306_01/server.102/b14237/initparams043.htm
Regard
Helios

Buffer Hit Ratio % -- Whats the right query ?

Whats the right query to track Buffer Hit % ;
Using this :
prompt BUFFER HIT RATIO %
prompt ===============
select 100 * ((a.value+b.value)-c.value) / (a.value+b.value) "Buffer Hit Ratio"
from v$sysstat a, v$sysstat b, v$sysstat c
where
a.statistic# = 38
and
b.statistic# = 39
and
c.statistic# = 40;
Buffer Hit Ratio
99.9678438
However, using this :
Select
Round((Sum(Decode(name, 'consistent gets',value,0)) +
Sum(Decode(name, 'db block gets',value,0)) -
Sum(Decode(name, 'physical reads',value,0))) /
(Sum(Decode(name, 'consistent gets',value,0)) +
Sum(Decode(name, 'db block gets',value,0)) ) * 100, 4)
from V$sysstat;
Comes up as : 67.7069 %
So which is the right one ?
Thanks.

user4874781 wrote:
Well, I recently joined this organisation and that was the script that was used since long to check Buffer Hit Ratio%.
But when I ran a TOAD report, using the other query, the value came up different.
So am confused .. Whats the difference and which is the right one ?
Try running the following query:
select
        statistic#, name
from
        v$sysstat
where
        statistic# in (38,39,40)
or      name in (
                'consistent gets',
                'physical reads',
                'db block gets'
;The you will understand the point the previous answer was making. It's a bad idea to rely on things like the statistic# being consistent across different versions of Oracle - names tend to be safer.
But neither query is correct. If you want any sort of vaguely meaningful "buffer cache hit ratio", you should be quering v$buffer_pool_statistics. See also: Re: Testing of buffer cache reveals these results: and http://jonathanlewis.wordpress.com/2007/09/02/hit-ratios/
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge." Stephen Hawking.

STATSPACK REPORT (BUFFER HIT RATIO)

my statspack report shows that my buffer ration is 83%...what factors i need to look to imporve the buffer hit ratio. Thanks

I deleted because i realized that i took the statspack report of 1 day period.
Below is the Statspack report of 1 hour. Can you please let me know if i still need to increase database buffer cache?
STATSPACK report for
Database DB Id Instance Inst Num Startup Time Release RAC
~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
4254163 TEST1 1 28-Jun-07 23:30 10.2.0.3.0 NO
Host Name: Linux3 Num CPUs: 2 Phys Memory (MB): 7,968
~~~~
Snapshot Snap Id Snap Time Sessions Curs/Sess Comment
~~~~~~~~ ---------- ------------------ -------- --------- -------------------
Begin Snap: 32 03-Jul-07 11:59:13 23 11.0
End Snap: 42 03-Jul-07 14:07:33 26 11.3
Elapsed: 128.33 (mins)
Cache Sizes Begin End
~~~~~~~~~~~ ---------- ----------
Buffer Cache: 100M Std Block Size: 8K
Shared Pool Size: 100M Log Buffer: 33,823K
Load Profile Per Second Per Transaction
~~~~~~~~~~~~ --------------- ---------------
Redo size: 1,259.57 8,598.13
Logical reads: 148.39 1,012.92
Block changes: 6.41 43.76
Physical reads: 41.91 286.09
Physical writes: 0.73 5.02
User calls: 15.66 106.91
Parses: 4.07 27.77
Hard parses: 0.27 1.85
Sorts: 1.70 11.61
Logons: 0.01 0.07
Executes: 9.59 65.47
Transactions: 0.15
% Blocks changed per Read: 4.32 Recursive Call %: 83.09
Rollback per transaction %: 6.03 Rows per Sort: 11.39
Instance Efficiency Percentages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 71.77 In-memory Sort %: 100.00
Library Hit %: 93.15 Soft Parse %: 93.34
Execute to Parse %: 57.58 Latch Hit %: 100.00
Parse CPU to Parse Elapsd %: 97.12 % Non-Parse CPU: 86.74
Shared Pool Statistics Begin End
Memory Usage %: 91.37 92.38
% SQL with executions>1: 77.55 80.43
% Memory for SQL w/exec>1: 83.11 84.69
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time
CPU time 132 48.3
db file sequential read 89,745 91 1 33.4
db file scattered read 29,289 35 1 13.0
control file parallel write 2,558 6 2 2.1
log file parallel write 2,294 3 1 1.0
Host CPU (CPUs: 2)
~~~~~~~~ Load Average
Begin End User System Idle WIO WCPU
0.11 0.11 2.26 2.65 95.09 0.90 0.24
Instance CPU
~~~~~~~~~~~~
% of total CPU for Instance: 1.06
% of busy CPU for Instance: 21.63
%DB time waiting for CPU - Resource Mgr:
Memory Statistics Begin End
~~~~~~~~~~~~~~~~~ ------------ ------------
Host Mem (MB): 7,967.6 7,967.6
SGA use (MB): 316.0 316.0
PGA use (MB): 57.8 62.6
% Host Mem used for SGA+PGA: 4.7 4.8
Time Model System Stats DB/Inst: TEST1/TEST1 Snaps: 32-42
-> Ordered by % of DB time desc, Statistic name
Statistic Time (s) % of DB time
sql execute elapsed time 212.3 92.7
DB CPU 124.2 54.2
parse time elapsed 21.6 9.4
hard parse elapsed time 19.7 8.6
PL/SQL execution elapsed time 4.3 1.9
hard parse (sharing criteria) elaps 1.4 .6
connection management call elapsed 1.4 .6
PL/SQL compilation elapsed time 1.2 .5
repeated bind elapsed time 0.1 .0
hard parse (bind mismatch) elapsed 0.1 .0
sequence load elapsed time 0.0 .0
DB time 228.9
background elapsed time 48.2
background cpu time 39.3
Wait Events DB/Inst: TEST1/TEST1 Snaps: 32-42
-> s - second, cs - centisecond, ms - millisecond, us - microsecond
-> %Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0
-> Only events with Total Wait Time (s) >= .001 are shown
-> ordered by Total Wait Time desc, Waits desc (idle events last)
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
db file sequential read 89,745 0 91 1 79.6
db file scattered read 29,289 0 35 1 26.0
control file parallel write 2,558 0 6 2 2.3
log file parallel write 2,294 0 3 1 2.0
db file parallel write 2,179 0 3 1 1.9
log file sync 1,089 0 2 2 1.0
os thread startup 7 0 1 120 0.0
latch free 3 0 0 89 0.0
SQL*Net break/reset to client 640 0 0 0 0.6
direct path read 140 0 0 1 0.1
control file sequential read 3,599 0 0 0 3.2
SQL*Net more data to client 2,121 0 0 0 1.9
db file parallel read 49 0 0 1 0.0
cursor: pin S wait on X 2 100 0 16 0.0
read by other session 4 0 0 5 0.0
direct path write 24 0 0 0 0.0
latch: shared pool 1 0 0 2 0.0
SQL*Net message from client 120,211 0 47,282 393 106.6
wait for unread message on broadc 7,631 100 7,517 985 6.8
Streams AQ: waiting for messages 1,540 100 7,512 4878 1.4
Streams AQ: qmn slave idle wait 275 0 7,508 27302 0.2
Streams AQ: qmn coordinator idle 554 51 7,508 13553 0.5
Streams AQ: waiting for time mana 25 52 6,643 ###### 0.0
SQL*Net message to client 120,215 0 0 0 106.6
class slave wait 7 0 0 1 0.0
SQL*Net more data from client 146 0 0 0 0.1
Background Wait Events DB/Inst: TEST1/TEST1 Snaps: 32-42
-> %Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0
-> Only events with Total Wait Time (s) >= .001 are shown
-> ordered by Total Wait Time desc, Waits desc (idle events last)
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
control file parallel write 2,557 0 6 2 2.3
log file parallel write 2,290 0 3 1 2.0
db file parallel write 2,179 0 3 1 1.9
os thread startup 7 0 1 120 0.0
db file sequential read 1,456 0 1 0 1.3
db file scattered read 25 0 0 8 0.0
control file sequential read 156 0 0 0 0.1
latch: shared pool 1 0 0 2 0.0
rdbms ipc message 25,017 92 59,496 2378 22.2
pmon timer 2,576 100 7,513 2917 2.3
Streams AQ: qmn slave idle wait 275 0 7,508 27302 0.2
Streams AQ: qmn coordinator idle 554 51 7,508 13553 0.5
smon timer 26 96 7,148 ###### 0.0
Streams AQ: waiting for time mana 25 52 6,643 ###### 0.0
Wait Event Histogram DB/Inst: TEST1/TEST1 Snaps: 32-42
-> Total Waits - units: K is 1000, M is 1000000, G is 1000000000
-> % of Waits - column heading: <=1s is truly <1024ms, >1s is truly >=1024ms
-> % of Waits - value: .0 indicates value was <.05%, null is truly 0
-> Ordered by Event (idle events last)
Total ----------------- % of Waits ------------------
Event Waits <1ms <2ms <4ms <8ms <16ms <32ms <=1s >1s
LGWR wait for redo copy 7 100.0
SQL*Net break/reset to cli 640 99.2 .6 .2
SQL*Net more data to clien 2121 100.0
control file parallel writ 2558 84.2 12.0 .7 1.4 1.5 .2
control file sequential re 3599 99.9 .1
cursor: pin S wait on X 2 100.0
db file parallel read 49 93.9 2.0 4.1
db file parallel write 2179 68.2 19.9 6.8 4.0 .9 .1 .1
db file scattered read 29K 90.7 6.0 .5 .5 .6 .8 .9
db file sequential read 89K 89.4 2.8 1.3 3.6 1.5 .7 .6
direct path read 140 87.1 2.9 .7 1.4 7.1 .7
direct path write 24 100.0
latch free 3 100.0
latch: messages 1 100.0
latch: shared pool 1 100.0
log file parallel write 2294 77.4 17.3 2.0 1.3 1.1 .8 .2
log file sync 1089 62.4 28.8 3.3 1.7 2.5 1.1 .2
os thread startup 7 100.0
read by other session 4 50.0 25.0 25.0
SQL*Net message from clien 120K 95.2 1.6 .9 .3 .1 .2 .1 1.7
SQL*Net message to client 120K 100.0
SQL*Net more data from cli 146 100.0
Streams AQ: qmn coordinato 554 49.1 .2 .2 50.5
Streams AQ: qmn slave idle 275 100.0
Streams AQ: waiting for me 1540 .2 99.8
Streams AQ: waiting for ti 25 36.0 16.0 48.0
class slave wait 7 85.7 14.3
pmon timer 2577 .5 .1 .1 99.3
rdbms ipc message 25K 2.3 1.3 1.4 .4 .4 .3 32.1 61.8
smon timer 26 100.0
wait for unread message on 7631 .0 .0 100.0 .0

How should i increase over all buffer hit ratio.....

Hi all,
As shown below if my DB2 databse buffer Qulaity is low .. How should i increase over all buffer hit ratio..
Please advice on any sap standrd notes or procedures
Number                                    1
Total Size                           80,000 KB
Physical Reads                         6.65 ms
Physical Writes                        0.00 ms
Overall Buffer Quality                86.05 %
Data Hit Ratio                        85.79 %
Index Hit Ratio                       87.50 %
No Victim Buffers                259,079,295
--rahul

One of the options is to simply increase the bufferpool size using the following command
db2 alter bufferpool immediate <bufferpool name> size <new bufferpool size>
However, this will affect the hit ration for a particular bufferpool. If you have more than one bufferpool, you need to identify the bufferpool(s) with worst hit ratio. In the SAP DBA Cockpit, check using
Performance -> Bufferpool
The victim buffer information is only useful in case you use alternate page cleaning.
Note that there are other options to fight bad bufferpool hit ratio - however, with your small bufferpool size (80MB) maybe increasing the size is the appropriate step.
Malte

One reason why buffer hit ratio just might be bogus

Hi.
Still trawling through statspack trying to make some sense of it ...
But looking at this, (on undo segments) I have perhaps another reason to sneer at the old buffer cache hit ratio: (in the sense of using it to tune, or of using it to justify action / lack of action).
"The header is also a data block that is frequently modified , so it generally remains in the buffer cache. Therefore, gets of the rollback segment header block increase the buffer cache hit ratio; this artificial increase in the hit ratio can mislead you into thinking that you have allocated enough data blocks to the buffer cache"
:taken from the OP Exam 033 text, p.295

Hi Dan,
The problem is about the usefulness of ratio's in-general, it's not specifically about the BCHR. . . .
This whole thing arose from the Oracle7 performance tuning classes where Oracle Corporation suggested that the BCHR be kept over 90%. . . .
Is the BCHR "bogus"? It is what it is, a ratio. . . .
I agree wit Ben, it does have limited use as an "indicator", that the buffer cache MIGHT be too small to cache the working set of frequently-referenced data blocks. I have my notes here:
http://www.dba-oracle.com/t_buffer_cache_hit_ratio_value.htm
Oh, and as to the buffer cache advisory, it's not perfect (as is any predictive model) and I rarely see one that does not suggest that adding RAM will reduce physical I/O.
Anyway, in just a few years all this will be a moot issue, espeially since solid-state disk has hit $100 per gig. Without spinning platters, there is no need for a large buffer cache at all . . . .
Hope this helps. . .
Donald K. Burleson
Oracle Press author
Author of "Oracle Tuning: The Definitive Reference":
http://www.dba-oracle.com/bp/s_oracle_tuning_book.htm

No swaps anyware still hit Ratio around 4% for Initial Record Buffer

Dear Gurus
I am using ABAP NW7.0 System.
in the system all buffers have hit ratio 99+%
but the initial record buffer hit ratio it below 10%
any way there is no swaps at all still hit Ratio is 4%
The current parameters are:
rsdb/ntab/irbdsize   --->6000
rsdb/ntab/entrycount---> 20000
HITRATIO -
>        %         4
HITS         -
>              64
REQUESTS    -
>             1.729
DB access quality %   -
>       4
DB access      -
>          1.656
DB access saved    -
>         64
Reorgs        -
>               0
Allocated     -
>    KB     6.625
Available     -
>    KB     6.000
Used         -
>     KB     1.099*
Free         -
>     KB     4.901
Available     -
>           5.000
Used         -
>            1.656
Free           -
>         * 3.344*
Objects swapped    -
>          0
Frames swapped    -
>           0
Total          -
>              0
Pl suggest me how can i have the hitratio more.
Thanks in advance

Hello,
Unfortunately we can not tell exactly why the value is low,
however it is not necessarily an incorrect value.
The quality of a buffer and how often it is accessed is measured by the
'%Hit Ratio'. This value will indicate if the information stored in the
buffers, such as table entries, programs and screens, is being hit
directly from the buffer itself or, on the other hand, if the system
needs to bring that data from the database since it was not found in the
buffer.
To find out the buffers with poor quality, first check the system
startup time. When the system is started, all buffers (except the
program buffer which has a pre-load) are initially empty. Therefore,
all objects that are accessed for the first time have to be read from
the database and then loaded into the buffers.
If objects are not yet in the buffer, the hit ratio for the buffer will
be low. The hit ratio increases from the time objects are loaded into
the buffers. The rate of the increase depends on the workload in the
system and is different for each buffer.So it is to be noted that how often you restart the system which resuls in the loading of object again and causes hit rate to be low.
Poor buffer quality is not always due to a real problem. For example,
transports into a system can reduce buffer quality. Keep in mind though
that a value lower does not always shows that you have a problem.
A more pressing concern would be if we saw swaps on the system. As you
can see, there are no swaps.
Swapping occurs when the buffer is full, and the SAP System has to
load additional objects into the buffer. Objects in the buffer that
were used the least recently are removed. In this context, the term
"swap" means the objects removed from the buffer are lost and cannot
be replaced until a new database access is performed (replacing what
was lost).
There are two possible reasons for swapping
1 There is no space left in the buffer data area
The buffer is too small. You should increase the buffer size.
2 There are no directory entries left.
Therefore, to conclude, although the hitratio appears low it does
not mean that there are any performance issues. The fact that there is
sufficient free space and there are no swaps confirm this.
You can try to increase size of intial record buffer(in steps) as from current setting it seems to be small.
I hope this helps.
Regards,
Archana

Problem with the cache hit ratio

Hello,
I ma having a problem with the cache hit ratio I am geting. I am sure, 100% sure, that something has got to be wrong with the cache hit ratio I am fetching!
1) I will post the code that I am using to retrieve the cache hit ratio. I've seen about a thousand different equations, all equivalent in the end.
In oracle cache hit ratio seems to be:
cache hits / cache lookups,
where cache hits <=> logica IO - physical reads
cache lookups <=> logical IO
Now some people use the session logical Reads stat, from teh view v$sysstat; others use db block gets + db consistent gets; whatever. At the end of the day its all the same, and this is what i Use:
SELECT (P1.value + P2.value - P3.value) AS CACHE_HITS, (P1.value + P2.value) AS CACHE_LOOKUPS, P4.value AS MAX_BUFFS_SIZEB
FROM v$sysstat P1, v$sysstat P2, v$sysstat P3, V$PARAMETER P4
WHERE
P1.name = 'db block gets' AND
P2.name = 'consistent gets' AND
P3.name = 'physical reads' AND
P4.name = 'sga_max_size'
2) The problem:
The cache hit ratio I am retrieving cannot be correct. In this case i was benchamarking a HUGELY inneficient query, consisting of the Union of 5 Projections over the same source table, and Oracle is configured with a relatively small SGA of 300 MB. They query plan is awful, the database will read the source database table 5 times.
And I can see in the physical data statistics of the source tablespace, that total Bytes read is aproximatly 5 times the size of the text file that I used to bulk load data into the databse.
Some of the relevant stats, wait events:
db file scattered read     1129,93 seconds
Elapsed time: 1311,9 seconds
CPU time: 179,84
SGA max Size: 314572800 Bytes
And total bytes read: 77771964416 B (aproximatly 72 Gga bytes)
the source txt loaded to the database was aprox 16 G
Number of reads was like 4.5 times the source datafile.
I would say this, given the difference between CPU time and Elapsed Time, it is clear that the query spent almost all of its time doin DB file scattered reads. How is it possible that i get the following cache hit ratio:
Cache hit Ratio: 0,92
Cache hits: 109680186
Cache lookups: 119173819
I mean only 8% of that Logical I/O corresponded to physical I/O? It is just not possible.
3) Procedure of taking stats:
Now to retrieve these stats I snapshot the system 2 times. One before the query, one after the query.
But: this is not done in a single session. In total 3 sessions are created. One session two retrieve the stats before the query, one session to run the query, a last session to snapshot after the query.
Could the problem, assuming there is one, be related to this:
"The V$SESSTAT view contains statistics on a per-session basis and is only valid for the session currently connected. When a session disconnects all statistics for the session are updated in V$SYSSTAT. The values for the statistics are cleared until the next session uses them."
What does this paragraph mean. Does it mean that the v$sysstat only shows you the stats of the last session that closed? Or does it mean thtat v$sysstat is increamented with the statistics of each v$sessionstat once a session terminates? If so, then my procedure for gathering those stats should be correct.
Can anyone help me sort out the origin of such a high cache hit ratio, with so much I/O being done?

sono99 wrote:
Hi,s
first of, let me start by saying that there were many things in your post that you mentioned that I could no understand. 1. Because i am not an Oracle Expert, i use whatever RDBMS whenever i need to. 2. Because another problem has come up and, right now, i cannot inform myself to be able to comprehend it all.Well, could it be that you need to understand the database you are working on in order to comprehend it? That is why we strongly advise you to read the concepts manual first, you need to understand the architecture that Oracle uses, as well as the basic concepts of how oracle does locking and maintains read consistency. It does these different than other database engines, and some things become nonsense if looked at from the viewpoint of a single user.
>
quote:
It would be useful to see the execution plan jhust in case you have simplified the problem so much that a critical detail is missing.
First, the query code:
2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:>SQL> CREATE TABLE FAVFRIEND
[2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 2 NOLOGGING TABLESPACE TARGET
[2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 3 AS
[2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 4 SELECT ID as USRID, FAVF1 as FAVF FROM PROFILE
[2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 5 UNION ALL
[2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 6 SELECT ID as USRID, FAVF2 AS FAVF FROM PROFILE
[2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 7 UNION ALL
[2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 8 SELECT ID as USRID, FAVF3 AS FAVF FROM PROFILE
[2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 9 UNION ALL
[2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 10 SELECT ID as USRID, FAVF4 AS FAVF FROM PROFILE
[2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 11 UNION ALL
[2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 12 SELECT ID as USRID, FAVF5 AS FAVF FROM PROFILE
[2009-10-20 15:11:59,141 INFO]: OUTPUT_GOBLER:> 13 ;
Now, Althought it is clear from the query that the statement is executed with the NOLOGGiNG, i have disabled the logging entirely for the tablespace.There are certain rules about nologging that may not be obvious. Again, this derives from the basic Oracle architecture, and if you use the wrong definitions of things like logging, you will be led down the primrose path to confusion.
>
Futhermore, yes, the RDBMS is a test RDBMS... I have droped the database a few times... And I am constantly deleting an re-inserting data into the source database table named PROFILE.>
I also make sure do check all the datafile statistics, and for this query the amount of RedoLog, Undo "Log", Templife used is negligible, practically zero.Create table is DDL, which has implied commits before and afterwards. There is a lot going on, some of it dependent on the volume of data returned. The Oracle database writer writes things out when it feels like it, there are situations where it might just leave it in memory for a while. With nologging, Oracle may not care that you can't perform recovery if it is interrupted. So you might want to look into statspack or EM to tell you what is going on, the datafile statistics may not be all that informative for this case.
>
Most of the I/O is reading, a few of the I/O is writing.
My idea is not to optimize this query, it is to understand how it performs. Well, have you read the Concepts manual?
I have other implementations to test, namely I having trouble with one of them.
Furthermore, I doubt the query Plan Oracle is using actually involves tablescans (as I I'd like it to do); because in the Wait Events, most of the wait time for this query is spent doing "db file scattered read". And I think this is different from a tablescan.Please look up the definition of [db file scattered read|http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/instance_tune.htm#sthref703].
>
Do you really have to use sessions external to the query session ? Can you query v$mystat joined to v$statname from the session itself.
No, I don't want to that!
I avoid as much as possible having the code I execute being implemented in java. Why do you think java has anything to do with this? In your session, desc v$mystat and v$statname, these are views you can look at.
When i can avoid it I don't query the database directly through JDBC, i use the RDBMS command line client, which is supposed to be very robust. Er, is that sqlplus?
So yes, I only connect to the database with JDBC... in very last session.
Of course, I Could Have put both the gather stats before query and gathers stats after query a single script: the script that would be also runing the query.
But that would cause me a number of problems, namely some of the SQL i build has to be implemented dynamically. And I don't want to be replicating the snapshoting code into every query script I make. This way I have one sql with the snapshoting scripts; and multiple scripts for running each query. I avoid code replication in this manner.Instrumentation is a large subject; dynamic sql generation is something to be avoided if possible. Remember, Oracle is written with the idea that many people are going to be sharing code and the database, so it is optimized in that way. For SQL parsing in particular, if every SQL is different, you get a performance problem called "hard parsing." You can (and generally should, and sometimes can't avoid) use bind variables so that Oracle doesn't need to hard parse every SQL. In fact, this is one of those things that applies to other engines besides Oracle. I would recommend you read Tom Kyte's books, he explains what is going on in detail, including in some places the non-Oracle viewpoint.
>
Furthermore, Since the database is not a production database, it is there so I can do my tests. I don't have to be concerned with what other sessions may be doing to my system. There are only the sessions I control.No, there are sessions Oracle controls. If you are on unix, you can easily see this, but there are ways to see it on Windows, too. In some cases, your own sessions can affect themselves.
>
then what it the array fetch size ? If the array fetch size is large enough the number of block visits would be similar to the number of physical block reads.
I don't know what the arraysize you mention is. i have not touched that parameter. So whatever it is, it's the default.You should find out! You can go to http://tahiti.oracle.com and type array fetch size into the search box. You can also go to http://asktom.oracle.com and do the same thing, with some more interesting detail.
>
By the way, I don't get the query results into my client, the query results are dumped into a target output table.
So, if the arraysize has something to do with the number of rows that Oracle is returning the client in each step... I think it doesn't matter.You may hear this phrase a lot:
"It depends."
>
As for the query plan, If i am not mistaken you can't get get query plans for queries that are: create table as select.What?
JG@TTST> explain plan for create table jjj as select * from product_master;
Explained.
JG@TTST> select count(*) from plan_table;
COUNT(*)
         3
I can however commit the create table part and just call for the evalution of the Select part of the query; i believe it should be same.
"Optimizer"     "Cost"     "Cardinality"     "Bytes"     "Partition Start"     "Partition Stop"     "Partition Id"     "ACCESS PREDICATES"     "FILTER PREDICATES"
"SELECT STATEMENT"     "ALL_ROWS"     "2563"     "586110"     "15238860"     ""     ""     ""     ""     ""
"UNION-ALL"     ""     ""     ""     ""     ""     ""     ""     ""     ""
"TABLE ACCESS(FULL) SONO99.PROFILE"     ""     "512"     "117222"     "3047772"     ""     ""     ""     ""     ""
"TABLE ACCESS(FULL) SONO99.PROFILE"     ""     "513"     "117222"     "3047772"     ""     ""     ""     ""     ""
"TABLE ACCESS(FULL) SONO99.PROFILE"     ""     "513"     "117222"     "3047772"     ""     ""     ""     ""     ""
"TABLE ACCESS(FULL) SONO99.PROFILE"     ""     "513"     "117222"     "3047772"     ""     ""     ""     ""     ""
"TABLE ACCESS(FULL) SONO99.PROFILE"     ""     "513"     "117222"     "3047772"     ""     ""     ""     ""     ""
This query plan was taken from sql developer, exported to txt, and the PROFILE table here has only 100k tuples.
Right now I am more concerned with testing the MODEL query. Which Oracle doesn't seem to be able any more... but that is a matter for another thread.
Regarding this plan. The Union ALL seems to be more than just a binary Operator... IT seems to be Neray.
The union all on that execution plan seems to be taking as leaf tables 5 99sono.Profile tables, and be making a table scan to them all. So I'd say that the RDBMS should only scan each database block once and not 5 times.
But: It doesn't seem to be so. IT seems like what oracle is doing is scanning completly each the table, and then moving on to next select statement in the UNION ALL. Because given the amount of source table that was read, 5 times greater than the size of the source table. Oracle didn't reuse read blocks.
But this is just my feeling.Your feeling is uninteresting. Telling us what you really hope to accomplish might be more interesting.
Anyway, in terms of consistent gets, how many consistent gets should the RDBMS be doing? 5
One for each table block?It depends.
>
My best regards,
Nuno (99sono xp).

Oracle Buffer Utilisation is very low

Hi,
Below are the values of buffer cache. Can some body suggest how to improve the buffer hit ratio. For my database it is under 80%.
NAME TYPE VALUE
db_cache_size big integer 654311424
SQL> show parameter db_block_size
NAME TYPE VALUE
db_block_size integer 8192
Thanks
VAS

VAS wrote:
Hi,
Below are the values of buffer cache. Can some body suggest how to improve the buffer hit ratio. For my database it is under 80%. You don't say what an improvement would be, though it sounds like you want to raise it. The easiest way to achieve your stated goal would be to do a bunch of useless indexed work - handily http://www.oracledba.co.uk/tips/choose.htm will do this for you and you can have whatever hit ratio short of 100 you desire (assuming you've got some time to waste). Of course your actual goal may be to improve the performance of something or other rather than to do a bunch of useless work - the code on my link above won't help you there. For that you'll have to
1) define what it is you wish to improve in specific terms
2) define what acceptable improvement is
3) determine how you are going to measure the performance of the thing you are interested in
4) measure it
5) work out if it is unacceptable
6) work out why it isn't meeting your acceptability criteria
7) fix the major contributor
8) return to step 4
9) repeat until step 5 shows your performance is now acceptable.
of course this takes more effort than modifying some cache parameters or running a script from the intertubes, but it s more satisfying (unless you're paid a bonus based on your hit ratio in which case go for the script.
Niall Litchfield
http://www.orawin.info/

Default Buffer Pool Busy Waits and Default Buffer Pool Hit Ratio

Hi experts,
I am having oracle database with version 11gR2 on windows server 2003 platform.
I am continuously getting alerts related to "Default Buffer Pool Busy Waits" and "Default Buffer Pool Hit Ratio."
I have fired some of the queries(which contain view like v$session_wait) to get information of sessions that causing the same issue,but unable to get it.
Please help me to resolve the same issue.

Hi - Try this query for Buffer busy wait
COL class FORM a10
COL total_waits FORM 9,999,999,999
COL "WAITS %" FORM 9999999
COL time_waited FORM 9999999
COL "TIME %" FORM 9999999
COL event FORM a24
COL avg_wait FORM 9999.99
SELECT a.event event, substr(c.wait_class,1,9) class,
a.total_waits total_waits, a.time_waited/100 time_waited,
a.average_wait avg_wait
-- a.average_wait/100 avg_wait -- displays seconds instead of 100s
FROM v$system_event a, v$event_name b, v$system_wait_class c
WHERE a.event_id=b.event_id
AND b.wait_class#=c.wait_class#
AND a.time_waited/100 > 0
AND (event LIKE '%HW%' OR event = 'buffer busy waits')
-- AND c.wait_class in ('Application','Concurrency','User I/O')
ORDER BY 1 DESC;

Buffer cache hit ratio query

Hi,
I would appreciate some advice please.
My Oracle 10.2.0.4.0 database starts off in the day with a buffer cache hit ratio of almost 100% but this drops gradually in the course of the day as the system gets busier. Is this something I need to be concerned about if no performance problem has been reported by the users?
I would have thought this should be a normal situation, i.e. as the system gets busier, I would expect that less number of calls to the buffer cache will be satisfied because many more calls are using up the memory?
Please note that I've done some reading up on this but would like some suggestions from more experienced people than myself on what I should normally expect and what should or should not be a concern.
thanks

user8869798 wrote:
hi,
thanks again for your response and apologies for not being able to get back yesterday.No problem :) .
>
- What i am doing and how - it is the backend database r our Finance application, many users with various transactions.Okay , that sounds like a "normal" database with normal workload.
- configuring buffer cache size - I haven't done anything manually yet, it's all been as installed, this is what I'm trying to figure out whether it is something I should be looking into doing simply because of the dropping hit ratio and not because of any reported performance problem.If you don't have much of the knowledge, its the best to take use of the advisories which would tell you in a better and in a graphical way that whether you should or shouldn't be worries. Look at the view v$db_cache_advice which can suggest to you that whether you would need to tweak the buffer cache or not.
>
- looking at the queries - What is the easiest way of doing this in an environment where many users are running different queries? What's the easiest way to identify queries that we may need to have a closer look at?Easiest way? Well, let the users come back to you ;-) .
>
- Basically, I'm just trying to ascertain whether or not I need to be concerned that my hit ratio drops below 89% even though no performance problem has been reported. If it is something that I should look into, then what is the best way to go about it?
I believe that's answered by couple of us already, nope.
Aman....

Oracle Buffer Hit Ratio

Similar Messages

Maybe you are looking for