I sent a message last week regarding our values in the v$sysstat table being WAY too
large;
physical_reads = 18,446,744,069,434,437,169
db_block_gets, physical_reads_direct, physical_writes_direct also.
This prevents us from running the db cache hit ratio queries.
I logged a tar with Oracle and they said it was a bug (#1713403). It is caused by an
overflow in v$sysstat when the amount of generated redo grows over 2GB. They say this
bug can't be fixed (at least not until 10i!). I am running on 8.1.7 (HP-UX11).
If you are on 8i, could you query the v$sysstat table and let me know if anyone else
is seeing this problem?
col name for a20
col value for 999,999,999,999,999,999,999
select name,value from v$sysstat
where name in ('redo size', 'physical reads', 'db block gets')
/
NAME VALUE
-------------------- ----------------------------
db block gets 18,446,743,996,920,309,855
physical reads 18,446,744,052,688,746,229
redo size 17,049,609,736
I find it unacceptable that Oracle would ignore this until 10i. The only time I can
get a cache hit ratio is when I first start up the database (which doesn't mean
anything). I know hit ratios are overrated and we look at waits more for performance
tuning (read all the articles), but it is still frustrating nonetheless.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Glenn Travis
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
