Re: Oracle 8.1.7 on W2K Adv. Svr with 8gb RAM - use AWE

Chuckster <chuckycarson_at_networkcloud.com> wrote in message news:<3DD3D3BA.2050706_at_networkcloud.com>...
> I keep hearing all this talk about W2K Advanced Server using more than
> 2GB memory. How? We are running Oracle 8.1.7.3.2 on W2K Advanced Server
> SP2 with 8gb memory, we are unable to utilize more than 1.7GB for the SGA.

these questions and more are addressed in the following book:

Oracle9i for Windows(R) 2000 Tips &: Techniques Scott Jesse Matthew Hart Michael Sale

Format: Paperback, 637pp.
ISBN: 0072194626
Publisher: McGraw-Hill Companies, The
Pub. Date: December 2001  

my copy is at the office - so I can't site it directly, but from memory:

in addition to the /3GB switch in the boot.ini, you can add the switch /PAE PAE = physical address extensions

if your CPU permits it (PII, PII, PIV, Xeon MP). This allows for db_block_buffers to be held in memory above 4 GB. As this memory is addressed indirectly, there is additional overhead involved.
(this is also supported in the Linux Kernel, I believe).

I have not yet attempted storing data block buffers in memory above 4 GB.
I do have access to a box w/MS W2K Adv. Server with 6 GB of memory and could test such functionality during a scheduled downtime period, as it houses 3 databases currently, and I'd have to shutdown the instances to make memory available.

The Dell Refurbished Site (outlet) rocks.

Back to your first question - can you use more than 2 GB of memory (for a single instance)?

Yes.
- the SGA can be up to 3 GB.
- db_block_buffers can be stored in physical memory above 4 GB both of these switches require that at least the advanced server edition of MS W2K Server be installed.

in regard to your second question - more memory used with dedicated ot shared server connections?

It depends.
if you use the same parameter settings for sort_area_size
hash_area_size
shared_pool
large_pool

then the only thing that would change would be the number of server processes (or threads) that would occupy memory in the PGA. shared server processes would *likely* mean fewer server processes, but scenarios such as a large number of min shared servers where this number is actually larger than the number of dedicated connections ... (misconfiguration).
you will likely need to increase the size of the large pool in order to keep sorts from using memory in the shared pool. (v$sysstat is good for a quick look to see if you have free memory in the large pool).

so if the memory used number of dedicated connections is larger than the amount of memory used by the shared server connections + increase in large pool, you're using less memory with mts, which is to be expected.

legend has it that the sweet spot for going from dedicated connections to mts is around 300 sessions, but it will depend on your environment and application.

Paul Received on Sat Nov 16 2002 - 14:37:33 CST