Installation guide
Another technique is available to address memory above 4 GB. The Address Windowing Extensions interface (AWE) allows access to
RAM up to 64 GB. AWE is implemented through Physical Address Extensions, which are enabled by seng the /PAE ag in the boot.
ini le. In addion, the account that runs Oracle must have the “Lock memory” privilege set under Local Security. The “USE_INDI-
RECT_BUFFERS=TRUE” must also be set in the Oracle inializaon le. Another inializaon parameter requirement is that the DB_
BLOCK BUFFERS parameter should be used instead of the DB_CACHE parameter. Note that only the buer cache may be extended
above 4 GB. The rest of the SGA must t below 4 GB.
The AWE interface is supported by both Microso and Oracle. However, there is some performance overhead associated with AWE.
In performance tesng on 32-bit Windows systems, it has been noted that there is minimal performance gain when the Oracle SGA
size is increased above 4 GB all the way up to 8 GB. Above 8GB, performance gains are more noceable.
There is another “hidden” catch to using AWE memory. There is a registry parameter called AWE_MEMORY_WINDOW. This
parameter species a window contained within the rst the rst 4 GB of memory that is used as a “swap” space for mapping upper
memory buers. The default window size is 1 GB, but the size may be customized by explicitly seng the registry key. Every block
of high memory used must rst be temporarily copied to this scratch space. The larger this window (i.e. 1.25 GB), the higher the
eciency of the copy operaon, and the higher the performance. However, the ability to support large numbers of users will suer,
even with the use of Shared Server connecons. This is because the enre Shared Pool, Large Pool, and PGA must t in the space
under 4GB that is le aer subtracng the AWE_MEMORY_WINDOW. With a default AWE_MEMORY_WINDOW of 1 GB, this leaves
only 1 GB of memory available for supporng user connecons. Some relief is oered by reducing AWE_MEMORY_WINDOW to 0.75
GB. However, this will allow only a few hundred users to log on simultaneously. For large user populaons, the /3GB ag will have to
be
set in the boot.ini le as well as the /AWE ag. This frees up an extra 1 GB of memory for the Shared Pool, Large Pool, and PGA,
allowing more user connecons. Unfortunately, there is a downside. With the /3GB ag set, it is impossible to access over 16 GB of
RAM. Any addional RAM would be inaccessible.
Due to these issues, the following are best pracces for choosing server memory for Oracle implementaons on Windows. For
opmal performance on 32-bit systems, it is recommended to use 4 GB of RAM and a max SGA size of 3 GB. If you need a larger
amount of memory, it is recommended to use more than 8 GB of RAM. However, if you ulize a 64-bit version of Windows (Windows
Server 2003 Enterprise and Datacenter) and a 64-bit version of Oracle soware, you can use up to 16, 32, or 64 GB of RAM, depend-
ing on the Dell server chosen. The Dell PowerEdge 6850 server may ulize up to 64 GB of RAM, with 4 GB memory per slot.
Changes in Memory Requirements for RAC
When moving from a single node database to a RAC database, there are some changes in memory requirements. If you are keeping
the workload requirements per instance the same, then about 10% more buer cache and 15% more shared pool is required. The
addional memory requirement is due to data structures for coherency management. The values are heurisc and are mostly upper
bounds. Actual resource usage can be monitored by querying current and maximum columns for the gcs resource/locks and ges
resource/locks entries in V$RESOURCE_LIMIT.