Db2 Locks Test

Typically, locking activity is governed by the following factors: 

  • Concurrency and granularity
  • Lock compatibility
  • Lock conversion
  • Lock escalation
  • Lock waits and timeouts
  • Deadlocks

In the event of an application slowdown, the measures reported by the Db2 Locks test enable administrators to accurately determine whether/not any of the above-mentioned factors have adversely impacted application performance, and if so, to what extent.

Target of the test : A DB2 database server

Agent deploying the test : An internal agent

Outputs of the test : One set of results for every database on the DB2 database server that is currently active

Configurable parameters for the test
Parameter Description

Test period

How often should the test be executed

Host

The IP address of the DB2 server

Port

  • The port number through which the DB2 server communicates. The default port is 50000.
  • User

    Specify the name of the user who is authorized to access the target database server and collect the required metrics in this text box. You can create a separate user on the OS hosting the DB2 server for this purpose. The steps for the same are detailed in the Creating a Special User for Monitoring DB2 Server topic.

    Password

    Enter the password of the specified USER in the PASSWORD text box.

    Confirm Password

    Confirm the Password by retyping it in the Confirm Password text box.

    Database

    Specify the name of the database on the monitored DB2 server to be used by this test.

    Include DB

    Specify a comma-separated list of databases that you wish to monitor in the Include DB text box.

    Exclude DB

    Specify a comma-separated list of databases that need to be excluded from monitoring in the Exclude DB text box.

    SSL

    If the target database server is SSL-enabled, then set the SSL flag to Yes. If not, then set the SSL flag to No.

    Trust Store File Name

    This parameter is applicable only if the target DB2 UDB database is SSL-enabled, if not, set this parameter to none. Specify the file name of the client-side SSL truststore that contains the server certificate required for establishing an SSL connection. The truststore is used to verify the identity of the server and enable a secure communication channel.

    By default, the truststore file should be placed in:<EG_INSTALL_DIR>/jre/lib/security/mytruststore.jks

    Here, mytruststore.jks is the Truststore file name. You may change this to any valid file name. By default, none is specified against this text box.

    Trust Store Password

    This parameter is applicable only if the target DB2 UDB database is SSL-enabled, if not, set this parameter to none. If a Truststore File name is provided, then, in this text box, provide the password that is used to obtain the associated certificate details from the Truststore File. By default, this parameter is set to none.

    Confirm Password

    Confirm the Password by retyping it in the Confirm Password text box.

    Measurements made by the test
    Measurement Description Measurement Unit Interpretation

    Locks Held:

    Indicates the total number of locks currently held by all applications in the database.

    Number

     

    Locks Escalated:

    Indicates the number of times every second that locks have been escalated from several row locks to a table lock. A lock is escalated when the total number of locks held by an application reaches the maximum amount of lock list space available to the application, or the lock list space consumed by all applications is approaching the total lock list space. The amount of lock list space available is determined by the maxlocks and locklist configuration parameters. When an application reaches the maximum number of locks allowed and there are no more locks to escalate, it will then use space in the lock list allocated for other applications. When the entire lock list is full, an error occurs. This data item includes a count of all lock escalations, including exclusive lock escalations.

    Escalations/Sec

    There are several possible causes for excessive lock escalations:

    1. The lock list size (locklist) may be too small for the number of concurrent applications
    2. The percent of the lock list usable by each application (maxlocks) may be too small
    3. One or more applications may be using an excessive number of locks.
    4. To resolve these problems, you may be able to:
    5. Increase the locklist configuration parameter value.
    6. Increase the maxlocks configuration parameter value.

    Identify the applications with large numbers of locks or those that are holding too much of the lock list. These applications can also cause lock escalations in other applications by using too large a portion of the lock list. These applications may need to resort to using table locks instead of row locks, although table locks may cause an increase in lock_waits and lock_wait_time.

    Exclusive Lock Escalations:

    Indicates the number of times per second that locks have been escalated from several row locks to one exclusive table lock, or the number of times (per second) an exclusive lock on a row caused the table lock to become an exclusive lock.

    Escalations/Sec

    Other applications cannot access data held by an exclusive lock; therefore it is important to track exclusive locks since they can impact the concurrency of your data. A lock is escalated when the total number of locks held by an application reaches the maximum amount of lock list space available to the application. The amount of lock list space available is determined by the locklist and maxlocks configuration parameters. When an application reaches the maximum number of locks allowed and there are no more locks to escalate, it will then use space in the lock list allocated for other applications. When the entire lock list is full, an error occurs. See Lock escalations for possible causes and resolutions to excessive exclusive lock escalations.

    An application may be using exclusive locks when share locks are sufficient. Although share locks may not reduce the total number of lock escalations share lock escalations may be preferable to exclusive lock escalations.

    Locks Timedout:

    Indicates the number of times that a request to lock an object timed-out instead of being granted.

    Timeouts/Sec

    This measurement can help you adjust the setting for the locktimeout database configuration parameter. If the number of lock time-outs becomes excessive when compared to normal operating levels, you may have an application that is holding locks for long durations. In this case, this element may indicate that you should analyze some of the other lock and deadlock monitor elements to determine if you have an application problem.

    You could also have too few lock time-outs if your locktimeout database configuration parameter is set too high. In this case, your applications may wait excessively to obtain a lock.

    Lock Waits:

    Indicates the total number of times per second that applications or connections waited for locks.

    Waits/Sec

    If the value is consistently high, find t the applications or connections causing lock waits and fine tune the appropriate SQL queries.

    Average Lock Wait Time:

    Indicates the average time that all the applications were waiting for a lock.

    Secs

    If the average lock wait time is high, you should look for applications that hold many locks, or have lock escalations, with a focus on tuning your applications to improve concurrency, if appropriate.

    Percent of Application in Lock Wait:

    Indicates the percentage of applications waiting for the release of lock.

    Percent

    If this value is high, the applications may have concurrency problems, and you should identify applications that are holding locks or exclusive locks for long periods of time.

    Deadlocks:

    Indicates the total number of deadlocks that have been detected per second.

    Deadlocks/Sec

    This element can indicate that applications are experiencing contention problems. These problems could be caused by the following situations:

    1. Lock escalations are occurring for the database
    2. An application may be locking tables explicitly when system-generated row locks may be sufficient.
    3. An application may be using an inappropriate isolation level when binding
    4. Catalog tables are locked for repeatable read
    5. Applications are getting the same locks in different orders, resulting in deadlock

    You may be able to resolve the problem by determining in which applications (or application processes) the deadlocks are occurring. You may then be able to modify the application to enable it to execute concurrently. Some applications, however, may not be capable of running concurrently.