The v$osstat view shows certain OS-level metics such as number of CPUs, current system load, accumulated IO time, etc. Starting in 10gR2, it also records PHYSICAL_MEMORY_BYTES, which is the total size of physical memory on the server. See the documentation.
I think I found an anomaly. On one particular database I take care of (version 10.2.0.3 running on RedHat 4 64-bit), PHYSICAL_MEMORY_BYTES appears to be the amount of free memory available on the system, not total memory size like it says in the docs.
On that system, if I run the following two commands from within sqlplus —
SQL> ho cat /proc/meminfo |grep ^MemFree |tr -s ' ' |cut -d' ' -f2 SQL> select value from v$osstat where stat_name='PHYSICAL_MEMORY_BYTES';
…the results are really, really close. Less than a few dozen bytes apart. This leads me to believe that on this particular database, v$osstat is getting its value for PHYSICAL_MEMORY_BYTES from free memory, not from total memory.
DBA_HIST_OSSTAT tracks this value over time. It should not change unless you are changing the amount of installed memory on your server. But here is how PHYSICAL_MEMORY_BYTES changes on my RHEL4 64-bit 10.2.0.3 system:
select * from (
select snap_id, value
, value-lag(value) over(order by snap_id) delta
from dba_hist_osstat
where stat_name='PHYSICAL_MEMORY_BYTES'
order by snap_id
) where rownum <= 50
/
SNAP_ID VALUE DELTA
---------- ---------- ----------
28389 2220048
28390 2171328 -48720
28391 1938152 -233176
28392 2131860 193708
28393 2123272 -8588
28394 2097128 -26144
28395 2070008 -27120
28396 2068092 -1916
28397 2076164 8072
28398 2059132 -17032
28399 2045440 -13692
28400 2037288 -8152
...
A 10.2.0.4 database installed on identical hardware/OS reports no change in PHYSICAL_MEMORY_BYTES:
SNAP_ID VALUE DELTA
---------- ---------- ----------
29125 8359936000
29126 8359936000 0
29127 8359936000 0
29128 8359936000 0
29129 8359936000 0
29130 8359936000 0
29131 8359936000 0
29132 8359936000 0
29133 8359936000 0
…so I am tempted to suppose that this is a 10gR2 bug that was fixed in 10.2.0.4. However, I checked on a 10.2.0.2 database running on Windows, and there is no anomaly:
SNAP_ID VALUE DELTA
--------- ---------- ----------
43747 4093104128
43748 4093104128 0
43749 4093104128 0
43750 4093104128 0
43751 4093104128 0
43752 4093104128 0
43753 4093104128 0
43754 4093104128 0
43755 4093104128 0
43756 4093104128 0
43757 4093104128 0
It appears that this is either a Linux-specific bug that was fixed in 10.2.0.4, or perhaps a bug that only occurs in 10.2.0.3 (I don’t have a 10.2.0.3 database running on Windows to test this out on). However, I could find no mention of this as a bug on Metalink.