Forcing SQL execution plan instability

Maris ElsinsOracle [Applications] DBA

Meetup v2.0

© 2011 Pythian 2

Who I am• 9yOracle: 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

© 2011 Pythian 3

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?

© 2011 Pythian

Lets talk about basics and stability!

4

© 2011 Pythian 5

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

© 2011 Pythian 6

Sample execution planselect 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)

© 2011 Pythian 7

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

© 2011 Pythian 8

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)

© 2011 Pythian 9

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 ...

© 2011 Pythian 10

Why DBAs are not thinking much about execution plan (in)stability?

People get used to frequent performance issuesThere were no good solutions to the problem

..But now it can be changed

© 2011 Pythian 11

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

© 2011 Pythian 12

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

© 2011 Pythian 13

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

© 2011 Pythian

SQL execution plan instability

Forcing optimizer to choose different execution plan

14

© 2011 Pythian 15

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

© 2011 Pythian 16

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...

© 2011 Pythian 17

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

© 2011 Pythian 18

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

© 2011 Pythian 19

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

© 2011 Pythian 20

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