How Automatic SQL Plan Management Works
Oracle 11g New Features Tips by Donald BurlesonJune 28, 2015
Oracle 11g New Features Tips
In version 10g, Oracle
has introduced the new mandatory
SYSAUX tablespace. It is the default
location for a number of tools which had their own tablespaces
before 10g, such as Oracle Text, Ultra Search, and Statspack and
some more. These tools tablespaces have all been consolidated into
the SYSAUX tablespace per default.
Also with version 10g, Oracle has
introduced the Automatic Workload Repository (AWR), which is a kind
of data warehouse for historical performance statistics. Oracle 10
creates performance snapshots in memory statistics from the SGA per
default every one hour and retains them in the AWR for seven days if
these settings are not adjusted.
There are historical statistics
about waits and resource consumption in the database, even across
shutdown and startup operations. Beside the AWR in an 11g
database, another structure is located in the SYSAUX tablespace. It
is a special infrastructure which is called
Management Base (SMB). It
holds the SQL Plan Baselines as well as SQL Profiles which are
created by the SQL Performance Analyzer that is implemented with the
package DMBS_SQLTUNE. Sql Profiles were introduced with
Oracle 10gR1. In an Oracle 10g database, they are stored in the
SYSTEM tablespace. There was no such thing as SMB in 10g.
SQL profiles are a reactive method for fixing performance problems
of SQL statements. In 10g this is always done manually by the DBA.
As of 11g, Automatic SQL Tuning happens
every night via an automatic task job if the choice is to allow the
server to not only create SQL Profiles but also implement them
automatically. This will be covered more at the end of this chapter.
the SYSAUX tablespace is offline in 11g, this can cause significant
performance impact because needed SQL Profiles are not
accessible. This could not happen in 10g!
Another reactive method to implement plan
stability is the use of Stored Outlines.
For backward compatibility, Oracle uses existing
stored outlines. A plan generated using a stored outline is not
stored in the SMB even if automatic plan capture is enabled for the
session. Stored Outlines have been deprecated in 11g and have been
replaced by SQL plan management features.
Also beginning in 11g,
a SQL Log
for all statements as well as a SQL Plan History for repeatable SQL
is maintained in the SMB by the optimizer along with the SQL plan
By default, Oracle uses SQL plan baselines but
does not automatically capture new plans.
Schematic of SYSAUX Tablespace
The above graphic shows the AWR and the SMB in
the SYSAUX tablespace. This tablespace must be created with
Automatic Segment Space Management (ASSM)
enabled to allow automatic purging tasks to maintain the SMB.
If the SYSAUX tablespace is offline, the optimizer cannot maintain
the SQL Log and the SQL Plan History and cannot use SQL Plan
Oracle uses two new parameters to
manage the SMB:
LUTZ AS SYSDBA @ orcl11g SQL> show parameter
It is possible to feed SQL execution
plans manually into the SQL plan baselines. By this, an execution
plan can be fixed and thus force the optimizer to use it. The manual
SQL plan maintenance will be reviewed later in this chapter.
to FALSE disables SQL Plan
optimizer_capture_sql_plan_baselines to TRUE enables
automatic capturing of SQL plans.
Both parameters are
SYSDBA @ racdb11g1 SQL> ALTER SYSTEM SET
From now on, the optimizer starts capturing SQL
execution plans automatically. A list of SQL_IDs, or the SQL log, is
used to check if a statement has been executed before.
If a statement is parsed for the first time, its
SQL_ID gets inserted into the SQL log in the SMB. For each statement
which is executed multiple times, the optimizer starts maintaining a
SQL plan history. There is a plan history for every repeatable SQL
statement in the SMB.
The plan history includes all relevant
information the optimizer has used to produce an execution plan and
thus makes it reproducible. The information in the plan history
includes the following:
When a statement is
parsed, the optimizer creates a best cost plan using object
statistics from the data dictionary for the new statement. If it is
parsed the first time, a
SQL plan baseline
is also created in the SMB for the new statement. The next time, the
same statement is reparsed for whatever reason, so again a best cost
plan is created. Before this plan can be used, the optimizer first
checks if the same plan has been created before and if it is in the
statements plan baseline. If this is the case, the statement is
executed with this plan. Subsequently created differing plans for
the same statement are added to the plan history
and marked for verification. They have the status ENABLED
but not ACCEPTED and cannot be used for execution as long it has not
been checked if they do not cause performance regression.
The verification is a task which can be
performed manually by the DBA. It is called SQL plan evolution. It
will be shown later that this can also be made manually using
dbms_spm.evolve_sql_plan_baseline. The plan baselines can also
be loaded manually from the cursor cache or SQL Tuning Sets. Only
plans with status ENABLED and ACCEPTED are part of the SQL plan
baseline. All other plans are part of the plan history.
SQL plan evolution can also happen
automatically via a new automatic maintenance task. Oracle runs an
automatic SQL tuning job every night which can create SQL Profiles
automatically and implement them, therefore populating SQL plan
baselines. This will be covered more at the end of this section.