Sam asks about trusting v$sysstat vs. v$buffer_pool_statistics. My experience is that v$sysstat is more reliable, at least in Oracle 10g. I don't know if the issue is resolved in 11g.

It appears that the columns in v$buffer_pool_statistics are stored as 31-bit
integers, and will wrap around and become useless in a high volume
environment.

Here are two queries against v$buffer_pool_statistics, one minute apart, in a
high-volume production environment:

15:39:39
Physical Reads Block Gets Consistent Gets Buffer Cache Ratio
---------------- ---------------- ---------------- ------------------
35,861,830,327 49,043,612,339 40,462,164,249 .599

15:40:39
Physical Reads Block Gets Consistent Gets Buffer Cache Ratio
---------------- ---------------- ---------------- ------------------
35,862,926,655 49,043,761,695 40,468,697,761 .599

The queries say the hit ratio (1-(physical reads/(block gets + consistent
gets))) is 59%. However, if you take the differences between the two
measurements, and compute the ratio, you get 83%, which agrees with the v
$sysstat numbers for this instance.

Notice how consistent gets climbed by 8 million during the minute, while
block gets climbed by 150,000. Yet the consistent gets values are lower than
the block get values. My best guess is that these counters have wrapped
around many times.

One more caution: when you start up an instance, all gets will require
physical reads. The hit ratio will be 0% at first, then slowly climb to a
useful value. So these statistics are meaningless unless a lot of data has
moved through the buffer pool.
-tdc