Progress Transactions Test

This test auto-discovers the users on the target Progress database server and for each user, reports the transaction activity performed on the target Progress database server. Using this test, administrators can easily track the numerical statistics of each transaction type and identify which type of transaction is executed too often on the target Progress database server and which user is responsible for those transactions.

Target of the test : A Progress Database Server

Agent deploying the test : An internal/external agent

Outputs of the test : One set of results for every user on the target 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.

Detailed Diagnosis

To make diagnosis more efficient and accurate, the eG Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

  • The eG manager license should allow the detailed diagnosis capability
  • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
Measurements made by the test
Measurement Description Measurement Unit Interpretation

Initiated transactions

Indicates the number of transactions initiated with the Begin status by this user.

Number

This measure is a good indicator of the current workload of the database server.

Active transactions

Indicates the number of transactions that are active for this user.

Number

 

Outside locked transactions

Indicates the number of transactions initiated by this user that acquired locks from outside.

Number

The detailed diagnosis of this measure lists the Transaction ID, Transaction flag, Transaction star time, Duration, Connection ID, Client IP address, Connection start time, Statement type and SQL Text.

Lock unreleased transactions

Indicates the number of transactions that are completed by this user but the locks are yet to be released.

Number

 

Preparing to commit transactions

Indicates the number of transactions that are being prepared for a commit by this user.

Number

 

Two-phase commit transactions

Indicates the number of transactions for this user that are in two-phase commit status.

Number

Two-phase commit ensures that distributed transactions occur consistently across all databases. Two-phase commit protects against inconsistency by making sure that all databases commit the transaction, or that none commit. To ensure database integrity across all involved databases, the database engine commits database updates in two distinct phases. During the first phase, the database engine checks each database involved in a transaction to verify that it is ready to commit the transaction. During the second phase, the database engine directs the databases to commit the transaction and then verifies that they committed it properly. If there is an inconsistency, the database engine displays error messages and allows you to complete or roll back the inconsistent transaction to return the data to a consistent state.

Phase-1 transactions

Indicates the number of transactions that are entering phase -1 for this user.

Number

Phase 1 indicates that though the transaction is ready to commit it is yet to send a ready to commit response.

Phase-2 transactions

Indicates the number of transactions that are entering phase 2 status for this user.

Number

 

Ready to commit transactions

Indicates the number of transactions (initiated by this user) that are ready to be committed.

Number

 

Limbo transactions

Indicates the number of limbo transactions initiated by this user.

 

A limbo transaction (also known as an in-doubt transaction) occurs if the coordinator database commits or aborts a distributed transaction, but a hardware or software failure prevents other databases from doing likewise. This is called a limbo transaction because the processing of the transaction is temporarily suspended. A limbo transaction might occur for a variety of reasons; for example, as a result of a power outage.

When a limbo transaction occurs, you must resolve the transaction to re-establish data consistency.

Active JTA transactions

Indicates the number of Java Transaction API (JTA) transactions initiated by this user that are currently active.

Number

 

Idle JTA transactions

Indicates the number of Java Transaction API (JTA) transactions initiated by this user that are currently idle.

Number

 

Prepared JTA transactions

Indicates the number of prepared JTA transactions that were initiated by this user.

Number

 

Rolledback only JTA transactions

Indicates the number of JTA transactions initiated by this user were rolled back due to errors encountered.

Number

Ideally, the value of this measure should be low.

Committed JTA transactions

Indicates the number of committed JTA transactions that were initiated by this user.

Number