Resident Portion

The resident portion includes areas of shared memory that record the state of the database server, including buffers, locks, log files, and the locations of dbspaces, chunks, and tblspaces.

The settings that you use for the LOCKS, LOGBUFF, and PHYSBUFF configuration parameters help determine the size of the resident portion.

The BUFFERPOOL configuration parameter determines the amount of buffers allocated to the resident segment when the database server is started. Subsequent buffer pools that are added while the database server is running go into virtual memory until the database server is restarted.

In addition to these configuration parameters, which affect the size of the resident portion, the RESIDENT configuration parameter can affect memory utilization. When RESIDENT is set to 1 in the ONCONFIG file of a computer that supports forced residency, the resident portion is never paged out.

The machine notes file for your database server indicates whether your operating system supports forced residency. For information on where to find the machine notes file, see the Introduction to this guide.

To estimate the size of the resident portion (in kilobytes) when you allocate operating-system shared memory, take the following steps. The result provides an estimate that slightly exceeds the actual memory used for the resident portion.

To estimate the size of the resident portion

To estimate the size of the data buffer, use the following formula:
```
buffer_value = (BUFFERS * pagesize) + (BUFFERS * 254)
```
pagesize

is the shared-memory page size, as onstat -b displays it on the last line in the buffer size field.

Calculate the values in the following formulas:

locks_value = LOCKS * 44
logbuff_value = LOGBUFF * 1024 * 3
physbuff_value = PHYSBUFF * 1024 * 2

To calculate the estimated size of the resident portion in kilobytes, use the following formula:

rsegsize = (buffer_value + locks_value + logbuff_value 
           + physbuff_value + 51,200) / 1024

The LOCKS configuration parameter specifies the initial size of the lock table. If the number of locks that sessions allocate exceeds the value of LOCKS, the database server dynamically increases the size of the lock table. If you expect the lock table to grow dynamically, set SHMTOTAL to 0. When SHMTOTAL is 0, no limit on total memory (resident, virtual, communications, and virtual-extension portions of shared memory) allocation is stipulated.