Terminate time in "Bind Values testing"

Hi,
Scenario:

  1. Start test Bind values of “Original” query for several binds.
  2. Then add more scenarios in same test
  3. When Original single run is less than second (let’s say 0.1 sec) then it is not possible to set proper terminate time (limit is one second) for new added scenarios
    So, please allow to set in seconds decimals terminate time or place a valu to define (as it is in original test) percentage of total time to terminate test (could be set in time).
    Brg
    Damir

By now, if Time of execute is less than a second, it will be set as 1 second. It seems not so accurate in calculation. However, termination time would not be pointed at that micro-level in design. We prefer to complete the execution if it will run completed within a seconds.

The termination time is calculated as following:

Termination Time = Time to execute + Delay time

Time to execute is depending on what’s the criteria to apply, however, delay time is defined by user which is from 1 to 999 seconds. This is design for put buffer with network travel time. Or even we issue a break execution command to Oracle, it also take a few seconds to feedback. Based on these factors, the outcome of placing a second decimals termination time seems not significant.

Thanks,

Tony Ng

Hi Tony,
Why you do not have “total time” termination, tha will cover all cases…small and big ones.
I really do not understand why second, postponed run (after original run) cannot have the same termination options like first one?
Brg
Damir

Does the “Total time” mean execution time for a scenario with all bind sets? If so, we have already worked on this way. In other words, the termination time which is based on the sum up of all bind sets on one SQL.

Thanks,

Tony Ng

Yes.

This was mine proposal almost one year ago…so thought it is lost somewhere in plans…

:slight_smile:

I am sorry if I miss anything from this topic because I think it was already completed.

If you have any other question, please feel free to ask.

Thanks,

Tony Ng