Ce contenu n'est pas disponible dans la langue sélectionnée.
17.2. Configuring Very Large Memory (VLM)
The following example shows how to use the RAM disk ramfs to allocate 8 GB of shared memory for the Oracle 10g database buffer cache on a 32 bit Red Hat Enterprise Linux 3, 4 or 5 systems (hugemem kernel). If this setup is performed on a server that does not have enough RAM, then Linux will appear to hang and the kernel will automatically start killing processes due to memory shortage (
ramfs
is not swappable). Furthermore, ramfs
is not backed by Huge Pages and therefore the Huge Pages pool should not be increased for database buffers, see Chapter 6, Swap Space. In fact, if there are too many Huge Pages allocated, then there may not be enough memory for ramfs.
Since ramfs is not swappable, it is by default only usable by root. If you put too much on a ramfs file system, you can easily hang the system. To mount the ramfs file system and to make it usable for the Oracle account, execute:
# umount /dev/shm # mount -t ramfs ramfs /dev/shm # chown oracle:dba /dev/shm
When Oracle starts it will create a file in the
/dev/shm
directory that corresponds to the extended buffer cache. Ensure to add the above lines to /etc/rc.local
. If ointall
is the primary group of the Oracle account, use chown oracle:oinstall /dev/shm
instead. For security reasons you do not want to give anyone write access to the shared memory file system. Having write access to the ramfs
file system allows you to allocate and pin a large chunk of memory in RAM. In fact, you can kill a machine by allocating too much memory in the ramfs
file system.
To enable VLM, set the Oracle parameter
use_indirect_data_buffers
to true:
use_indirect_data_buffers=true
For 10g R1 and R2 databases it is important to convert
DB_CACHE_SIZE
and DB_xK_CACHE_SIZE
parameters to DB_BLOCK_BUFFERS
, and to remove SGA_TARGET
if set. Otherwise you will get errors like these:
ORA-00385: cannot enable Very Large Memory with new buffer cache parameters
Here is an example for configuring a 8 GB buffer cache for a 10g R2 database with Red Hat Enterprise Linux 3, 4 or 5
hugemem
kernels:
use_indirect_data_buffers=true db_block_size=8192 db_block_buffers=1048576 shared_pool_size=2831155200
Note that
shmmax
needs to be increased for shared_pool_size
to fit into the System V shared memory. In fact, it should be slightly larger than the SGA size. Since shared_pool_size
is less than 3 GB in this example, shmmax
does not need to be larger than 3GB. The 8 GB indirect buffer cache will be in the RAM disk and hence it does not have to be accounted for in shmmax
. On a 32 bit system the shmmax
kernel parameter cannot be larger than 4GB, see also Section 7.3, “Setting SHMALL Parameter”.
In order to allow oracle processes to lock more memory into its address space for the VLM window size, the
ulimit
parameter memlock
must be changed for oracle. Ensure to set memlock
in /etc/security/limits.conf
to 3145728:
oracle soft memlock 3145728 oracle hard memlock 3145728 Login as Oracle again and check max locked memory limit: $ ulimit -l 3145728
If it is not working after a
ssh
log in, then you may have to set the SSH parameter UsePrivilegeSeparation
, see Chapter 22, Setting Shell Limits for Your Oracle User.
If
memlock
is not set or too small, you will get error messages similar to this one:
ORA-27103: internal error Linux Error: 11: Resource temporarily unavailable
Now try to start the database. Note the database start up can take a while. Also, the
sqlplus
banner or show sga may not accurately reflect the actual SGA size in older Oracle versions.
The 8GB file for the database buffer cache can be seen in the ramfs shared memory file system:
$ ls -al /dev/shm total 120 drwxr-xr-x 1 oracle dba 0 Nov 20 16:29 . drwxr-xr-x 22 root root 118784 Nov 20 16:25 .. -rw-r----- 1 oracle dba 8589934592 Nov 20 16:30 ora_orcl_458754 $
If the shared pool size is configured too large, you will get error messages similar to this one:
ORA-27103: internal error Linux Error: 12: Cannot allocate memory