The HammerDB CLI includes a jobs interface that stores benchmark configuration, virtual user output, status, result, timing, transaction count, metrics and system information in a SQLite database called hammer.DB. The same jobs repository is used by the GUI, CLI, web service and CI pipeline automation, so a workload started from one interface can be inspected from another.
The location of hammer.DB is controlled by the sqlite_db setting in the commandline section of generic.xml. By default HammerDB uses the operating system temporary directory. A flexible way to choose a specific jobs location is to set the TMP environment variable before starting HammerDB.
export TMP=/opt/hammerdb-ci/TMP ./hammerdbcli
On Windows, set the temporary directory before starting the CLI if you want the jobs repository to be created in a specific location.
C:\Program Files\HammerDB-6.0>set TEMP=C:\temp C:\Program Files\HammerDB-6.0>hammerdbcli.exe HammerDB CLI v6.0 Copyright © HammerDB Ltd hosted by tpc.org 2019-2026 Type "help" for a list of commands Initialized Jobs on-disk database C:/temp/hammer.DB using existing tables (274,432 bytes) hammerdb>
Job output can be returned as text or JSON. JSON is useful for automation, while text is easier for manual inspection.
hammerdb>jobs format text Setting jobs output format to text hammerdb>jobs format JSON Setting jobs output format to JSON
If the jobs repository is not required, it can be disabled and then re-enabled later. HammerDB must be restarted after changing this setting.
hammerdb>jobs disable 1 Disabling jobs repository, restart HammerDB to take effect hammerdb>jobs disable 0 Enabling jobs repository, restart HammerDB to take effect
When jobs are disabled, jobs commands return an error until jobs are re-enabled and HammerDB has been restarted.
hammerdb>jobs Error: Jobs Disabled: enable with command "jobs disable 0" and restart HammerDB
Timing profile data can be stored with jobs output. If timing data should not be stored, set xt_job_storage to 0 in the timeprofile generic configuration.
hammerdb>giset timeprofile xt_job_storage 0 Changed timeprofile:xt_job_storage from 1 to 0 for generic
The jobs command has the following functionality. The job command remains an alias for jobs.
Table 9.3. Jobs command
| jobs | List all jobs. |
| jobs [jobid|joblist|result|timestamp] | Show output for a jobid, return a compact text job list, list results for all jobs or list starting timestamps for all jobs. |
| jobs format [ text | JSON ] | Set job command output format to text or JSON. |
| jobs disable [ 0 | 1 ] | Enable or disable storage of job output after restart. |
| jobs profileid [ id ] | Return the current performance profile id, set the current performance profile id, or use id of all to show previously used profile ids. |
| jobs profile [ id ] | Return the results for the selected performance profile id. |
| jobs diff basepid comppid [true|false] | Compare two performance profiles. The basepid is the baseline or reference profile. The comppid is compared relative to the baseline. The optional true or false argument controls weighted comparison mode. |
| jobs jobid [bm|db|delete|dict|metrics|result|save|status|system|tcount|timestamp|timing|vuid] | Query an individual job. Options show the benchmark, database, configuration dictionary, metrics, result, status, system data, transaction count, timestamp, timing summary or virtual user output. The delete option removes the job. The save option writes an AI-friendly job report JSON file to TMP. |
| jobs jobid timing vuid | Show timing data for an individual virtual user. |
| jobs jobid getchart [result | timing | tcount | metrics | profile | diff:pid] | Generate an HTML chart for result, timing, transaction count, metrics, performance profile or profile comparison data. |
A timed workload returns a jobid when the workload is started with vurun. The jobid can then be used to query the result, configuration, status, timing, metrics and other stored output.
hammerdb>set jobid [ vurun ] Benchmark Run jobid=67FD3C792EF803E253533323 hammerdb>jobs 67FD3C792EF803E253533323 result [ "67FD3C792EF803E253533323", "2026-06-24 10:15:34", "32 Active Virtual Users configured", "TEST RESULT : System achieved 400301 NOPM from 932861 SQL Server TPM" ]
The status option returns the stored status output for the job. In text format this is shown as readable virtual user status lines. In JSON format the same data is returned in structured form for scripts.
hammerdb>jobs format text hammerdb>jobs 67FD3C792EF803E253533323 status Vuser 1:RUNNING Vuser 2:RUNNING ... Vuser 1:FINISHED SUCCESS ALL VIRTUAL USERS COMPLETE
The dict option shows the configuration dictionary used for the job. The result, tcount, timing and metrics options show the captured benchmark result, transaction counter data, response-time profile and operating system metrics respectively.
hammerdb>jobs 67FD3C792EF803E253533323 dict hammerdb>jobs 67FD3C792EF803E253533323 tcount hammerdb>jobs 67FD3C792EF803E253533323 timing hammerdb>jobs 67FD3C792EF803E253533323 metrics hammerdb>jobs 67FD3C792EF803E253533323 system
The save option writes a report-oriented JSON artifact for the job. This is intended for automation, reporting and sharing workflows where a single structured job artifact is more useful than individual CLI queries.
hammerdb>jobs 67FD3C792EF803E253533323 save Saved job report JSON to /opt/hammerdb-ci/TMP/hdb_67FD3C792EF803E253533323.json
Performance profiles are also stored in the jobs repository. Use jobs profileid to show or set the active profile id, jobs profile to return the profile data, and jobs diff to compare two profile ids. The getchart option can generate profile and profile comparison charts.
hammerdb>jobs profileid all hammerdb>jobs profile 20260624101534 hammerdb>jobs diff 20260624101534 20260624110321 true hammerdb>jobs 20260624101534 getchart profile hammerdb>jobs 20260624101534 getchart diff:20260624110321
When using the HammerDB web service, job output is displayed in a browser in grouped sections, including output by virtual user. Raw JSON output remains available for automation from the web service, while the CLI jobs command remains the simplest way to query job data directly from a terminal.