terminate option in second run

SQL Optimizer SQL Optimizer for Oracle
1

SQL Optimizer 9.2.2.270

Add 5 scenarios and some number of bind sets.

Run all 5 of them with option toi terminate according 110% of all time against original one

Finish testing.

Save

Close Optimitzer

Open same test and now check original and only other 1-2 others.

Now there is no same termination policy as it was run on first run?.

Why?

2

Hi Damir,

Some options are for all SQLs and only be shown when you test run all SQLs. If you want to run selected SQLs or non-tested SQLs, you will not see these options.

Regards,

Ken

3

Hi Ken,

Thx for your reply, I see that …but why is taht so? What is the logic behind?
Brg
Damir

4

Hi Damir,

Some options need compare to all SQLs that cause it can only be shown when select all SQLs to test run.

Regards,

Ken

5

Hi Ken,

Thx for your reply, but cannot understand why we cannot make some “summary time” as a treshold to stop testing scenario.

Imagine that you have 1200 bind sets (like I have) and need to prevent that any further scenario goes beyond some time in total. For that was 110% option nice, but in this case when I resume testing I cannot use it.
Do you understand where do I point to now?
Brg
Damir

6

When we design the bind values test, we have considered the same question. Should we provide same termination criteria when test run in difference lots. As you know it cause more factors to impact the test run result, which most of user may not be notify. To play safe, we remove the option of original SQL run time percentage termination. And we believe there is workaround to take the User-defined time to do termination.

I understand it may cause a bit inconvenience to the user. But it also very hard for us to design what will be better for them. I appreciate your feedback to help us improve the product.

Thanks,

Tony Ng

7

Hi Tony,

Thx for your reply.
Now look from mine perspective (and I see on some users site as well).
Scenarios are tested against 800 bind sets.
They include various combinations with huge difference of LIO and this is the main problem-some scenarios runs fast for one group of bind set while on other group they are bad. I know this is data problem, but explain you the real case.
They are split in test execution because all should be tested in specific time. This is important because some indexes they use are under heavy pressure in that tim3 so “best query” plan may be inefficient in particular moment of execution, because other processing in the database.
So when I resume, I have to open best scenario test case until that moment, export data in Excel and summarize the time of best solution and then put that number in terminate dialog. This is tedious work.

So please, if you do not want to change termination part, at least put next columns in result grid :

  • total elapsed time (for all bind set) for each scenario that was already run
  • total LIO (for all bind set) for each scenario that was already run
  • start and end time for each scenario that was already run (when test starts and when ends)
    This would be also a solution. I hope i have clear up mine case.

Brg
Damir Vadas

8

Thanks for your suggestions.

To change the termination criteria and add in more testing summary information also fine for us. We will create a case as an enhancement in next release.

Thanks

Tony Ng