I presented on how to force a SQL to start using a different execution plan at LVOUG meetup #2 in 2011.

1. Forcing SQL execution
plan instability
Maris Elsins
Oracle [Applications] DBA
Meetup v2.0

2. © 2011 Pythian2
Who I am
• 9yOracle: 3y – PL/SQL Developer, 6y – Oracle [Apps] DBA
• Certificates: 10g OCM, 9i/10g/11g OCP, 11i Apps DBA OCP, 11i
SysAdmin OCE
• Working for Pythian since 07.2011
• Conferences:
• : 2007/2008/2010/2011
• : 2009/2010
• OUG Harmony : 2010/2011
• How to find me?
• http://www.pythian.com/news/author/elsins/
• http://appsdbalife.wordpress.com/
• http://lv.linkedin.com/in/mariselsins
• http://education.oracle.com/education/otn/melsins.html
• @MarisElsins

3. © 2011 Pythian3
Agenda
• Let’s talk about basics and stability at first
• Introduction about SQL execution plans
• Why do execution plans change?
• Why DBAs should be thinking about plan (in)stability?
• What plan stability features are available?
• SQL Plan Management (Baselines)
• SQL execution plan instability
• Why we would like to cause instability of execution
plans?
• How to «help» oracle to choose different execution plan?
• How to force oracle to use the plan which we know is
better?

4. © 2011 Pythian
Lets talk about basics and
stability!
4

5. © 2011 Pythian5
What is the «execution plan»?
• Set of detailed instructions on how to execute the
DML statement
• The instructions determine execution decisions like:
• In what order the tables (data sets) will be accessed
• What will be the access path (table scan/index)
• What will be the access method (index range scan / )
• How the data sets will be joint (HJ/NL/MJ)
• What/when set operations will be applied (union/minus/...)
• ... ~30 different operations available ...
• Each valid DML statement has an execution plan
• Execution plan is built by Optimizer during SQL parse
phase

6. © 2011 Pythian6
Sample execution plan
select o.order_date, i.product_id, i.unit_price, i.quantity
from orders o, order_items i
where i.order_id=o.order_id and o.customer_id=120;
--------------------------------------------------------
| Id | Operation | Name |
--------------------------------------------------------
| 0 | SELECT STATEMENT | |
|* 1 | HASH JOIN | |
| 2 | TABLE ACCESS BY INDEX ROWID| ORDERS |
|* 3 | INDEX RANGE SCAN | ORD_CUSTOMER_IX |
| 4 | TABLE ACCESS FULL | ORDER_ITEMS |
--------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("I"."ORDER_ID"="O"."ORDER_ID")
3 - access("O"."CUSTOMER_ID"=120)

7. © 2011 Pythian7
How to find the execution plan?
• DEMO1
• explain plan for select... – be careful!
• select * from table(DBMS_XPLAN.DISPLAY);
• Autotrace – be careful!
• dbms_xplan.display_cursor – this is good!
• Trace file STAT rows – this is good!
• However! Tkprof with «explain» option = be careful!
• Be Careful! = The execution plan might not be the one
that’s actually used at the time of execution
• this is good! = The execution plan is the one that’s
actually used at the time of execution

8. © 2011 Pythian8
Why do execution plans change?
• Execution plans are built by optimizer during hard parse operation.
• Hard parse happens just before execution when:
• The query is not found in the library cache (text of the statement is different)
• The query found in the library cache is semantically different
• The query found in the library cache has been invalidated
• The session settings / features are different
• ...
• It’s imposible to have total control over hard parses
• Following things can impact which plan will be chosen by the
optimizer:
• Optimizer statistics – DEMO2
• Data set
• Configuration
• Bind variables
• ...
• Any guesses on how many causes there are for queries with the same
text to have different execution plans? (v$sql_shared_cursor)

9. © 2011 Pythian9
Why DBAs should be thinking about execution
plan (in)stability?
• Because DBAs hate Mondays.
• Because data change and optimizer makes mistakes.
• Because optimizer behaviour can change after
patching / updates.
• Because bind variable peeking can make you hate
Tuesdays too.
• Because global configuration changes can affect
queries that we don’t want to be affected.
• e.g. pga_aggregate_target and hash joins
• Becuase ...

10. © 2011 Pythian10
Why DBAs are not thinking much about
execution plan (in)stability?
People get used to frequent performance issues
There were no good solutions to the problem
..But now it can be changed

11. © 2011 Pythian11
What plan stability features are available?
• Rule Based Optimizer :D 
• Hints 
• Stop collecting statistics 
• Outlines («Plan Stability» from 8i, not in 12c) /
• Useful to fight issues with individual SQLs (e.g. Bind variable
peeking)
• not good for wide use as the plans are completely locked
• Baselines («SQL Plan Management» from 11g) 
• Provides stability and also the flexibility
• DEMO3 Outlines
• DEMO4 Baselines

12. © 2011 Pythian12
More about Baselines...
• Capturing the baselines
• Automatic1
• OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=TRUE
• 1st baseline is accepted automatically, others are not accepted
• Baseline is automatically created only for the queries that are executed at least 2
times
• DEMO2
• Automatic2
• OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=FALSE
• If the baseline for the SQL exists already and possibly more efective execution plan
is identified
• Manually (DBMS_SPM)
• Load from Cursor cache (filter by schema, module, action)
• Load from Sql Tuning Set (DBMS_SQLTUNE = Tuning Pack)
• Load from AWR (DBMS_SQLTUNE = Tuning Pack)
• All manually loaded baselines are accepted when loaded
• Which baseline is used by optimizer?
• Fixed baseline with the lowest cost
• Accepted baseline with the lowest cost

13. © 2011 Pythian13
Evolving the baselines...
• What Evolving does?
• Compares the performance of new baselines to the best accepted baseline
• Comparison is done by executing sqls (comparing elapsed time, buffer gets,
...)
• If the new execution plan performs better, the baseline is accepted
• Evolving SQL Baselines
• Automatically = SQL Tuning Advisor = Tuning Pack licenses required
• Manually
• By Running DBMS_SPM.evolve_sql_plan_baseline
• By loading the new baselines from the cursor cache.
• SQL Plan Management (Baselines) is one of the TOP new features in 11g

14. © 2011 Pythian
SQL execution plan instability
Forcing optimizer to choose different execution plan
14

15. © 2011 Pythian15
Why we would like to force optimizer to use
different execution plan?
• Typical situations that benefit from ability to force usage
of different execution plans
• Optimizer refuses to generate the most efficient execution plan, we
need to force the usage of our tuned execution plan.
• We have an emergency!
• We have a poorly performin 3rd party application without access to
the source code, we are not able to tune the SQLs.
• Change control process is to painful and long (I’m not suggesting to
skip the testing)
• How do we want to do it?
• We want to affect only the queries we choose
• We want to affect those queries only in the way we choose
• We want flexibility in case situation changes
• We want a supported approach
• We don’t want to cause any downtime
• We don’t want to pay more 

16. © 2011 Pythian16
What features are available to force optimizer
to use different execution plan?
• Preferred approach
• Collect statistics so that they represent the data correctly 
• Tune the query, but don’t use hints
• Other options only when preferred approach is not possible
• Set and lock statistics 
• Adjust settings / init parameters 
• Globally
• Using logon triggers
• Outlines /
• SQL Profiles (EE+Diag+Tuning Packs = $) /
• Provides additional selectivity estimates to the optimizer
• Baselines 
Wait a second, there are copy/paste issues on this slide!
Outlines and Baselines are plan stability features!
...yes, but they can be used for other purposes too...

17. © 2011 Pythian17
Using Outlines to force usage of the execution plan
• Based on «How to Edit a Stored Outline to Use the Plan from
Another Stored Outline [ID 730062.1]»
• Create 2 private outlines
• For current execution plan
• For the wanted execution plan
• Swap private outlines
• Test private outlines
• Make the new outline public
• The method is supported by Oracle and available for versions 9i-
11gR2
• DEMO6

18. © 2011 Pythian18
Using Baselines to force usage of the execution plan
• Similarily to outlines there is an option to swap baselines by
• exporting them to stage table
• updating the data
• importing the modified baseline
• Recently J.Lewis suggested an easier way to build a «fake» baseline
• http://jonathanlewis.wordpress.com/2011/01/12/fake-baselines/
• Use dbms_spm.load_plans_from_cursor_cache to create the baseline
by combining data from 2 different SQLs:
• sql_text from bad SQL
• Sql_id and plan_hash_value from good SQL
• The method is fully supported by Oracle
• DEMO7

19. © 2011 Pythian19
Summary
• Databases change and so do the execution plans
• They can change to better one or worse ones
• There are situation when we need plan stability to
avoid bad surprises
• There are also situations when we want to enforce
different execution plan for particualt SQL
• Till 11g there were no good flexible features for that
• Check out the SQL Plan Management if you’re on 11g+
• Easy to use
• Offers Flexibility
• Available on 11g+ SE/EE
• Be careful with performance management options:
• Easy to do something that requires licensing
• control_management_pack_access

20. © 2011 Pythian20
Pythian Facts
• Founded in 1997, over 14 years
• 130+ employees
• 5 offices in 5 countries
• lots of employees around the world
• Employs
• 6 Oracle ACEs (Including 1 ACE director)
• Several Oracle Masters
• Plenty of technical geeks
• Platinum level partner in the Oracle Partner Network
• Actively supports technical communities via
• Blogging
• Conferences
• SIGs and other events
• Winner of Oracle North American Titan Award for Oracle
Exadata Pythian Oracle Titan Award.mp4