Buffer Cache hit ratio low (40.42%)

Can someone help me with a good guide or advice in order to increase my Buffer Cache hit ratio? If I am not wrong databases should have +85% hit ratio for a good performance.
thanks

Here is a script that will bump up your BCHR
http://www.oracledba.co.uk/tips/choose.htm
I think you understood from that you shouldn't worry about your bchr but better focus on your real problems i.e. parts of your app that run slowly and people are expecting quicker resposnse.
Gints Plivna
http://www.gplivna.eu

Similar Messages

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....

Buffer Cache hit Ratio

Hi All,
My DB Version: 10.2.0
OS: Windows Server 2003
I run the following script to get Hit ratio's
SELECT cur.inst_id, 'Buffer Cache Hit Ratio ' "Ratio", to_char(ROUND((1-(phy.value / (cur.value + con.value)))*100,2)) "Value"
FROM gv$sysstat cur, gv$sysstat con, gv$sysstat phy
WHERE cur.name = 'db block gets'
AND con.name = 'consistent gets'
AND phy.name = 'physical reads'
and phy.inst_id=1
and cur.inst_id=1
and con.inst_id=1
union all
SELECT cur.inst_id,'Buffer Cache Hit Ratio ' "Ratio", to_char(ROUND((1-(phy.value / (cur.value + con.value)))*100,2)) "Buffer Cache Hit Ratio"
FROM gv$sysstat cur, gv$sysstat con, gv$sysstat phy
WHERE cur.name = 'db block gets'
AND con.name = 'consistent gets'
AND phy.name = 'physical reads'
and phy.inst_id=2
and cur.inst_id=2
and con.inst_id=2
union
SELECT inst_id, 'Library Cache Hit Ratio ' "Ratio", to_char(Round(sum(pins) / (sum(pins)+sum(reloads)) * 100,2)) "Library Cache Hit Ratio"
FROM gv$librarycache group by inst_id
union
SELECT inst_id,'Dictionary Cache Hit Ratio ' "Ratio", to_char(ROUND ((1 - (SUM (getmisses) / SUM (gets))) * 100, 2)) "Percentage"
FROM gv$rowcache group by inst_id
union
Select inst_id, 'Get Hit Ratio ' "Ratio",to_char(round((sum(GETHITRATIO))*100,2)) "Get Hit"--, round((sum(PINHITRATIO))*100,2)"Pin Hit"
FROM GV$librarycache
where namespace in ('SQL AREA')
group by inst_id
union
Select inst_id, 'Pin Hit Ratio ' "Ratio", to_char(round((sum(PINHITRATIO))*100,2))"Pin Hit"
FROM GV$librarycache
where namespace in ('SQL AREA')
group by inst_id
union
select a.inst_id,'Soft-Parse Ratio ' "Ratio", to_char(round(100 * ((a.value - b.value) / a.value ),2)) "Soft-Parse Ratio"
from (select inst_id,value from gv$sysstat where name like 'parse count (total)') a,
(select inst_id, value from gv$sysstat where name like 'parse count (hard)') b
where a.inst_id = b.inst_id
union
select a.inst_id,'Execute Parse Ratio ' "Ratio", to_char(round(100 - ((a.value / b.value)* 100),2)) "Execute Parse Ratio"
from (Select inst_id, value from gv$sysstat where name like 'parse count (total)') a,
(select inst_id, value from gv$sysstat where name like 'execute count') b
where a.inst_id = b.inst_id
union
select a.inst_id,'Parse CPU to Elapsed Ratio ' "Ratio", to_char(round((a.value / b.value)* 100,2)) "Parse CPU to Elapsed Ratio"
from (Select inst_id, value from gv$sysstat where name like 'parse time cpu') a,
(select inst_id, value from gv$sysstat where name like 'parse time elapsed') b
where a.inst_id = b.inst_id
union
Select a.inst_id,'Chained Row Ratio ' "Ratio", to_char(round((a.val/b.val)*100,2)) "Chained Row Ratio"
from (SELECT inst_id, SUM(value) val FROM gV$SYSSTAT WHERE name = 'table fetch continued row' group by inst_id) a,
(SELECT inst_id, SUM(value) val FROM gV$SYSSTAT WHERE name IN ('table scan rows gotten', 'table fetch by rowid') group by inst_id) b
where a.inst_id = b.inst_id
union
Select inst_id,'Latch Hit Ratio ' "Ratio", to_char(round(((sum(gets) - sum(misses))/sum(gets))*100,2)) "Latch Hit Ratio"
from gv$latch
group by inst_id
/* Available from 10g
union
select inst_id, metric_name, to_char(value)
from gv$sysmetric
where metric_name in ( 'Database Wait Time Ratio', 'Database CPU Time Ratio')
and intsize_csec = (select max(intsize_csec) from gv$sysmetric)
order by inst_id
What i am getting after this is:
INST_ID Ratio Value
1 Buffer Cache Hit Ratio .83
1 Chained Row Ratio 0
1 Dictionary Cache Hit Ratio 77.5
1 Execute Parse Ratio 45.32
1 Get Hit Ratio 75.88
1 Latch Hit Ratio 100
1 Library Cache Hit Ratio 99.52
1 Parse CPU to Elapsed Ratio 24.35
1 Pin Hit Ratio 95.24
1 Soft-Parse Ratio 89.73
i have a doubt with buffer cache hit ratio, can anyone please help me to understand this

Buffer Cache Hit Ratio .83Quite weird value. It seems your system is doing all physical reads, which seems unrealistic.
I had a 10.2.0.1 database where i saw this kind of result for cache hit ratio and after patching it to 10.2.0.4, it started showing results correctly.
Probably it could be some Oracle 10g bug which made this odd display of hit ratio information in data dictionary. Can you try patching your database to latest 10g PSU, or contact Oracle support for a one-off patch for this problem
Salman

Buffer Cache Hit ratio 48

just now I have checked the buffer cache hit ratio is 48% . In my production database . is It any problem.
Thank You
Prasad

Maybe, maybe not.
You might want to post your question into a more appropriate forum : General Database Discussions
Nicolas.

Manual calculation of 'Buffer Cache hit ratio'

Using: Oracle 10.2.0.1.0, Redhat 4, 64bit.
Manual calculation of ‘Buffer Cache hit ratio’ is very off from what it shown in statspack.
Statspack shows:
Instance Efficiency Percentages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %: 100.00       Redo NoWait %:   99.97
            Buffer Hit   %:   99.18    In-memory Sort %: 100.00
            Library Hit   %:   90.43        Soft Parse %:   52.56
         Execute to Parse %:   80.14         Latch Hit %:   99.98
Parse CPU to Parse Elapsd %:   96.21     % Non-Parse CPU:   56.89
Manual calculation (Got this formula from Sybex PT book, page 275):
SQL> select name, 1-(PHYSICAL_READS/(DB_BLOCK_GETS+CONSISTENT_GETS))
from v$buffer_pool_statistics;
NAME                 1-(PHYSICAL_READS/(DB_BLOCK_GETS+CONSISTENT_GETS))
DEFAULT                                                      .700247215Any idea, why using v$buffer_pool_statistics gives wrong results?
Thanks regards,

SYS@oradocms11> select (P1.value + P2.value - P3.value)/(P1.value + P2.value)*100
2 from v$sysstat P1, v$sysstat P2, v$sysstat P3
3 where P1.name = 'db block gets'
4 and P2.name = 'consistent gets'
5 and P3.name = 'physical reads';
(P1.VALUE+P2.VALUE-P3.VALUE)/(P1.VALUE+P2.VALUE)*100
99.6977839
SYS@oradocms11> select name, 1 - (PHYSICAL_READS/(DB_BLOCK_GETS+CONSISTENT_GETS)) from v$buffer_pool_statistics
NAME 1-(PHYSICAL_READS/(DB_BLOCK_GETS+CONSISTENT_GETS))
DEFAULT .997009542
In my case, both are giving almost same result.

How to tune effectively to the buffer cache hit ratio?

We have a database with following sga sizes;
shared pool : 256 MB
Buffer Cache: 880 MB
Large pool: 32 MB
Java pool: 32 MB
Total SGA: 1201.435 mb. From the health check, i found Buffer Cache Hit Ratio is giving the trouble. so, i need advice from dba gurus, should Buffer Cache Hit ratio be increase or decreasee, in order to improve the performance?
Please help me
Ateeq

I will generate statspack tommorrow morning when there will be lot of activity on the database. In the meantime, some output from Health check toad are:
->!Buffer Cache Hit Ratio : 82.3246
-->[Segments with > 100 extents] Exec Time 1 seconds
! TABLE IN_CHIYODA.SPEC_REVISION_DOCUMENT_MAIN: 107 Extents
! TABLE EF2_DATA.N3RGRPRGRP: 126 Extents
! TABLE EF2_DATA.N3OBJATTR: 192 Extents
! TABLE EF2_DATA.EFT_UID: 119 Extents
! TABLE EF2_DATA.N2FILEOBJ: 121 Extents
! TABLE EF2_DATA.N2IFOBJ: 211 Extents
! TABLE EF2_DATA.N2REVGRP: 128 Extents
! INDEX EF2_DATA.N3OBJATTR_RLTLEFTRELINDEX: 122 Extents
! INDEX EF2_DATA.N3OBJATTR_RLTRIGHTRELINDEX: 114 Extents
! INDEX EF2_DATA.PK_N3OBJATTR: 119 Extents
! INDEX EF2_DATA.EFI_UID_N1UID: 120 Extents
! INDEX EF2_DATA.EFI_UID_N1OBJOBID: 103 Extents
! INDEX EF2_DATA.N1BOBJOBID_N2IFOBJ: 186 Extents
! INDEX EF2_DATA.N2IFOBJ_N1BOBJOBID: 159 Extents
! INDEX EF2_DATA.N2IFOBJ_N1NAME: 115 Extents
! INDEX EF2_DATA.PK_N2IFOBJ: 158 Extents
! INDEX EF2_DATA.N2IFOBJ_MYINDEX: 187 Extents
Can you advice anthing based on these results.
Thanks

RAC - buffer cache hit ratio

Hi, I'm a newbie to the forums, so please bear with me.
I am trying to determine if the usual buffer cache hit ratio figures are irrelevant when used on a RAC environment, because of Cache Fusion and the blocks being moves between the SGA's of the instance?

Buffer cache hit ratios are always relevant (but not necessarily an indicator of performance).
Wether it is coming in by cache fusion or a direct read from a datafile, you are still moving a datablock into the cache or reading from the cache.

Database buffer cache hit ratio is less that 90%

Hi All,
For the following query i get result less than 90%
SELECT ROUND(((1 -(phy.VALUE /(cur.VALUE con.VALUE)))*100),2) "HIT RATIO"+
FROM SYS.v_$sysstat cur,
SYS.v_$sysstat con,
SYS.v_$sysstat phy
WHERE cur.NAME = 'db block gets'
AND con.NAME = 'consistent gets'
AND phy.NAME = 'physical reads' ;
HIT RATIO
+81.79+
Please advice me what may be the reasons and how can i make it more than 90%.
I have metalink access. Can i raise this issue with Oracle metalink?
Thanks and regards,
Arun Kumar

user8853422 wrote:
Thnaks for the reply..
I have noticed for the another database it is 23.29.
But i did not get any complaints from application side yet.
It's laudable that you want to be proactive and fix the database before people complain, but I'll second what the others said, targetting a specific hit ratio is useless for that.
Who told you to run that hit ratio script? There are a number of reasonable methodologies to determine if there might be problems, but that isn't one of them. Waiting for users to complain may or may not work, some users simply accept poor performance, thinking that's just the way it is.
What are you really trying to accomplish?

Tivolo storage manager error message is Database Cache Hit Ratio is too low

Hi basis friends,we are performing incremental backup from mon-fri.from past two days i was getting error message as 'data base cache hit ratio is too low (97.3,98)and increase buffer pool size value.what is the problem for this error message? how can i overcome this error? give me detail analysis to the issue please.
Thanks and regards,
Nani

Hello Nani,
The database buffer cache hit ratio is the proportion of Oracle logical reads that do not require operating system (OS) read calls.
When an Oracle session accesses a block, Oracle executes an instruction path that determines whether or not that block is already in the database buffer cache. We refer to this instruction path as an Oracle logical I/O call.. If the block is not in the buffer cache, then Oracle will execute an OS read call. We refer to this as a physical I/O call.It must be ideally close to 99% and since in your case it is low,that is why you are getting these errors
Now to increase this you will have to increase the vakue of shortbuffer pool size as suggested by Tivolii.
Fo that you wil have to increase the value of parameter DB_CACHE_SIZE if you are using Oracle 9i.
Go through the following link http://download.oracle.com/docs/cd/B13789_01/server.101/b10752/memory.htm
which will help you understand the concept better
Hipe it helps
Rohit

Cache hit ratio - index sql statement

I am reading the note 33833.1 on Metalink web site. I have diffult to understand the part in the last page of the note. In the last page author talk of a situation where the cache hit ratio is near 100% but the system is not good because. the author talk of a bad sql statement using a non selective index.
Anyone can explain me this situation ?
thanks for all

Because it can be spoofed easily, cache hit ration should never be used as an indicator of system performance. I could not find the article you refered to I can explain it this way:
Repeatedly hitting the same large amount of datablocks to return a small amount of data will show an artificially high buffer cache hit ratio because the same block get hit over and over, even though most of the data in them is irrelavent.
Another example would be using subquries instead of joins or joins on inline views.
All that being said, a low buffer cache hit ratio over an extended period of time is an indicator that the cache is too small, however a high buffer cache hit ration does not mean that is the right size.
(it's Monday, I hope this makes sense.)

Buffer Cache Hit

Hello !
I am relativelly new to DBA so I have some doubts. I have read that the a high Buffer Cache Hit ratio means that the DB does not have to do so many reads on the disk. I am now checking our production db every day (a third part company istalled EBS and now they have left). The Buffer Cache Hit ratio is always (in the time people are working) on 100% or a bit under (99, 98...). It is ok for the buffer cache to be above 90% but it is also really ok for it to be almoust all the time on 100%? We have a 9.2.0.6 on Win2003 DB, the hit ratio % was read from EM, in SQLPlus:
SQL> select 1-(sum(decode(name,'physical reads',value,0))/
2 (sum(decode(name,'db block gets',value,0)) +
3 (sum(decode(name,'consistent gets',value,0))))) "Hit Ratio"
4 from v$sysstat;
Hit Ratio
,996897321
Is this ok?
Thanks for advices.

I calculate the physical_reads_per_hour and tune to reduce this by increasing the buffer cache, adding indexes and archiving old rows.
To see the physical reads per hour, use:
select
host_name,instance_name,(round((sysdate-i.startup_time)*100))/100 updays,
SUM(DECODE(Name, 'consistent gets',Value,0)) consistent,
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,2)
BlkHit,
round(SUM(DECODE(Name, 'physical reads',Value,0))/to_number(sysdate-i.startup_time)/24) Physrds_per_hour,
SUM(DECODE(Name, 'consistent gets',Value,0))/to_number(sysdate-i.startup_time)/24 Con_per_hour,
SUM(DECODE(Name, 'db block gets',Value,0)) Dbblock,
SUM(DECODE(Name, 'db block gets',Value,0))/to_number(sysdate-i.startup_time)/24 Dbblock_per_hour,
SUM(DECODE(Name, 'physical reads',Value,0)) Physrds
from V$SYSSTAT,v$instance i
group by host_name,instance_name,(sysdate-i.startup_time)
To see what is taking memory, look for large tables in memory and add indexes:
set pages 30
set heading on
COLUMN OBJECT_in_memory FORMAT A40
COLUMN NUMBER_OF_BLOCKS FORMAT 999,999,999,999
column meg_in_memory format 9999999999
SELECT COUNT(*)*8192/1024/1024 meg_in_memory,
o.object_type,o.OBJECT_NAME Object_in_Memory
FROM DBA_OBJECTS o, V$BH bh
WHERE o.DATA_OBJECT_ID = bh.OBJD
AND o.OWNER != 'SYS'
and o.object_name like upper('%&object_name%')
GROUP BY o.OBJECT_NAME,o.object_type
having count(*)>0
ORDER BY COUNT(*);
To see what is taking I/O:
COLUMN OBJECT_in_memory FORMAT A40
COLUMN NUMBER_OF_BLOCKS FORMAT 999,999,999,999
column buffers_read_into_memory format 9999999999
set termout off
drop table alan9;
drop table alan10;
create table alan9 nologging as
select OBJD,FILE#,BLOCK# from v$bh;
create table alan10 nologging as
select OBJD,FILE#,BLOCK# from v$bh
minus
select OBJD,FILE#,BLOCK# from alan9;
set termout on
SELECT COUNT(*) buffers_read_into_memory,
o.OBJECT_NAME Object_in_Memory
FROM DBA_OBJECTS o, alan10 bh
WHERE o.DATA_OBJECT_ID = bh.OBJD
AND o.OWNER != 'SYS'
GROUP BY o.OBJECT_NAME
having count(*)>0
ORDER BY COUNT(*);
set termout off
drop table alan9;
drop table alan10;
set termout on

Cache hit ratio

What is the difference between these two queries??
which is the cache hit ratio???
SELECT sum(gets) "GETS",
sum(getmisses) "MISSES",
(100*(sum(getmisses)/sum(gets))) "RATIO%"
FROM v$rowcache;
Result:
GETS MISSES RATIO%
366606 19906 5.42980747723714287272985166636661702209
SELECT ROUND((1-(phy.value / (cur.value + con.value)))*100,2) "Cache Hit Ratio"
FROM v$sysstat cur, v$sysstat con, v$sysstat phy
WHERE cur.name = 'db block gets'
AND con.name = 'consistent gets'
AND phy.name = 'physical reads';
Result:
Cache Hit Ratio
98.47

You do NOT need to increase DB_BLOCK_CACHE.
Partly that's because it's DB_CACHE_SIZE, but that's a side issue.
It's not a "valid approach" either.
These things aren't down to "personal preference". If you do care about the hit ratio, you are wasting your time, sadly misguided, technically misdirected and have bought into one of the longest-running myths about Oracle that exists.
Those are facts, not mere words.
Jonathan Lewis, Tom Kyte, Me, Richard Foote, Anjo Kolk, Cary Milsap, Connor McDonald, Kevin Closson... you will not find a technically competent "Oracle expert" on this planet that thinks the buffer cache hit ratio is worth two beans as a measure of anything. Any one of those people can, if they have a mind to, explain for the thousandth time WHY this is so, but quite frankly, they probably have better things to do with their time because the issue has been done to death, over and over and over for years on end.
You can read the latest discussion of it here, if you like:
http://groups.google.com.au/group/comp.databases.oracle.server/browse_thread/thread/1a946dbe8dcfa71e/47793b44134e60d6?hl=en#47793b44134e60d6
It's interminable and silly, but the main "clear arguments" are nevertheless put across quite clearly by a number of people, myself included.
All I'll do here is remind you that if you have insufficient undo tablespace, you will be re-using the same undo blocks over and over again. That will mean lots of logical reads in the buffer cache, and your hit ratio will rise accordingly. That will result in a "good" ratio, according to you... but it will actually be a symptom of an insufficiently-sized undo tablespace.
When a tool can't distinguish between "good" things and "bad" but registers the same measurement in both scenarios then, as a matter of plain common sense, that tool is useless.
The buffer cache hit ratio is likewise worthless as a measure of anything other than "something is going on in the database but I can't tell you what".

Cache hit ratio at enterprise manager

hit ratio formula is:
(logical_reads - physical_reads/logical_reads )*100
Now, if I open Oracle Enterprise Manager and goes to Instance->Configuration->Memory I can see SGA and PGA configuration. I can also see the cache hit ratio, in my case 35%, but it seems that this is not the formula I mentioned above, because when I execute that formula i get 75% hit ratio:
SELECT 1 -(phy.value / (cur.value + con.value)) "CACHE HIT RATIO"
FROM v$sysstat cur, v$sysstat con, v$sysstat phy
WHERE cur.name = 'db block gets'
AND con.name = 'consistent gets'
AND phy.name = 'physical reads';
CACHE HIT RATIO
,749500702
So my question is, what is that hit ratio at Oracle Enterprise Manager?

Hi Elidas,
what is that hit ratio at Oracle Enterprise Manager? Thet don't publish their formula, but you can log an SR and ask.
By itself, the buffer cache hit ratio is not very meaningful, and the data buffer cache hit ratio is largely meaningless for decision support and data warehouse applications because of their propensity to have full-table scans and parallel full-table scans (which may bypass the data buffers entirely, using PGA memory).
The buffer cache hit ratio is most meaningful for databases with an undersized db_cache_size, where the "working set" of frequently-referenced data has not been cached. Oracle provides the data buffer cache advisory utility (v$db_cache_advice) in the standard AWR report. (and later releases of STATSPACK reports). Oracle has expanded the advisory utilities to include a shared pool, Java and PGA advisory.
Here are my notes:
http://www.dba-oracle.com/m_buffer_cache_hit_ratio.htm
Hope this helps. . .
Donald K. Burleson
Oracle Press author

Buffer cache hit ration found 99.7%,still the app users complains.

Here in my database,i querey the v$sysstat and found the buffer cache hit ration 99.7% ,by looking that hit ration there is room improvements.
what are the other things which can examine here ?
hare krishna
Alok

As others have said, buffer cache hit ratio is only one of the measurements - and it is often improperly applied, making it worse than useless.
Since this is in production,. it's too late to do anything about the design. So we skip that very important step and go to the SQL statements ...
What are the users complaining about, in detail? Is it the system, or is it a specific operation? Use that knowledge to attempt to define a single SQL statement or a small set of SQL statements, and then start tuning those.
The other possibility, seen A LOT these days, is that the app was written in Visual Basic, .Net or Java and uses the "build the statement on the fly and execute immediate" method. In that case, your server is probably sitting at very high CPU useage and your shared pool is used very inefficiently. Use the V$PGA_TARGET_ADVICE and V$SHARED_POOL_ADVICE views (described in the Administrator's manual and the Performance Tuning manual) to adjust these memory segments properly. All youi can do is alleviate the result of bad development.
And finally, you may simply have gone into swapping or paging, the evil that occurs when you attempt to a) put multiple instances on a server, or b) put the instance and the application background tasks on the same server, or c) do not use PGA_AGGREGATE_TARGET properly.

Low database cache hit ratio (85%)

Hi Guys,
I understand that high db cache hit ratio doesn't indicates that the database is healthy.
The database might be doing additional "physical" reads due to un-tuned SQL.
However, can explain why a low cache hit ratio might not indicate the db is unhealthy, as in the db need additional memory allocated?
What i can think of is probably:
1. the database might query different data most of the time. As such the data is not read again from cache before it aged out. Even if i add additional memory, the data might not be read again (from memory).
2. ?
3. ?
I'm quite reluctant to list out the databases with below 90% hit ratio as part of the monthly report to the management. To them, below 90% means unhealthy.
If these ratios to be used in monthly report, there will be a long section to explain why these ratios cannot meet but there is no performance concern.
As such will need your expert advise on this.
thanks
Edited by: Chewy on Mar 13, 2012 1:23 AM

Nikolay Savvinov wrote:
In isolation, ratios are useless, but trends in ratios can point to potential problem. If your BCHR is steadily degrading over time, this is something to worry about (you'll have to examine your application for scalability issues)
I used to think that there was a case for trending through a ratio in the days when databases were small, simple and (by modern standards) not very busy. But I'm no longer sure it was even a good idea then. How much of a change do you need to see before you start worrying - and what time-granularity would you take as your baseline. When a ratio varies between 98% and 99% during daylight hours, how do you spot a very large problem that's only going make a change of 0.01% over the course of a couple of weeks ?
I really don't think there's any good SIMPLE way of producing a management sound-bite for every database in the system; each database needs a personal touch, and the number of figures you need to supply on each is not going to be easy to grasp without some graphic assistance. A suggestion I have is simply to pick three "representative" queries from the application (one "small", one "medium" and one "large") and run them once every hour, capturing the plan_hash_value, elapsed time, disk-reads, buffer gets, and CPU for each. A daily graph - 4 lines each - of each query will give management the big picture of variation in response time; a longer term graph based on the daily average with (say) best and worst excluded will give a trend warning. Obvously each database (or even application within database) needs its own three queries, and there may be periods during the day when it is not relevant to worry about a particular query.
(NB In the past I've run baseline queries from a pl/sql package called by dbms_job, or dbms_scheduler, and stored the resulting cost figures in the database - capturing all the session stats, wait event and time model information)
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Author: <b><em>Oracle Core</em></b>

Buffer Cache hit ratio low (40.42%)

Similar Messages

Maybe you are looking for