IDLM has internal data structures that contain lists of all database resources. IDLM also tracks the status of both PCM and non-PCM locks on all instances. The IDLM internal data structures that contain these types of information are referred to as IDLM resources and IDLM locks. The LM_RESS and LM_LOCK initialization parameters determine how many of these data structures are allocated. These parameters are used to configure the capacity of the IDLM:

Consider, for example, an OPS environment with two instances, where data block B1 is protected by PCM lock L1. Also assume that instance 2 is updating the block. Since instance 2 is updating block B1, it will hold lock L1 in exclusive mode. The other instance then has lock L1 in null mode. In this case, you need one LM_RESS data structure to keep information about the resource, and you need two LM_LOCKS data structures to maintain the lock status on both the instances, as shown in Figure 10.2.

Figure 10-2. Lock Manager parameters

The value of the LM_RESS parameter must take into consideration all of the database resources that are protected by PCM as well as non-PCM locks. The value of LM_LOCKS depends on the number of instances in the OPS environment. One “bottom-up” approach to setting up LM_RESS and LM_LOCKS is to compute the total number of PCM resources, non-PCM resources, and locks required in your OPS environment. A detailed discussion and worksheet are provided in Oracle Corporation’s OPS Concepts and Administration manual in the chapter titled “Ensuring IDLM Capacity for all Resources and Locks.” See also the related discussions in other chapters of the same manual.

A “top-down” approach that we suggest is to initially set up a high value for these parameters based on the available memory that can be allocated to the SGA. Then monitor the V$RESOURCE_LIMIT dynamic performance view, and adjust these parameters based on utilization. In order to do this, you have to first determine how much memory each IDLM lock and IDLM resource data structure take up. The exact amount of memory consumed by each IDLM lock and IDLM resource for each additional increment of the LM_RESS and LM_LOCKS parameter settings is platform-dependent. On an IBM RS/6000 platform, each additional increment of the LM_RESS and LM_LOCKS parameter settings requires 220 bytes of memory. You can do a test on your own platform to determine the memory requirements for these parameters. Successively increase the value of each initialization parameter (one at a time), and note the size of the SGA after restarting the OPS instance after each increase. After a few such changes, you should be able to compute the memory required for allocating IDLM data structures in accordance with these parameter settings.

Once you know the memory requirements for each of these parameters, you can initially set up high values for LM_RESS and LM_LOCKS based on the most memory that can be allocated to the SGA. This is only a starting point for the tuning activity. You then can check the usage of LM_RESS and LM_LOCKS periodically by executing the query shown in the following example. Note that using higher values beyond the utilization limits shown in the V$RESOURCE_LIMIT view results in unnecessary overhead. Tune your LM_RESS and LM_LOCKS values based on the CURRENT_UTILIZATION and MAX_UTILIZATION values:

SQL> SELECT * 
  2 FROM v$resource_limit 
  3 WHERE resource_name like 'lm%';

RESOURCE_NAME   CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_AL LIMIT_VALU
--------------- ------------------- --------------- ---------- ----------
lm_procs                        228             268       1200       1200
lm_ress                       29702           29828      31024  UNLIMITED
lm_locks                      34206           34231      35000  UNLIMITED

If the number of LM_RESS and LM_LOCKS specified by the initialization parameters is not adequate, then additional IDLM locks and resources are allocated dynamically. Memory for dynamically allocated LM_RESS and LM_LOCKS is taken from the shared pool in the SGA. Each time there is a dynamic allocation, one of the following messages will be written to the alert log:

Dynamic allocation has an adverse impact on performance and also reduces the memory that is allocated to the shared pool in the SGA. So make sure you provide adequate initial values for these parameters. If you see these messages frequently in your alert log, you should increase your LM_RESS and LM_LOCKS parameter values. In Oracle8i (Version 8.1.6) these parameters values are automatically set by Oracle.