> 2 CPU, 2GB, Windows 2003, Oracle 8.1.7.4, SGA is 1.2 G, only 80M RAM is used. 
> The rest is Virtual Memory. 1.5 GB RAM is unused. Is it normal? I use Windows 
> Task Manager, in Process page, I select column 'Virtual Memory Size' from
> menu view-->select colomns...

According to David Solomon's "Inside Windows NT", Task Manager Virtual Memory 
Size is virtual memory of private memory only. I.e., the real virtual memory of 
a process including its shared memory is actually larger than the number under 
VM Size column of Task Manager. The number under Mem Usage is working set and 
it has to be in RAM. In fact the top command in Windows Services for UNIX, a 
product Microsoft bought from Interix, reports that as RSS (resident set size).

So I believe what you observed is quite true. I just did a test using Oracle 
10.1.0.2.0 on Windows XP. My show sga shows:

Total System Global Area  150994944 bytes
Fixed Size                   787908 bytes
Variable Size              66058812 bytes
Database Buffers           83886080 bytes
Redo Buffers                 262144 bytes

Mem Usage in Task Manager is 106M and VM Size is 194M. Then I set lock_sga=true 
and restart the database. Mem Usage is 185M now. VM Size doesn't change. (Note
that "Mem Usage" in Task Manager is working set size while "VM Size" is
private memory portion of virtual memory.)

So lock_sga does seem to be supported on Windows at least for 10g. The reason Oracle doesn't 
enable it by default as done on Solaris (enabled implicitly there) is probably 
because Windows memory locking does not really lock memory. According to 
Jeffrey Richter's "Advanced Windows", under memory pressure, locked memory 
could still be paged out when the thread is not running (see p.218).

Try setting lock_sga and post back your finding.

Yong Huang

--------------------------------------------------------------------------------

>   I set lock_sga = true, and when starting database, get ora-27102: out of
>   memory error. My sga:
>   Total System Global Area 896563228 bytes
>   Fixed Size 75804 bytes
>   Variable Size 224866304 bytes
>   Database Buffers 671088640 bytes
>   Redo Buffers 532480 bytes

Metalink Note:274092.1 says the workaround for Oracle 9.2 is add the key
ORA_WORKINGSETMIN = 2 under HKLM\SOFTWARE\ORACLE\HOME in registry. According
to Note:46001.1, that registry value determines the minimum working set in MB.
It looks strange that setting it to 2MB would solve the problem. I would
expect the number to be much larger.

My previous message says I tested with lock_sga and it works. I was using 10g.
This problem exists before 10g.

Please try the registry workaround and post back. (It should be ORA_... not
ORA__... as in the article. Only 1 underscore)

ALSO SEE
http://yong321.freeshell.org/computer/orawintrace.html#lock_sga

--------------------------------------------------------------------------------

sga_max_size

Oracle allocates all memory specified by sga_max_size on startup. Here's something 
everybody working on Windows should understand about a Windows process:

Virtual memory is measured by perfmon virtual bytes;
Working set (resident set) part of virtual memory is Mem Usage in Task Manager (TM);
Private part of virtual memory is VM Size in Task Manager.

Process virtual memory can be split into working set and non-working set (the part 
paged out). TM Mem Usage measures the first part only. Alternatively, virtual memory 
can also be split into private memory and shared memory. TM VM Size measures the 
first part only.

catan's problem is due to incomplete measurement. He's probably looking at Mem Usage which hasn't reached its normal workload level yet. The only reliable way is to use perfmon, and look at oracle.exe process's virtual bytes or use Process Explorer to look at virtual size.

I'll be surprised if Oracle decides to allocate less than sga_max_size virtual memory for oracle.exe on instance startup. On UNIX/Linux, that might be true if you turned off _use_ism; even then I doubt it but we can verify. On Windows, _use_ism is unlikely to have any effect at all.