The following are the release notes for HammerDB v4.6.
From version 4.0 In the database.xml file and the User Interface the workload names have changed to TPROC-C and TPROC-H. This is a nomenclature change only to represent that the workloads are fair use implementations derived from the TPC specifications and the nomenclature does not change the functionality of the workload compared to prior versions using the TPC-C and TPC-H terminology.
From version 4.0 the stored procedures for the Oracle and PostgreSQL TPROC-C workloads have been refactored. From version 4.5 the stored procedures for the SQL Server TPROC-C have been refactored and MySQL, MariaDB and Db2 modified. This increases the expected performance between versions and consequently the performance from HammerDB v4.5 & HammerDB v4.0 cannot be compared directly to the performance of v3.3 or previous releases dependent on the database being tested. Additionally for some workloads HammerDB v45/v4.0 changed the relationship between the NOPM and TPM metrics compared to previous versions. As a result of the stored procedure refactoring using bulk operations more work is processed per commit and therefore in these cases the NOPM has increased whilst the TPM remains the same. This indicates a real measure of increased throughput by doing more work per database transaction and consequently NOPM is now listed first as the primary metric in reporting output. However as raised in HammerDB GitHub Issue #111 there may be cases where there is a dependency on the wording of the HammerDB log. For this reason a configuration option in the generic.xml file of first_result is given. If this option is set to NOPM then the v4.0 format is used if set to TPM then the output is compatible with v3.3.
<benchmark>
<rdbms>Oracle</rdbms>
<bm>TPC-C</bm>
<first_result>NOPM</first_result>
</benchmark>HammerDB v4.6 includes a built-in SQLite repository database to store the output, results, configuration, timing and transaction count of workloads run in the Command Line (CLI) and can also be enabled by advanced users in the GUI. This feature can also be disabled if desired.
HammerDB v4.6 permits the CLI to be run in a system installed Python interpreter calling HammerDB CLI commands with python syntax. At version v4.6 this feature requires a system installed Python 3.8 on Linux, Python 3.6 on Red Hat Enterprise Linux 8 and Python 3.10 on Windows.
From version v4.6 the commands runtimer and waittocomplete have been deprecated with these values calculated automatically, running these commands will print a deprecation notice "runtimer command has been deprecated and is not required for version v4.6". An additional configuration parameter of keepalive_margin with a default value of 10 seconds has been added to generic.xml in the commandline section to modify the additional time that HammerDB will wait after completion before terminating the workload. This can be useful if for example gathering timing data for event driven scaling workloads with a large number of asynchronous clients.
From v4.6 the default driver has been set to be "timed" instead of "test". This setting can be changed in the GUI and CLI interface.
HammerDB has a dependency on 3rd party driver libraries to connect to the target databases. The following are known issues with some of the 3rd party drivers that HammerDB uses.
If you are running HammerDB against Oracle on Windows there is long established bug in Oracle that can cause application crashes for multi-threaded applications on Windows.This bug can be investigated on the My Oracle Support website with the following reference. Bug 12733000 OCIStmtRelease crashes or hangs if called after freeing the service context handle. To resolve this Oracle issue add the following entry to the SQLNET.ORA file on your HammerDB client.
SQLNET.AUTHENTICATION_SERVICES = (NTS) DIAG_ADR_ENABLED=OFF DIAG_SIGHANDLER_ENABLED=FALSE DIAG_DDE_ENABLED=FALSE
Using the HammerDB client for SQL Server on Linux can be slower than the same client on Windows when using the default installed unixODBC drivers on many Linux distributions. As described in the SQL Server Programming Guidelines "When using the driver with highly multithreaded applications, unixODBC's handle validation may become a performance bottleneck. In such scenarios, significantly more performance may be obtained by compiling unixODBC with the --enable-fastvalidate option. However, beware that this may cause applications which pass invalid handles to ODBC APIs to crash instead of returning SQL_INVALID_HANDLE errors." Recompiling unixODBC with the --enable-fastvalidate option has been measured to improve client performance by 2X. Example configure options used to build unixODBC are shown as follows:
./configure --prefix=/usr/local/unixODBC --enable-gui=no --enable-drivers=no --enable-iconv
--with-iconv-char-enc=UTF8 --with-iconv-ucode-enc=UTF16LE --enable-threads=yes --enable-fastvalidate