ABOUT ME
KARAN DODWAL (OCM)
Over 8 years of experience with oracle technology
Oracle Certified Master DBA 11G
Oracle Database Architect
Author of OTN Articles
Oracle Certified PLSQL Developer
Oracle Database Instructor http://karandba.blogspot.in/
http://education.oracle.com/education/otn/KDodwal.html
https://www.linkedin.com/pub/karan-dodwal-ocm/2b/b2b/765
Email :- [email protected]
AGENDA
Issues faced in the past without SPM
What is SPM
Architecture of SPM
Why use SPM
Managing SPM
Transporting SPM
Upgrade Strategies
Whats new in 12C
Best Practices
SCENARIO 1
Poor performance
Dev Team Complaints
DBA analysis :- Bad Plan
Suggestion :- Hints to fix a plan ???
Dev Team :- Fix the problem without changing
the source code
SCENARIO 2
Poor performance
Dev team complaints
DBA analysis :- Bad Plan
Cause :- Statistics
Dev Team :- Kindly Fix the problem
SCENARIO 3
Poor performance
Dev team complaints
DBA analysis :- Bad Plan
Cause :- SQL Profile
Dev Team :- Kindly Fix the problem
SCENARIO 4
Poor performance of few SQL post upgrade
Lets say 10G to 11G
Dev team complaints and asks has the upgrade
caused the slowness ?
DBA Team :- Speechless
Cause :- Optimizer Version Change
Dev Team :- Lets have a con call
COMMON REASONS OF PLANS CHANGE
New optimizer version
Changes to optimizer statistics
Changes to optimizer parameters
Changes to schema
Changes to system settings
SQL profile creation
SO WHATS WRONG WITH STORED OUTLINES ?
Forcefully use an execution plan
Uses hints
Preferred over SPM when use_stored_outlines
is true
Not a good approach
Should be migrated to SPM
SPM V/S SQL PROFILES
SQL Profiles are reactive
SPM is Proactive
SPM reproduces a specific plan
SQL Profile corrects CBO Estimates
SQL Profiles don’t guarantee plan stability
SPM provides plan stability
SQL PLAN MANAGEMENT (SPM)
Introduced in 11G
Preserves the performance
Only accepted plans are used
New plans are saved for future evolution
Enhanced in 12C
Whole idea is to avoid using new plan
SPM BASELINES
Proactive and a Conservative Approach
Guarantee execution plan stability
Only accepted/verified plans are used
Enforce specific plans
New plans are stored in Plan History
Purges history according to retention
CONTROLLING SPM BASELINES
OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES
OPTIMIZER_USE_SQL_PLAN_BASELINES
DBMS_SPM
LOADING PLANS IN BASELINES
From Cursor Cache
From Sql Tuning Set
Migrate from Stored Outlines
Unpack from Staging Table (Using STS)
DISPLAY THE BASELINES
Package DBMS_XPLAN has a function called
display_sql_plan_baseline:
select * from table (
dbms_xplan.display_sql_plan_baseline (
sql_handle=>'SYS_SQL_9804ihk4287d3257',
format=>'basic')
)
FIXING A PLAN
dbms_spm.alter_sql_plan_baseline (
sql_handle => ‘SYS_SQL_9804ihk4287d3257’, plan_name => ‘SYS_SQL_PLAN_8421adga5ha456’, attribute_name => 'fixed',
attribute_value => 'YES')
• Fixed plan will be given priority
• More than one plan can be fixed
• In that case optimizer chooses the best from them
• To make a plan“unfix”, use attribute_value => ‘NO'
MIGRATE FROM OUTLINES
SQL> variable v clob
SQL> execute :v :=
dbms_spm.migrate_stored_outline
(attribute_name=>'outline_name',
attribute_value=>
'SYS_OUTLINE_14090100280772402',
fixed=>'NO');
DICTIONARY VIEWS
DBA_SQL_PLAN_BASELINES
Columns :-
accepted, enabled, fixed, last_verified
DBA_SQL_MANAGEMENT_CONFIG
Columns :-
parameter_name, parameter_value
MORE INTERNAL DICTIONARY OBJECTS
Oracle Performs merge for SPM on following
# SQLOBJ$
# SQLOBJ$DATA;
# SQLOBJ$AUXDATA
# SQLLOG$
METHODOLOGY
Export the staging table stg1 into a flat file
using the export command or Oracle Data
Pump.
Transfer the flat file to the target system.
Import the staging table stg1 from the flat file
using the import command or Oracle Data
Pump.
LICENSING SPM
SPM is available as part of EE 11g/12C
Tuning pack involves auto plan evolution(12c)
Interaction with Tuning Advisor requires tuning
pack
Tuning pack or RAT pack required to load from
Sql Tuning Set into SPM
NEW AUTO EVOLUTION TASK
New task SYS_AUTO_SPM_EVOLVE_TASK
Runs in nightly maintenance window
Poor plans stay for 30 days only if sql is active
Use dbms_Spm.report.auto_evolve_task to
view results of auto job
Auto plan evolution is part of tuning pack
SPM EVOLVE ADVISOR TASK (DBMS_SPM)
CREATE_EVOLVE_TASK
EXECUTE_EVOLVE_TASK
REPORT_EVOLVE_TASK
IMPLEMENT_EVOLVE_TASK
SET_EVOLVE_TASK_PARAMETER
SQL MANAGEMENT BASE ENHANCEMENT
In Oracle 12C plan rows are persisted to sysaux
tablespace, so when
dbms_xplan.display_plan_baseline is run, you
fetch plan data from SMB rather than compiling
the sql statement with baseline.
UPGRADING STRATEGY
Before upgrade pack 10g plans into STS
After upgrade load plans from STS to SPM
Use 10G Statistics until the system is stable
Use pending statistics feature
Alternatively export stats from prod and import them in test
After upgrade and before stats gather switch on incremental stats for all partitioned tables
BUG 11719151 SPM CAPTURE CAUSES
SLOWNESS
Confirmed Version affected 11.2.0.2
Waits for "library cache: mutex X“
Merge slow over following tables :-
sqlobj$ , sqlobj$data, or sqlobj$auxdata
Issue is fixed in 11.2.0.3 (Server Patch Set)
BEST PRACTICES FOR EXECUTION PLANS
When upgrading use STS for loading plans in SPM
Gather stats after data is loaded & before indexes are created
Parallel execution should be leveraged
Use pending stats feature to minimize risk
Export statistics from PROD and import them to TEST
Get all good plans in STS and accept them all
Upgrade to 12C to leverage adaptive plans and many more
Review the plan evolution report for critical SQL’s