To select the driver script options select Options from under the Driver Script heading in the tree-view.
This displays the Driver Script Options dialog. The connection options are common to the Schema Build Dialog in addition to new Driver Options.
Table 12.7. Driver Script Options
| Option | Description |
|---|---|
| Scale Factor | Although not visible under the Driver Options the Scale Factor value is also inherited from the Build Options and must be the set to the same value for running the Driver Script as was used for the Build. This option is required in the Driver Script when the refresh function is run to ensure that the data is created to insert in the correction location without errors. The Scale Factor is also used as input to some queries. From v4.8 HammerDB will automatically detect and set the Scale Factor if it is set incorrectly. |
| Total Query Sets per User | A Query Set is a sequence of 22 queries. The Total number of query sets is the number of times after logging on that the virtual user completes an entire sequence of queries before logging off again. The difference between this and using iterations value in the Virtual User options is that the virtual user only logs on and off once and completes all of the query sets in between whereas with the iterations value the entire script is run multiple times. |
| Exit on Database Error | Exit on Database Error is shown as the parameter RAISEERROR in the Driver Script. RAISEERROR impacts the behaviour of an individual virtual user on detecting a database error. If set to TRUE on detecting an error the user will report the error into the HammerDB console and then terminate execution. If set to FALSE the virtual user will ignore the error and proceed with executing the next transaction. It is therefore important to be aware that if set to FALSE firstly if there has been a configuration error resulting in repeated errors then the workload might not be reported accurately and secondly you may not be aware of any occasional errors being reported as they are silently ignored. |
| Verbose Output | Verbose Output is shown as VERBOSE in the Driver Script. Setting this value to TRUE will print both the Queries and their results for each virtual user however will add to the Query time by the time required to print the results. |
| Refresh Function | The refresh function checkbox corresponds to refresh_on in the Driver Script. When this checkbox is enabled the first virtual user will run the refresh function as opposed to running a query set. Note that if you choose only one virtual user and select the refresh function checkbox then your virtual user will run a power test as detailed further in this document. The refresh function as the name implies inserts and deletes rows from the ORDERS and LINEITEM tables and the times of this function are required as input to calculating the QphH. |
| Number of Update Sets/Trickle Refresh Delay(ms)/Refresh Verbose | If you have enabled the refresh function then the values for Number of Update Sets/Trickle Refresh Delay(ms)/Refresh Verbose become active and these correspond to update_sets trickle_refresh and REFRESH_VERBOSE in the driver script respectively. The update sets determines how many times the virtual users will cycle through the refresh functions whilst noting that the function always starts at 1 and therefore cannot be restarted against the same schema until the schema has been refreshed. The Trickle Refresh Delay value sets the delay between each insert and delete with a default of 1 second ensuring that the refresh function does not place a significant load on the system, The Refresh Verbose value means that the virtual user running the refresh function reports on its activities. |
| Cloud Analytic Queries (Oracle MySQL PostgreSQL Only) | When selected this option loads a driver script that runs the sequence of 13 Oracle Cloud Analytic Queries. |
| Degree of Parallelism (Oracle, Db2 and PostgreSQL Only) | For Oracle Degree of Parallelism defines the number of Parallel Execution Server processes that the Queries will be executed with. The Degree of Parallelism is defined as the degree of parallel in the driver script. You should consult a good reference on Parallel Execution as the actual execution environment is more complex including both Producer and Consumer Parallel Execution Servers. This value will be determined by your available hardware resources and may be different for both the Power and Throughput tests. HammerDB will ensure that the test will run at your chosen degree of parallelism (also dependant on your settings of parallel_min and parallel_max servers). For Db2 The Degree of Parallelism is the value used for the command “SET CURRENT DEGREE” in the driver script and determines the level of parallelism used in executing the queries. For PostgreSQL the Degree of Parallelism sets the max_parallel_workers_per_gather parameter for the sessions executing the queries. |
| MAXDOP (SQL Server Only) | The MAXDOP setting defines the Maximum degree of parallelism to be set as a default on the schema objects. |