I got it! YES what i exactly meant is “Automatic Plan Evolution of SQL Plan Management” which is abviously an interaction between the SQL Tune Advisor’s nightly tuning task and SPM!! which would be proceeded through DBMS_SQLTUNE sub routines and requires tuning pack lisence (what we own!).
My questions are:
1)would you mean it is preferable to use DBMS_SQLTUNE once we got the Tunung Pack lisence for an autom. evolve process?
2)obviously SPM requires much more DBA manually works rather than DBMS_SQLTUNE, true?
3)can you recommand any oracle docu which describes more about the interactive engine of both features?

Many Thanks!
Alireza

Thanks!
Alireza

1. I’m assuming you are asking: “what if ACCEPTED SPM baseline is using an index and you remove the index” ?
The way SPM works is: it tries to reproduce the plan from baseline during parse. If it cannot (i.e. if the index is not there), it cannot use this plan, even if it is ACCEPTED and needs to either try other ACCEPTED plans from baseline or parse a new one.
The plan with the index remain ACCEPTED, I believe (did not check on that) but will not be used.
Keep in mind that you can have several ACCEPTED plans for the same statement and ORACLE can choose between them during parse. ACCEPTED does not mean BEST, nor does it mean THE ONLY ONE that can be used. Rather it means: it was approved at some point (which you can do manually, btw)

2. SPM is not a part of diagnostic license – it is available as a part of enterprise edition. What you are probably thinking about is DBMS_SQLTUNE package, which deals with profiles (close cousins to baselines), and does require tuning pack. It has a job that looks through sqls and finds profile recommendations as well as evolve baselines. But it is not necessary if you only want to evolve baselines – you can create your own “evolve” script quite easily.

Speaking of upgrades. You want to be real careful here. I think the main benefit of SPM during upgrades is the fact that you can “freeze” plans, not so much that you can make them better. While it is nice to improve the plans after upgrade, to me it is much more important not to make them worse … Unfortunately SPM evolution can do both.
What is, arguably, even worse, it can also populate baselines with several ACCEPTED plans for the same sql, meaning that your sql will execute sometimes with plan A and sometimes with plan B. These plan flips can be disastrous if your users are relying on stable execution of that sql (there are ways to fix it by i.e. working with ENABLED attribute, but it’s better not to have this problem in the first place).

So, be extra careful with auto evolutions – they can do both good and bad.

Regards,
Maxym Kharchenko

There could be multiple reasons.

First of all, look at the v$sql.SQL_PLAN_BASELINE field for your query cursor to see what/whether baseline is actually used (it will be empty if it’s not) or running dbms_xplan on your cursor and looking at the “notes” section. Depending on the results you can look deeper by i.e. dumping 10053 trace and seeing why baseline was (not) chosen.

I’m not sure that scenario 1 is strictly about baseline attributes, such as FIXED.

My point is: indexes can be ignored, because baselines require EXPLICIT operations (which is a bit weird).

I.e. if you have a baseline on your query that uses a full table scan and then you add an index, ORACLE will not automatically switch to using that index, even though a new plan with the index will likely be generated and be vastly more efficient.

You have to do something to enable the new plan, by either evolving it or simply forcing it (or dropping the baseline).

As for FIXED attribute, it can be used to force the plan that you want (again, explicitly), but I found it to be somewhat unreliable, so I’m always forcing the plan by disabling all the other plans in the baseline (through ENABLED attribute).

Cheers,
Maxym Kharchenko

Thanks