11g 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 SQL 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.

M If 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 baselines.

By default, Oracle uses SQL plan baselines but does not automatically capture new plans.

Figure 26: 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 Baselines.

Oracle uses two new parameters to manage the SMB:

• optimizer_capture_sql_plan_baselines

• optimizer_use_sql_plan_baselines

LUTZ AS SYSDBA @ orcl11g SQL> show parameter plan_base 

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_capture_sql_plan_baselines boolean     FALSE
optimizer_use_sql_plan_baselines     boolean     TRUE

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.

M  Setting optimizer_use_sql_plan_baselines to FALSE disables SQL Plan               Management.

M Setting optimizer_capture_sql_plan_baselines to TRUE enables automatic              capturing of SQL plans.

Both parameters are dynamically changeable:

LUTZ AS SYSDBA @ racdb11g1 SQL> ALTER SYSTEM SET optimizer_capture_sql_plan_baselines= TRUE;

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:

• SQL text

• outline

• bind variables

• compilation environment

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.