Progress Lock Requests Test

A Progress database server provides data concurrency and integrity between transactions using locking mechanisms. The locking activity of a database server should 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.

This test indicates the level of locking activity on a database in terms of the number of locks of different modes held by each user and the time taken by each user to hold a RECORD lock and TRANSACTION lock.

Target of the test : A Progress Database server

Agent deploying the test : An internal agent

Outputs of the test : One set of results for every user accessing the locks on the target Progress database server being monitored

Configurable parameters for the test

Parameter	Description
Test Period	How often should the test be executed
Host	The IP address of the Progress database server.
Port	The port number on which the database server is listening. By default, this is NULL.
Database Name	Specify the name of the Progress database instance that is to be monitored.
Username	In order to monitor a Progress database instance, a special database user account has to be created in every Progress database instance that requires monitoring. This special user needs to be granted a set of privileges. To know how to create the database user and grant the required privileges, refer to Pre-Requisites for monitoring the Progress database. Specify the name of such a user in this text box.
Password	The password of the specified Username.
Confirm Password	Confirm the password by retyping it here.

Measurements made by the test

Measurement	Description	Measurement Unit	Interpretation
Exclusive locks	Indicates the rate at which EXCLUSIVE locks were held by this user on the database during the last measurement period.	Locks/sec	Exclusive locks are used to lock data being modified by one transaction thus preventing modifications by other concurrent transactions. You can read data held by exclusive lock only by specifying a NOLOCK hint or using a read uncommitted isolation level. Because DML statements first need to read the data they want to modify you’ll always find Exclusive locks accompanied by shared locks on that same data.
Record locks	Indicates the rate at which RECORD locks were held by this user on the database during the last measurement period.	Locks/sec
Record lock waits	Indicates the rate at which this user had to wait to hold the RECORD locks on the database during the last measurement period.	Waits/sec
Shared locks	Indicates the rate at which SHARED locks were held by this user on the database during the last measurement period.	Locks/Sec
Transaction locks	Indicates the rate at which TRANSACTION locks were held by this user on the database during the last measurement period.	Locks/sec
Transaction lock waits	Indicates the rate at which this user had to wait to hold the TRANSACTION locks on the database during the last measurement period.	Waits/Sec