Oracle DB 19c: SQL Tuning Using SPM

Oracle OpenWorld 2019
S A N F R A N C I S C O
Copyright © 2019 Oracle and/or its affiliates.

Oracle Database 19c: SQL Tuning Using Plan
Stability Methods SPM and SQL Quarantine
Soumendra Paik
Senior Principal Technical Support Engineer
Oracle Support Services, DB Performance Team, USA

The following is intended to outline our general product direction. It is intended for information purposes
only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code,
or functionality, and should not be relied upon in making purchasing decisions. The development,
release, timing, and pricing of any features or functionality described for Oracle’s products may change
and remains at the sole discretion of Oracle Corporation.
Statements in this presentation relating to Oracle’s future plans, expectations, beliefs, intentions and
prospects are “forward-looking statements” and are subject to material risks and uncertainties. A detailed
discussion of these factors and other risks that affect our business is contained in Oracle’s Securities and
Exchange Commission (SEC) filings, including our most recent reports on Form 10-K and Form 10-Q
under the heading “Risk Factors.” These filings are available on the SEC’s website or on Oracle’s website
at http://www.oracle.com/investor. All information in this presentation is current as of September 2019
and Oracle undertakes no duty to update any statement in light of new information or future events.
Safe Harbor

Agenda
• Brief overview of SQL Plan Management (SPM) and SQL
Quarantine (SQ) features
• What Plan Stability methods are available in EE/SE DBs
• How Plan Stability methods are implemented in 19c
• What to do if SPM is not usable as a plan stability method
• How SQL Quarantine feature compliments SPM

SQL Plan Management (SPM) in 19c
• Cost-based Optimizer hard parses a SQL statement to generate an execution plan
• Optimizer uses various inputs to come up with a cheapest cost plan
 Object statistics, column statistics and histogram, extended statistics, system statistics,
optimizer related parameter settings, optimizer bug fixes, bind variable values, etc.
 SQL statement is uniquely identified by a SQL_ID starting Oracle 10g
• For various reasons, including DB Upgrade, the execution plan of a SQL can change
and can lead to a sub-optimal execution plan and slower performance
• When a SQL uses bad performing plan, we need a way to control it
 Using a SQL Plan Baseline of SPM feature is one such option

• SPM feature was introduced in Oracle 11g
• Only a small set of SQLs may regress over time in same release or when
Database is upgraded to a newer version like 19c
• SPM uses a mechanism called SQL Plan Baseline using three steps:
 Plan Capture
 Plan Selection
 Plan Evolution
• SQL Plan Baseline captures one or more execution plans for a SQL_ID
• SPM has been enhanced to store Execution Plans starting 12c for plan
comparison when the baseline plans cannot reproduce any more

• SPM is not the only method available to provide plan stability
for a SQL statement
• DBA_SQL_PLAN_BASELINES view uses SIGNATURE but not
all views have Signature column in them
 GV$SQL has SIGNATURE while DBA_HIST_SQLTEXT does not have it
 SQL_ID is universally used to uniquely identify a SQL in AWR reports, etc.
 You may have to generate SIGNATURE value from SQL Text in some cases
 Same plan can be used by multiple similar SQLs with bind variables because they may
generate the same SIGNATURE

Plan Stability Methods in 19c Enterprise Edition (EE)
• Plan stability options in Oracle 19c EE:
 SQL Plan Management (SPM) - Preferred SQL plan stability
method
 CoE Profile ( or Custom SQL Profile)
 Stored Outline
 Add optimizer hints non-invasively using SPM
 Add optimizer hints directly in the SQL (invasive method)
 Avoid adding hints explicitly as much as possible
 SPM and CoE Profile DO NOT WORK for an application generating dynamic SQLs (which create
different SQL_IDs) for similar SQLs

Plan Stability Methods in 19c Standard Edition (SE2)
• Use Stored Outline in 18c or 19c Standard Edition and higher
release
• Add Optimizer Hints in the SQL directly
• A single SQL Plan Baseline allowed in Oracle 18c and 19c
Standard Editions (SE2 or DBCS SE)
• You cannot use SQL Profile or CoE Profile in Oracle Standard
Editions

Limitations of Stored Outline for Plan Stability in 19c
• Stored Outline is deprecated in 12c and higher version
 Advantage: Provides plan stability in Standard Edition(SE2)/Enterprise Edition (EE)
 Disadvantage: Stored Outlines cannot evolve over time like SQL Plan Baselines
 Migrate it as a single SQL Plan Baseline starting 18c and in 19c
 Only ONE SQL Plan Baseline supported in SE2/DBCS SE databases starting 18c
 Only one Stored Outline can be active at any time
 Multiple outlines can be created for a SQL_ID but only one can be used at a time
 Each stored outline must be stored under a different category
 Category is set using sqltune_category = DEFAULT (by default)

SQL Profile as a Plan Stability Method in 19c
- It is not a real plan stability method
• A misunderstood feature by a lot of people
• A row estimate corrector to try to get to a better performing plan
 Generated using SQL Tuning Advisor (STA) Tool
 Becomes ineffective over time because of data changes in related objects
 Each SQL Profile is used for a specific SQL statement (SQL_ID)
 Used at Hard Parse time and affects costing of the SQL
 Should be used for a short term workaround
• Plan on using a long term Plan Stability method (SPM or CoE Profile)
• Do not enable a SQL Profile if using SPM or CoE Profile for plan stability

SQL Profile – an Example
- Note the SCALE_ROWS= values in a SQL Profile

CoE Profile as a Plan Stability Method in 19c
- Alternative method to use when SPM is not working
• Developed when Oracle 10g was released by Center of Expertise (CoE )
 Father of SQL Plan Management (SPM) feature
 Available from Oracle 10g to 19c and higher
• Provides plan stability of a SQL when it is regressing with multiple execution
plans
• Very easy to move CoE Profiles from one database to another
• Uses Stored Outline Hints behind the scene
• Do not enable SQL Profile (costing implication) when using CoE Profile

CoE Profile as a Plan Stability Method in 19c – Steps
• Step#1 – Create a CoE Profile Script in SOURCE DATABASE:

CoE Profile as a Plan Stability Method in 19c – Steps
• Step#2 – Implement the CoE Profile in DESTINATION DATABASE:

- Sample Execution plan using a CoE Profile

• To stop using a CoE Profile, either Disable or Drop it:

SQL Plan Management (SPM) for Plan Stability in 19c
• SPM allows the Cost-based optimizer to use an optimal execution plan and to stop
performance regression ( Set Enabled=YES, Accepted=YES)
• Set Enabled=YES, Accepted=YES, Fixed=YES to use one of the baseline plans as the
preferred execution plan
• Allows execution plan to evolve over time
• Helps to use a set of baselines plans after verifying that those plans will not cause
performance regression
• If hints in SPM baseline become invalid and the plan is not 100% reproducible, it will
use another baseline (if available) or use the current best cost plan generated by the
optimizer

• Methods available to create SQL Plan Baselines (Plan Capture):
 Set optimizer_capture_sql_plan_baselines = TRUE (default FALSE)
 Preferably at session level to capture repeatable SQLs and their execution plans
 Capture SQL Plan Baselines from Cursor Cache memory of database SGA
 Capture baselines from AWR repository
 Capture it from SQL Tuning Set
 Pack/Unpack SQL Plan Baselines from one database to another
• Method to use a SQL Plan Baseline for a SQL (Plan Selection):
 Set optimizer_use_sql_plan_baselines = TRUE (by default)
 SPM is not supported for a Distributed SQL as of Oracle 19c

• Example of captured plans for a SQL:
• Enabled and Accepted flags must be set to YES before a baseline can be considered by the
optimizer
• You can have multiple baselines as Accepted for a SQL_ID
• Origin shows how the baseline was captured
• A bit tricky to join DBA_SQL_PLAN_BASELINES with DBA_HIST_SQLTEXT
 Need to generate SIGNATURE from SQL_TEXT

• Example of SPM usage for a SQL statement:

Configuring SQL Plan Management (SPM) in 19c
• Use DBMS_SPM.CONFIGURE to change default configurations for SPM
baseline captures
 Add filters about what SQLs to capture as baselines, for example
 Use other DBMS_SPM APIs to manage different aspects of SQL Plan Baselines
• Automatic SQL Plan Management is a new Feature in 19c
 ALTERNATE_PLAN_SOURCE= AUTO
 ALTERNATE_PLAN_BASELINE= AUTO (default EXISTING in 19.4)
 Adjust task parameters using DBMS_SPM.SET_EVOLVE_TASK_PARAMETER()
 Auto task SYS_AUTO_SPM_EVOLVE_TASK helps to capture the baseline plans

SPM Evolve Task Parameters in different DB Versions
- Note the values for ALTERNATE_* parameters in 19c versus 18c
• SPM Evolve Task Parameter value differences by database versions:

Reasons why SPM is not used by a SQL
• Change in table definition
• Change in index definition (adding more columns to an existing index, for example)
• Unusable indexes
• Making an index INVISIBLE
• Inadvertent dropping of indexes (based on non-usage of indexes, for example)
• A known bug
• Potential bug (will need reproducible testcase and further debugging to determine it)

SQL Quarantine feature in Oracle 19c
• It is a new feature in Oracle 19c
 Helps application SQLs avoid using same bad plan over and over again
 Prevents causing overall performance problem in the system
 Compliments SPM to help with further plan stability of a SQL statement
 DBMS_SQLQ package is used to manage quarantined plans for SQLs
• Automatically adds a bad execution plan to be quarantined for a SQL_ID when
Resource Manager limits are exceeded
• Manually add an execution plan for a SQL_ID to be quarantined as well
• Drop quarantined plan (Quarantine_Name) when it not needed any more

SQL Quarantine feature in 19c
• Move quarantined plans from one database to another using DBMS_SQLQ package
• Add a SQL by SQL_ID or by SQL Text to quarantine a bad plan
• Add a PLAN_HASH_VALUE of a SQL_ID to quarantine
• Adjust quarantine thresholds for an execution plan using DBMS_SQLQ.ALTER_QUARANTINE

SQL Quarantine feature in 19c
• To verify the plan_hash_value added in DBA_SQL_QUARANTINE view:
• To drop and verify dropping of the quarantined execution plan:
• Disable a plan hash value instead of dropping it right away using ALTER_QUARANTINE of
DBMS_SQLQ package

SQL Quarantine feature in 19c – Final comments
• “ORA-56955: quarantined plan used” error if a SQL tries to use a quarantined plan
• Hint /*+ QUARANTINE(ELAPSED_TIME=4294967295) */ always quarantines a
SQL and its plan
• Even if related plan or SQL text not in DBA_SQL_QUARANTINE view
• Restriction: SQL Quarantine feature in 19c works only in on-premise Oracle
Engineered Systems and Exadata Cloud Services (ExaCS) at this time
• There is an undocumented way to test the feature in Oracle 19c EE version
• Set "_exadata_feature_on"= TRUE and restart the database
• This feature is similar to how a SQL_ID and its plan can be quarantined in Exadata
Cell Servers

Reference Documents
• Oracle 19c Database Licensing Information User Manual
• Bug 28945421 - Auto SPM Enhancements (Doc ID 28945421.8)
• Bug 29353271 - Auto Index SPM Evolve Task should not pass Irrelevant Plans to Advisor
Framework Iterator (Doc ID 29353271.8)
• How to Use SQL Plan Management (SPM) - Plan Stability Worked Example (Doc ID 456518.1)
• Loading Hinted Execution Plans into SQL Plan Baseline. (Doc ID 787692.1)

Q&A

Thank You
Soumendra Paik
Senior Principal Technical Support Engineer
Oracle Support Services, DB Performance Team, USA

Oracle DB 19c: SQL Tuning Using SPM

More Related Content

What's hot (20)

Similar to Oracle DB 19c: SQL Tuning Using SPM (20)

Recently uploaded (20)

Oracle DB 19c: SQL Tuning Using SPM