eG Monitoring
 

Measures reported by HanaRdWrtLckTest

SAP HANA Database provides various lock modes to control concurrent access to data in tables. Lock mode considers various lock types that can be applied to a resource that has to be locked.

Lock Type Lock Mode Description
Shared locks S (Shared)

Several users (transactions) can access locked data at the same time in display mode. Requests from further shared locks are accepted, even if they are from different users.

An exclusive lock (E) set by another user on an object that already has a shared lock will be rejected. Every extended exclusive lock (X) will also be rejected.
Exclusive locks E (Exclusive)

Locks the table in EXCLUSIVE mode. EXCLUSIVE locks are acquired explicitly by LOCK TABLE, but are also acquired implicitly by DDL commands. EXCLUSIVE locks have the following characteristics:

  • The transaction that holds the lock can read and write to the table. All other transactions can read from the table but cannot write to it.

  • When a table has an EXCLUSIVE lock on it, all other lock requests by other transactions are blocked.

  • The database releases acquired locks at the end of the transaction.
Intent Locks I (Intent)

Intent locks are a means in which a transaction notifies other transaction that it is intending to lock the data. Thus the name. Their purpose is to assure proper data modification by preventing other transactions to acquire a lock on the object higher in lock hierarchy. What this means is that before you obtain a lock on the page or the row level an intent lock is set on the table. This prevents other transactions from putting exclusive locks on the table that would try to cancel the row/page lock.
Intentional Exclusive Locks IX Intentional Exclusive

Locks the table in INTENTIONAL EXCLUSIVE mode.

  • Acquired by DML implicitly.

  • Multiple transactions can acquired a INTENTIONAL EXCLUSIVE lock.

  • EXCLUSIVE lock requests for the table by other transactions are blocked while the INTENTIONAL EXCLUSIVE lock is held.

  • The database releases acquired locks at the end of the transaction.

The locking activity of a database server must be monitored carefully because an application holding a specific lock for a long time could cause a number of other transactions relying on the same lock to fail. The HANA Locks Test monitors the locking activity on a database server instance. This test monitors the lock wait events on the SAP HANA Database server, and promptly alerts administrators to a sudden/steady increase in the number and duration of such events. With this information, administrators can easily troubleshoot long wait times.

Outputs of the test: One set of results for the target database server being monitored.

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
Exclusive_locks Indicates thenumber of Exclusive locks that are currently held on the database server during the last measurement period. Number

A high value may indicate one of the following:

  • Too many transactions happening

  • Locked resources not being released properly

  • Locks are being held unnecessarily
ExclusiveLockWaits Indicates the number of requests waiting to acquire Exclusive locks during the last measurement period. Number

Lock waits can be caused by transactions that take too long to execute. Long wait times can also occur when various applications want to lock the same object.

A consistent increase in the value for this measure could indicate that locks are not being released in a timely manner.
AvgExclusiveLckWaits Indicates the average time for which requests were waiting to acquire an exclusive lock during the last measurement period. Seconds

Ideally, this value should be very low. A high value or a consistent increase in the value may choke the database server and severely hamper its overall performance. Therefore, if the value of this measure is high, you might first need to identify what is causing the lock waits.

A high value may indicate one of the following:

  • Too many transactions happening

  • Locked resources not being released properly

  • Locks are being held unnecessarily.
IntentLocks Indicates thenumber of Intent locks that are currently held on the database server during the last measurement period. Number

A high value may indicate one of the following:

  • Too many transactions happening

  • Locked resources not being released properly

  • Locks are being held unnecessarily.
IntentLockWaits Indicates the number of requests waiting to acquire Intent locks during the last measurement period. Number

Lock waits can be caused by transactions that take too long to execute. Long wait times can also occur when various applications want to lock the same object.

A consistent increase in the value for this measure could indicate that locks are not being released in a timely manner.
AvgIntentLckWaitTime Indicates the average time for which requests were waiting to acquire an Intent lock during the last measurement period. Seconds

A high value may indicate that there is contention for locks in the system. When the average wait time for locks is high, users may have to wait for their transactions to complete.
IntentTimeouts Indicates the number of times that a request to acquire Intent lock on an object timed-out instead of being granted during the last measurement period. Number

When a unit of work exceeds the maximum allowable amount of time, a lock timeout occurs and the unit of work isn’t granted the lock it has been waiting for.

If the number of lock timeouts becomes excessive when compared to normal operating levels, an application may be holding locks for long durations. This requires an adjustment in the LOCKTIMEOUT configuration parameter. Committing can also free locks.

If the LOCKTIMEOUT database configuration parameter is set too high, it may result in too few lock timeouts. In such a case, your applications may wait excessively to obtain a lock.
SharedLocks Indicates thenumber of Shared locks that are currently held on the database server during the last measurement period. Number

A high value may indicate one of the following:

  • Too many transactions happening

  • Locked resources not being released properly

  • Locks are being held unnecessarily.
SharedLockWaits Indicates the number of requests waiting to acquire Shared locks during the last measurement period. Number

Lock waits can be caused by transactions that take too long to execute. Long wait times can also occur when various applications want to lock the same object.

A consistent increase in the value for this measure could indicate that locks are not being released in a timely manner.
AvgSharedLckWaitTime Indicates the average time for which requests were waiting to acquire an Shared lock during the last measurement period. Seconds

A high value may indicate that there is contention for locks in the system. When the average wait time for locks is high, users may have to wait for their transactions to complete
SharedTimeouts Indicates the number of times that a request to acquire Shared lock on an object timed-out instead of being granted during the last measurement period. Number

If the number of lock timeouts becomes excessive when compared to normal operating levels, an application may be holding locks for long durations. This requires an adjustment in the LOCKTIMEOUT configuration parameter. Committing can also free locks.

If the LOCKTIMEOUT database configuration parameter is set too high, it may result in too few lock timeouts. In such a case, your applications may wait excessively to obtain a lock.