What's difference between SQL profiles and SQL plan baselines. But first let's briefly recap each feature.
Programmers add hints to SQL query to give direction to the Optimizer. Both SQL Profiles and Baselines are nothing but collections of stored hints that “attach” to their target SQLs.
Both SQL Profiles and SPM Baselines are designed to deal with the same problem "Optimizer sometimes produces a very inefficient execution plan", and they are both doing it by essentially abandoning the idea that “all SQLs are created equal”. Instead, another idea is put forward “Some SQLs are special and deserve individual treatment”.
The way they are implemented, both SQL Profiles and SPM Baselines are:
- External objects that contain additional “magic” information for the optimizer
- Attached to individual SQLs and influence them only
- Built by actually running the SQL and using feedback from runtime engine
What is the “magic” contents that profiles and baselines use to influence SQL execution plans ?
Based on hint contents, there are some major differences in SQL influence “mechanics” between SQL Profiles and SPM Baselines:
- SQL Profiles (“Soft power”) are mostly ADVISORS that work with the Optimizer making its estimations more precise
- SPM Baselines (“Hard Power”) on the other hand are ENFORCERS. They completely ignore the Optimizer and simply tell the runtime engine what to do
Is there any difference in purpose ?
Now that we’ve seen the actual contents of both SQL Profiles and SPM Baselines, let’s talk about their purpose.
SQL Profiles were designed to correct Optimizer behavior when underlying data do not fit anymore into its statistical (and simplistic) world view. Their goal is to create the absolute best execution plan for the SQL by giving the very precise data to the optimizer. In other words, SQL Profiles are all about “ON THE SPOT” SQL PERFORMANCE.
Baselines, on the other hand are different. They were designed to prevent execution plans from changing uncontrollably and their goal is to only allow execution plans that were proven to be efficient. In other words, SPM Baselines are all about LONG TERM STABILITY.
Baselines know what plan they are trying recreate and SQL Profiles do not. SQL Profiles will blindly apply any hints it has and what you get is what you get. Baselines will apply the hints and if the optimizer gets the plan it was expecting, it uses the plan. If it doesn't come up with the expected plan, the hints are thrown away and the optimizer tries again (possibly with the hints from another accepted Baseline).
Profiles have a “force matching” capability that allows them to be applied to multiple statements that differ only in the values of literals. Think of it as a just in time cursor sharing feature. Baselines do not have this ability to act on multiple statements.
Can Baseline be disregarded?
Baselines can be rejected in the underlying objects (“indexes”) were missing. Baselines can be disregarded, even without such extreme conditions as a specified index having been removed. The reason for this is that Baselines attempt to apply enough hints to limit the choices the optimizer has to a single plan, but there are situations where the set of hints is not sufficient to actually force the desired plan. What I mean is that the hints will eliminate virtually all possibility, but there still may be a few that are valid and so it’s possible to get a different plan. In fact, there are situations where the act of creating a Baseline causes the plan to change. This is clearly not intended behavior, but it can happen. At any rate, in these cases where the optimizer arrives at a different plan than was expected, the optimizer uses a plan generated completely without the hints (or possible picks another accepted Baseline and applies it’s hints). This behavior is very different from SQL Profiles which blindly apply the hints.
Note: SQL Profiles can also be created manually with the same set of hints that would be used in a Baseline and there is a MOS note regarding how to do this.
SQL query to get SPM baseline.
SQL> select count(*) from dba_sql_plan_baselines where parsing_schema_name='$1';