Oracle 9i R2 Support for Very Large Memory (VLM) Configurations

Support for Very Large Memory (VLM) Configurations

Oracle9i release 2 (9.2) for Windows supports Very Large Memory (VLM) configurations in Windows 2000 and Windows XP, which allows Oracle9i release 2 (9.2) to access more than the 4 gigabyte (GB) of RAM traditionally available to Windows applications.
Note:

This feature is not supported on Windows NT, and it is available on Windows 2000 and Windows XP only with Intel Pentium II and Pentium III Xeon 32-bit processors.

Specifically, Oracle9i release 2 (9.2) uses Address Windowing Extensions (AWE) built into Windows 2000 and Windows XP to access more than 4 GB of RAM.

The requirements for taking advantage of this support are:

1. More than 4 GB of RAM must be present in the server on which Oracle9i release 2 (9.2) will run.

2. The user account under which Oracle9i release 2 (9.2) runs (typically the local SYSTEM account), must have the "Lock memory pages" Windows 2000 and Windows XP privilege.

3. USE_INDIRECT_DATA_BUFFERS=TRUE must be present in the initialization parameter file for the database instance that will use VLM support. If this parameter is not set, then Oracle9i release 2 (9.2) behaves in exactly the same way as previous releases.

4. Initialization parameters DB_BLOCK_BUFFERS and DB_BLOCK_SIZE must be set to values you have chosen for Oracle9i database.

Note:

The total number of bytes of database buffers (that is, DB_BLOCK_BUFFERS multiplied by DB_BLOCK_SIZE) is no longer limited to 3 GB.
5. Registry parameter AWE_WINDOW_MEMORY must be created and set in the appropriate key for your Oracle home. This parameter is specified in bytes and has a default value of 1 GB. AWE_WINDOW_MEMORY tells Oracle9i release 2 (9.2) how much of its 3 GB address space to reserve for mapping in database buffers.

This memory comes from the 3 GB virtual address space in Oracle9i release 2 (9.2), so its value must be less than 3 GB. Setting this parameter to a large value has the effect of using more of the address space for buffers and using less AWE memory for buffers. However, since accessing AWE buffers is somewhat slower than accessing virtual address space buffers, Oracle recommends that you tune these parameters to be as large as possible without adversely limiting database operations.

In general, the higher AWE_WINDOW_MEMORY is set, the fewer connections and memory allocations will be possible for Oracle9i release 2 (9.2). The lower AWE_WINDOW_MEMORY is set, the lower the performance.
6. Once this parameter is set, Oracle9i release 2 (9.2) database can be started and will function exactly the same as before except that more database buffers are available to the instance. In addition, disk I/O may be reduced because more Oracle data blocks can be cached in the SGA.

Note:

Registry parameter VLM_BUFFER_MEMORY, which enabled VLM configurations in Windows NT in Oracle8i release 2 (8.1.6), is not supported in Oracle9i release 2 (9.2).

VLM Instance Tuning

VLM configurations improve database performance by caching more database buffers in memory. This reduces disk I/O compared to configurations without VLM. VLM support in Oracle9i release 2 (9.2) has been re-written to integrate very closely with Oracle9i database. Compared to Oracle8i release 2 (8.1.6), VLM users should see better performance with the newer implementation.

Tuning for VLM is no different than tuning for configurations without VLM. It is an iterative task that begins by selecting appropriate DB_BLOCK_SIZE and DB_BLOCK_BUFFER initialization parameters for the application being supported.
Note:

Oracle9i release 2 (9.2) VLM configurations do not support multiple database block sizes.

AWE_WINDOW_MEMORY, a new registry parameter specific to VLM, defaults to a value of 1 GB, which should be suitable for most installations. This parameter tells Oracle9i database how much of its address space to reserve for mapping in database buffers. Increasing this value will improve performance, but it will also limit the amount of memory available for other Oracle threads (like foreground threads). Clients may see "out of memory" errors if this value is set too large.

Having a large cache in a VLM configuration may also slow down database writer (DBWR) threads. Having more DBWR threads will distribute work required to identify and write buffers to disk and will distribute I/O loads among threads. Initialization parameter DB_WRITER_PROCESSES enables you to configure multiple database writer threads.

A large cache can also introduce contention on the LRU (least recently used) latch. On symmetric multiprocessor (SMP) systems, Oracle9i sets the number of LRU latches to a value equal to one half the number of processors on the system. You can reduce contention on such configurations by increasing the number of LRU latches to twice (or four times) the number of processors on the system.
See Also:

Oracle9i Database Performance Tuning Guide and Reference for more information on instance tuning
4 GB RAM Tuning (4GT)

Windows NT Server Enterprise and Datacenter Editions (version 4.0) include a feature called 4 GB RAM Tuning (4GT). This feature allows memory-intensive applications running on Oracle9i Enterprise Edition to access up to 3 GB of memory, as opposed to the standard 2 GB in previous operating system versions. 4GT provides a tremendous benefit: 50 percent more memory is available for database use, increasing SGA sizes or connection counts. 4GT is also supported on Windows 2000 Advanced Server and Windows 2000 Datacenter Server.
Large User Populations

New features allow Oracle9i to support an increasingly large number of database connections on Windows NT and Windows 2000:

* Oracle Shared Server Process, which limits the number of threads needed in the Oracle database process, supports over 10,000 simultaneous connections to a single database instance.

* Oracle Net multiplexing and connection pooling features allow a large configuration to connect more users to a single database instance.

* Oracle Real Application Clusters raises connection counts dramatically by allowing multiple server computers to access the same database files, increasing the number of user connections by tens of thousands, as well as increasing throughput.

Note:

Oracle Real Application Clusters is not supported on Windows XP.