counter of failed queries

[sagyvolkov]

I'm testing hammerdb on SQL server using some SDS (Software Define Storage).
I'm doing some resiliency tests for the SDS while running hammerdb (like pulling out a drive or shutting down a node). These actions should create some kind of a period of time where IOs can not complete (for example, if the SDS lost a node, it has to update its metadata so all clients will know where to get another copy of the data), so I'm pretty sure some queries failed or maybe were retried (not that much of an expert on hammerdb), and I'm looking to find a way to show these failures or retries - like a counter to show number of queries that failed/never finished, or number of orders that failed.
is there such a thing?

Other question/option - is there a timeout period where hammerdb did not receive any feedback/IOs from the storage sub-system, but still continue to hold the query as running? (my thought is that maybe there's a parameter that control this and then, for example, only after 60 seconds of no IO interaction, which is very high, will hammerdb fail the query or the test).

I'm running something like:
diset tpcc mssqls_driver timed
diset tpcc mssqls_rampup 2
diset tpcc mssqls_duration 10
vuset logtotemp 1
print dict
loadscript
puts "Run starts..."
vuset vu 3
vucreate
vurun
runtimer 300

Thanks.

[sm-shaw]

Hi,
So HammerDB will not be directly communicating with the storage subsystem. That will be managed by SQL Server, then above this you have the ODBC Driver eg "ODBC Driver 17 for SQL Server" and then above this HammerDB. So when HammerDB makes a request to run a stored procedure if there is an error in that stack it will detected and either resolved or potentially passed back through the ODBC layer to HammerDB to say that the stored procedure call failed. So clearly it is important to check the SQL Server logs first. Also time outs etc are set in the ODBC configuration underneath HammerDB. When an error does reach the HammerDB layer there is a setting "Exit on SQL Server Error" to deal with this eventuality. To set this in the CLI it is the following setting:

hammerdb>diset tpcc mssqls_raiseerror true
Changed tpcc:mssqls_raiseerror from false to true for MSSQLServer

So when set to false (the default) HammerDB will catch and detect the error and print a message but not stop executing, it will just go the next call. If you set RAISEERROR it will call an error which will print the message stop that particular virtual user executing and vustatus will show that it has failed, an example you can find in the driver script is below:

if  {[catch {set resultset [ $neword_st execute [ list no_w_id $no_w_id w_id_input $w_id_input no_d_id $no_d_id no_c_id $no_c_id ol_cnt $ol_cnt date $date ]]} message ]} {
	if { $RAISEERROR } {
error "New Order Bind/Exec : $message"
	} else {
puts "New Order Bind/Exec : $message"
	}

I would suggest in the first instance to set raise error to true and then it will be clear when a virtual user stops from an error. When the behaviour is clearer make sure you have enabled logging and set it to false and then you can count the errors in the logfile. HammerDB takes a scripted approach meaning it would be easy to modify the section above to count the bind/exec errors and the following fetch errors separately to record a count. However as above SQL Server or ODBC may deal with an error without reporting it to HammerDB.
Steve

[sagyvolkov]

Thanks for the reply Steve.
The problem is that I want to capture the failed data, but I also want the run to continue (meaning mssqls_raiseerror should use the default false settings) and it seems that this might not possible. any thoughts?

[sm-shaw]

Hi,
Yes, if set to false if it detects an error you should still get a message printed with the error message, from the line as follows:
puts "New Order Bind/Exec : $message"
However it will not stop with an error. What I would recommend is setting to true first and see if any errors are being reported and stopping the virtual users. If they are then switch to false and enable the logfile. Then you should just see them printed but ignored. The catch statement will catch any errors and these will be stored in the message variable.

[sagyvolkov]

will log file only capture errors or any transaction?

[sm-shaw]

The logfile captures anything that is printed with the "puts" command. There is an option to timestamp every entry. So you are very much in control to log as much or as little as you wish. eg comment out the line shown in the comment above and it won't appear in the log. Similarly you can add more details if you wish with more puts commands.

[sm-shaw]

Closed no further update