Purpose

Understand the need of SPM

Go through the concepts of SPM

Introduction to various phases of SPM

Take a look at different scenarios of

implementing SPM

Disclaimer

SPM is one aspect of SQL Plan Control (other 2

being SQL Profiles and SQL Patch). SPM is being
presented here.
Content discussed here is primarily applicable for
Oracle Database 11g. Some minor changes might
be needed if you want to apply this learning on
Oracle Database 12c.
Content discussed has many references to Oracle
official documentation and such content is
copyright of Oracle and author doesnt claim to own
the same.

1. SQL Plan can CHANGE anytime?

Plan may change due to:

New optimizer version

Changes to optimizer statistics and optimizer parameters

Changes to schema and metadata definitions

Changes to system settings

SQL profile creation

Earlier ways to fix the plan:

Store outlines (before 11g)

SQL Profiles (11g and later)

Lock statistics

Fixing the plan is not the best approach in long-term.

Plan should be allowed to change but only if it is better than or at par to
current plan. Thats what SPM does (automatically or manually).

2. SPM Components/Stages
Primary view is DBA_SQL_PLAN_BASELINES and management package is
DBMS_SPM.
1. SQL plan baseline Capture:
Create SQL plan baselines that represents accepted (trusted) execution plans
for all relevant SQL statements. The SQL plan baselines are stored in a plan
history in the SQL Management Base in the SYSAUX tablespace.
2. SQL plan baseline Selection:
Ensure that only accepted execution plans are used for statements with a SQL
plan baseline and track all new execution plans in the plan history for a statement.
3. SQL plan baseline Evolution:
Evaluate all unverified execution plans for a given statement in the plan history
to become either accepted or rejected.

SQL Management Base (SMB) Architecture

...

SQL Management Base (SMB) Architecture

...

SMB Architecture...
A typical scenario shown in figure:
a) A single SELECT statement that has two accepted plans in its
SQL plan baseline.
b) The SQL plan history includes two other plans for the statement
that have not been proven to perform well.
The SQL management base (SMB), which is part of the data
dictionary, stores the SQL plan baselines and plan history in the
SYSAUX tablespace.
The SMB also contains SQL profiles.
The SMB uses automatic space management.

3. SQL Plan Baseline (SPB) Capture

Two Primary ways:

Automatic Capture of Execution Plans

Bulk Load of Execution Plans

Automatic Capture of SPB is enabled by setting init.ora parameter

OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES to TRUE (default FALSE).
How?

With this parameter on, each SQL is tracked and any repeatable SQL is populated in
SPM repository.
When a SQL is compiled first time, the optimizer will log the identity (SQL
Signature) into a statement log.
When same SQL is compiled or executed again, it is identified as repeatable SQL,
and hence, a SQL Plan history will be created which will include the information
required to reproduce the execution plan.
Also, current cost-based plan is added as first SPB and this plan will be marked as
accepted.

SPB Capture...

Each SQL can have multiple accepted and unaccepted plans in plan history in
SQL Plan Management base.
But, only accepted/verified plans for each SQL will be part of SPB.

More than one possible accepted/verified plans are possible to be present in SPB
for each SQL. Optimizer chooses best one in runtime.
Accepted means plans which were manually OR automatically accepted to be
good ones.

Unaccepted means plans unverified (newly found but not verified yet) OR
rejected (newly found, verified but not found to be good).

SPB Capture...
Automatic SPB Capture Flow Chart

SPB Capture...
Bulk Load capture is useful when database version is upgraded or when application is
being changed.
This type of capture can be done in 4 ways:
1.Populate the execution plans for a given SQL Tuning Set (STS)
For ex In Oracle 10g, create STS for all or selected SQLs with current plans, load STS
into a staging table and import that table in Oracle 11g, then use EM or
DBMS_SPM.LOAD_PLANS_FROM_SQLSET to load the execution plans into the
SQL Management Base.

2.Populate the execution plans from Stored Outlines

For ex In Oracle 10g or earlier version, create Outlines for all SQLs using
CREATE_STORED_OUTINES to TRUE or for specific SQLs using CREATE
OUTLINE, export OUTLN schema, use EM or
DBMS_SPM.MIGRATE_STORED_OUTLINE to load the Stored Outlines into the
SQL Management Base.

SPB Capture...
Bulk Load capture...
3.

Use the execution plans currently in the Cursor Cache

For ex Starting Oracle 11g, the plans can be loaded using the PL/SQL procedure
DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE or through Oracle
Enterprise Manager.
Mainly useful when SQL of packaged applications can not be changed. In such cases,
plan of a manually modified SQL (say index hint added) can be pushed to be used
for SQL of packaged applications.
4.

Unpack existing SQL plan baselines from a staging table

For ex A product vendor can ship proper SPB along with application in case Oracle
11g is being used. OR, when migrating Oracle 11g databases from one system to
another, SPB also can be migrated.
Programs to be used in this case: DBMS_SPM.CREATE_STGTAB_BASELINE,
DBMS_SPM.PACK_STGTAB_BASELINE,
DBMS_SPM.UNPACK_STGTAB_BASELINE.

SPB Capture...
...

3. SQL Plan Baseline (SPB) Selection

Use of SPB for plan selection is enabled by setting init.ora parameter
OPTIMIZER_USE_SQL_PLAN_BASELINES to TRUE (default value).

How?

Whenever a SQL is compiled, the optimizer first finds the best possible cost-based
plan as usual.
But, with this parameter on, each SQLs plan is matched with SPB. If matching plan
is found in SPB, this plan is used.
If match is not found, then new plan is stored in plan history as unaccepted one and
will not be used for SQL execution.
Rather, best one among the SPB will be used as long as plan is reproducible. If one is
marked as fixed, then that one is preferred to be used. There can be more than one
fixed plans, in that case, best among fixed ones will be used.
If SQL itself is not found in SPB (a very new SQL), then normally generated plan
will be used and this plan will be added in SPB as accepted one (part of capture
phase).

SPB Selection...
SPB Selection Flow Chart

3. SQL Plan Baseline (SPB) Evolution

In this phase, database evaluates the performance of new plans and integrates plans with
better performance into SQL plan baselines. Plans to be evaluated are the ones
which were added earlier as unaccepted plans in selection phase. Refer to attached
xspm.sql

Evolution can be done in 3 ways:

1.

Using Manual Loading When manual capture is done, plans are added as
accepted plans.

2.

Using OEM / DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE 3 Options

a) Accept the plan only if it is better than existing SPB

b) Accept without evaluation
c) Run comparison without accepting the plan
3.

Using STA (SQL Tuning Advisor) STA, if configured so, can automatically
implement recommendations of SQL Profiles which in turn adds the tuned plan to
SPB (given SPB is enabled). However, it does so without comparing with existing
unaccepted plans.

Thank You