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 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