Have
you ever experienced performance regressions because of some drastic changes in
the execution plan? If so, then we have brought to you a smart solution known
as SQL Plan Management (SPM). SQL plan management Oracle is a deterrent
mechanism that allows the optimizer to automatically handle execution plans
while assuring that the database utilizes only verified and known plans.
The
execution plan mainly changes because of several system changes. For instance,
you might have changed a few optimizer-related parameters or updated stats for
some objects manually or automatically. The more substantial change is the
database upgrade. These changes can lead to the generation of new execution
plans for many of your SQL statements. While some new plans are improvements,
some of them are worse that leads to performance regression.
SQL Plan Management (SPM)
SPM
enables database users to manage stable yet optimal performance for a set of
SQL statements. Further, it incorporates the positive features of plan stability
and adaptability, while simultaneously dodging their shortcomings. SPM has two
key objectives:
●Offering
performance improvement by gracefully accepting database changes, and
●Preventing
performance regressions in the face of any changes in the database system.
A
managed SQL statement has an enabled SPM system. SQL
plan management Oracle can be controlled manually either partially or
wholly or be configured to work automatically. SPM prevents performance
regressions by allowing the detection of plan changes for managed SQL
statements. For this purpose, SPM manages, on disk, a plan history that
comprises distinct execution plans generated for every maintained SQL
statement.

The
SPM aware optimizer doesn’t pick a brand new best-cost plan. Instead, it picks
from a set of accepted plans called an SQL plan baseline that represents a
subset of the plan history. These accepted plans have been either designated to
hold good performance or verified to not cause a performance regression. A
brand new plan is combined with the plan history as a non-accepted plan. Later,
an SPM utility determines its performance and holds it as an accepted plan if
it improves the performance or as a non-accepted plan if it reduces the
performance.
The
plan performance verification method ascertains both plan adaptability and
stability. A SQL plan baseline can be created in several ways-
1. Using
a SQL Tuning Set (STS);
2. From
the cursor cache;
3. Using
a staging table; and
4. Automatically.
SQL plan baselines from STS
If
you are upgrading your Oracle Server, you might have an existing STS containing
some or all your SQL statements. This STS might include a plan that works
satisfactorily.
SQL Plan Baselines from the Cursor Cache
For
any cursor that is present in the cache, SQL plan baselines can be
automatically created. This lets you create SQL plan baselines for all every
statement whose text is similar to the specified string. Various overloaded
variations of such function enable you to filter on other cursor features.
SQL plan baselines using a staging table
If
you have SQL plan baselines, you can export them to another system. Firstly,
create a staging table and pack the SQL plan baselines you need to export. This
will pack all SQL plan baselines for statements that match the certain filter.
MY_STGTAB, the staging table is a regular table that you must export to the
production system with the use of Datapump Export.
On
the production system, for creating the SQL plan baselines, you can now unpack
the staging table. You must note that the filter for unpacking the staging
table isn’t mandatory, it’s optional. Plus, it may be distinct from the one
utilized during packing which implies that various SQL plan baselines can be
packed into a staging table and selectively unpack only a subset of them on the
target system.
Creating SQL plan baselines automatically

By
now, we expect that you have understood how SQL plan management oracle can be
used to create SQL plan baseline. Also, SPM is one of the best oracle SQL
query optimization techniques that avoid performance regression.