Tibero Transaction Workload Test

Knowing the count of transactions executing on the Tibero database server per second can indicate the transaction load on the server. However, the true impact of this load can be assessed and understood only if administrators are enabled to determine the number and type of database operations each transaction triggers. This is where the Tibero Transaction Workload test helps!

This test reports how many key database operationSs - eg., data modifications, block changes, reads/writes, parses, rollbacks, etc. - are performed on the server per transaction. This way, the test reveals the real workload of the server. In addition, the test also enables administrators to compare current CPU usage with the real workload, so that they can figure out whether/not the server needs to be resized to handle its load.

Target of the test : A Tibero Database server

Agent deploying the test :An internal agent

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

Configurable parameters for the test
Parameter Description

Test Period

How often should the test be executed.


The host for which the test is to be configured.


The port to which the specified host listens. By default, the port number is 8629.

User and Password

In order to monitor a Tibero database server, a special database user account has to be created in every Tibero database instance that requires monitoring. A Click here hyperlink is available in the test configuration page, using which a new Tibero database user can be created. Alternatively, you can manually create the special database user. When doing so, ensure that this user is vested with the select any dictionary and create session privileges.

The sample script we recommend for user creation for eG monitoring is:

create user tibeg identified by tibeg default tablespace <users> temporary tablespace<temp>;

grant create session, select any dictionary tibeg;

The name of this user has to be specified in the User text box, and the password of this user has to be entered in the Password text box. This login information is required to query Tibero's internal dynamic views, so as to fetch the current status / health of the various database components.

Confirm Password

Confirm the Password by retyping it here.

Tibero SID

Specify the SID of the target Tibero database instance that is to be monitored in this text box.

Measurements made by the test
Measurement Description Measurement Unit Interpretation

Redo size

Indicates the amount of data written to the redo logs per transaction since the last measurement period.


If the value of this measure keeps growing, it could indicate that transactions are making numerous and frequent changes to the data in the databases.

Logical reads

Indicates the number of logical reads performed by the server per transaction.


These measures are good indicators of the level of activity that every transaction generated on the database server.



Block changes

Indicates the number of database blocks that were changed per transaction.


Physical reads

Indicates the number of physical reads performed per transaction.


User calls

Indicates the number of user calls made per transaction.




Indicates the number of parses executed by the server per transaction.


Parsing is one stage in the processing of a SQL statement. When an application issues a SQL statement, the application makes a parse call to Tibero Database. During the parse call, Tibero Database:

  • Checks the statement for syntactic and semantic validity.
  • Determines whether the process issuing the statement has privileges to run it.
  • Allocates a private SQL area for the statement.

If the value of this measure keeps increasing consistently, it could indicate on an average, transactions are executing many SQL statements on the server, thus generating more parses.

Hard parses

Indicates the number of hard parses executed per transaction.


As opposed to a soft parse, a hard parse loads the SQL source code into RAM for parsing. A high value for this measure therefore indicates that the server is performing many hard parses.


Indicates the number of users logging in per transaction.


A steady rise in this value is indicative of a steady increase in user activity on the server.


Indicates the number of executes performed per transaction.




Indicates the number of rollbacks performed per transaction.


Ideally, the value of this measure should be low. This is because, rollbacks are expensive operations and should be avoided at all costs. A consistent increase in the value of this measure is hence a cause for concern.


Indicates the rate at which transactions were executed by the server.


A steady increase in the value of this measure could indicate an increase in the transaction load on the server. A consistent and notable drop in the value of this measure could indicate a bottleneck in transaction processing.