Cache hit ratio

Question

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

Answer 1

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