Most of the DB2 parameters that you set to store a geodatabase have to do with locking.
Deadlocks may not be uncommon, depending on the client application and the database configuration. Note that the problem may be aggravated with deep states lineages. DB2 provides tuning parameters to control the size of the lock list (LOCKLIST), the maximum percentage of locks an application can hold (MAXLOCKS), the amount of time a request will wait for a lock to be acquired (LOCKTIMEOUT), the frequency interval for deadlock detection (DLCHKTIME), and deadlock rollback behavior (DB2LOCK_TO_RB).
The default value for LOCKLIST and MAXLOCKS is AUTOMATIC, which enables these parameters for self tuning. This allows the DB2 memory tuner to dynamically size the memory resources between different memory consumers. Automatic tuning only occurs if self-tuning memory is enabled for the database (SELF_TUNING_MEM=ON).
To view lock list settings, issue the following command:
db2 get db cfg
Max storage for lock list (4KB) (LOCKLIST) = 50
Interval for checking deadlock (ms) (DLCHKTIME) = 10000
Percent. of lock lists per application (MAXLOCKS) = 22
Lock time out (sec) (LOCKTIMEOUT) = -1
Max number of active applications (MAXAPPLS) = AUTOMATIC
- LOCKTIMEOUT
To set the amount of time DB2 will wait when attempting to acquire a lock, modify LOCKTIMEOUT.
- DLCHKTIME
To tune the period between deadlock detection checks, adjust DLCHKTIME.
- DB2LOCK_TO_RB
DB2LOCK_TO_RB specifies the behavior of the transaction when the amount of time waiting on a lock exceeds LOCKTIMEOUT. By default, a lock time-out will roll back the request transaction. The default behavior should be sufficient geodatabases in DB2.
For the DB2LOCK_TO_RB registry value, use db2set and look for DB2LOCK_TO_RB=.
For information on setting these parameters, see the DB2 documentation in the IBM Knowledge Center.