02 03

How to use v sql_plan

The best-cost plan found by the optimizer that does not match any plans in the plan history for the SQL statement represents a new plan, and is added as a non-accepted plan to the plan history. The new plan is not used until it is verified to not cause a performance regression. However, if a change in the system (such as a dropped index) causes all accepted plans to become non-reproducible, the optimizer will select the best-cost plan. Thus, the presence of a SQL plan baseline causes the optimizer to use conservative plan selection strategy for the SQL statement.

Clear as mud?

Now my description:

Baselines are the latest evolution in Oracle’s efforts to allow a plan to be locked.

That gives us the ability to manipulate the text of the SQL statement in order to get the plan we want. Outlines can be tricked into doing something similar by swapping hints between statements. SQL Profiles also can do something similar by using a trick to load the hints from one statement into another (see my previous post for an example). But Baselines have the built-in ability to do this. No tricks, no sneaky stuff, just call the procedure directly and it’s done. Of course the optimizer will have to verify that the plan will work for the statement you attach it to. If it fails this validation step, then the optimizer will ignore it and go on about it’s normal business. The goal has always been to provide the best performance, but until 11g there has not been a mechanism that had as a design goal, the idea of eliminating backwards movement (“performance regressions” as the Oracle documentation calls them). That is, not allowing a statement to switch to a plan that is significantly slower than the one it has already been executing. This new mechanism depends on a construct called a Baseline. So for this post I am not going to focus on the process of evolving plans to prevent “performance regressions”, but rather on the Baselines themselves. (hopefully I’ll get to the plan management part soon)

Here’s a little excerpt from the 11gR1 documentation:

Each time a SQL statement is compiled, the optimizer first uses a cost-based search method to build a best-cost plan, then tries to find a matching plan in the SQL plan baseline.

Not that big of deal since it’s only the 1st execution after the Baseline is created, but it’s a little weird.
  • If a FIXED Baseline cannot be validated, NON-FIXED Baselines will NOT be used. That is to say, if a FIXED Baseline exists, and it cannot be validated, any NON-FIXED Baselines will be ignored. Instead, the normal optimizer costing calculations will kick in to create a new plan. (By the way, validation includes checking to make sure that the plan_hash_value arrived at by applying the hints associated with the Baseline matches the original plan_hash_value. Therefore, a different plan than the original cannot be used – unlike with Outlines and SQL Profiles).
  • Comments

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>