Download PDF (1.3 MB) - IBM Redbooks

4.14.6 Ensuring sufficient locking resources are available
Locks are allocated from a common pool controlled by the locklist database level parameter,
which is the number of 4000 pages set aside for this use. A second database level parameter,
maxlocks, bounds the percentage of the lock pool held by a single application. When an
application attempts to allocate a lock that exceeds the fraction allowed by maxlocks, or when
the free lock pool is exhausted, DB2 performs lock escalation to replenish the supply of
available locks. Lock escalation involves replacing many row locks with a single table-level
lock.
Although lock escalation addresses the immediate problem of lock-pool overuse or starvation,
it can lead to database deadlocks and therefore should not occur frequently during normal
operation. In some cases, application behavior can be altered to reduce pressure on the lock
pool by breaking up large transactions that lock many rows into smaller transactions. It is
simpler to try tuning the database first.
Beginning with version 9, DB2 adjusts the locklist and maxlocks parameters automatically, by
default. To tune these parameters manually, observe whether lock escalations are occurring
either by examining the db2diag.log file or by using the system monitor to gather snapshots
at the database level. If the initial symptom is database deadlocks, consider whether these
deadlocks are initiated by lock escalations, as follows:
1. Check the lock escalations count in the output.:
db2 get snapshot for database
2. Obtain current values for locklist and maxlocks by examining the output.:
db2 get db config for
3. If necessary, alter these values, for example, to 100 for locklist and 20 for maxlocks, as
shown in Example 4-3.
Example 4-3 Setting values for locklist and maxlocks
db2 update db config for using locklist 100 maxlocks 20
When increasing the locklist size, consider the impacts of the additional memory allocation
that is required. Often, the locklist is relatively small compared with memory dedicated to
buffer pools, but the total memory required must not lead to virtual memory paging.
When increasing the maxlocks fraction, consider whether a larger value allows a few
applications to drain the free lock pool. This drain might lead to a new cause of escalations as
other applications needing relatively few locks encounter a depleted free lock pool. Often, a
better way is to start by increasing locklist size alone.
4.14.7 Setting boundaries on the size of the catalog cache for clustered
applications
The catalog cache is used to avoid repeating expensive activities, notably preparing execution
plans for dynamic SQL. Therefore, an important consideration is to be sure that the cache is
sized appropriately.
By default, several 4 KB pages of memory are allocated for each possible application as
defined by the MAXAPPLS database parameter. The multiplier is 4 for DB2 9, and 5 for
DB2 9.5 and later. MAXAPPLS is AUTOMATIC, by default, and its value are adjusted to
match the peak number of applications connected at run time.
Chapter 4. Performance tuning and configuration 85