With PostgreSQL by default the 5 TPROC-C transactions are implemented using PostgreSQL functions. From PostgreSQL v11.0 there is the option to use PostgreSQL stored procedures instead. However prepared statements are not supported by PostgreSQL for stored procedures only for functions and therefore if using the XML connect pool feature only PostgreSQL functions are supported. Conversely PgBouncer does not at the time of writing keep track of prepared statements and therefore when using event driven scaling, stored procedures are recommended.

With MySQL there is the option to use server side prepared statements. This option is mandatory if using the XML connect pool feature.

With MariaDB there is the option to use server side prepared statements. This option is mandatory if using the XML connect pool feature.

For MySQL and MariaDB there is an advanced option of No Stored Procedures. When selected this option will drive the TPROC-C workload entirely from the client, running the same SQL statements with the application logic within HammerDB. This option is useful when looking to run a workload with an increased network load and in tests increases the Bytes received and Bytes sent by 6X and 8X respectively. This option should not be expected to deliver NOPM/TPM values as high as using stored procedures due to the additional time spent at the network.

Figure 4.44. No Stored Procedures Option

For MariaDB there is an option supported in versions of MariaDB 10.7 and upwards to purge the history list after a workload has completed. This option is recommended for consistency of test results to prevent flushing during a test.

Figure 4.45. Purge when complete

The Generation of Oracle AWR reports is built-in functionality with the Oracle Timed Test. At the end of the test HammerDB will report the snapshot numbers between which the report corresponds to the test.

In the Db2 driver script options the Minutes for Test Duration is shown as monreportinterval in the Driver Script. This defines the period of time taken from the minutes for test duration that the monitoring user runs a monreport capture. The results are output at the end of the test and therefore selecting this option should be done in conjunction with the logfile enabled. While the MONREPORT is being captured the monitoring virtual user cannot bet terminated as control is handed over to the DB2 database and therefore shorter periods of report are optimal. In all cases in the MONREPORT interval specified is longer than the minutes for test duration then no MONREPORT will be captured.