LVOUG meetup #2 - Forcing SQL Execution Plan Instability

60 %
40 %
Information about LVOUG meetup #2 - Forcing SQL Execution Plan Instability

Published on March 11, 2014

Author: mariselsins



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

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

© 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? • • • • • @MarisElsins

© 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?

© 2011 Pythian Lets talk about basics and stability! 4

© 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

© 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)

© 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

© 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)

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

© 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

© 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

© 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

© 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

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

© 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 

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

© 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

© 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 • • 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 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

© 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

Add a comment

Related presentations

Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...

In this presentation we will describe our experience developing with a highly dyna...

Presentation to the LITA Forum 7th November 2014 Albuquerque, NM

Un recorrido por los cambios que nos generará el wearabletech en el futuro

Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...

Microsoft finally joins the smartwatch and fitness tracker game by introducing the...

Related pages

Maris Elsins | LinkedIn

View Maris Elsins’ professional ... SQL statements that have different execution plans ... “Forcing SQL execution plan instability” LVOUG Meet-up #2 ...
Read more

Maris Elsins | LinkedIn

The experience I've gained working 3 years as a PL/SQL developer before I became DBA has proven to be very valuable ... (8 years 2 months) Oracle ...
Read more

Unstable Plans (Oracle Plan Stability/Instability)

I noticed two plan_hash_value for a SQL_ID with same execution plan. ... Unstable Plans (Oracle Plan Stability/Instability) ... SQL(in any form) 2) ...
Read more

Multiple column index vs multiple indexes with MySQL 5.6

... Multiple column index vs multiple indexes? ... and shows where we can meet up! ... Execution plan instability is typically very hard to ...
Read more

Great SQL Server Debates: Lock Pages in Memory

If you’d like to learn more about how to troubleshoot memory management issues, or other common problems than afflict SQL Server, check out the free ...
Read more

Kerry Osborne’s Oracle Blog » Blog Archive » SQL ...

This means an Outline always has exactly the same execution plan, but a SQL ... 2 PLAN_HASH_VALUE for the same sql ... Kerry Osborne’s Oracle Blog ...
Read more

Deploying Windows XP Service Pack 2 using Software Update ...

It is also recommended that you plan your Windows XP SP2 deployment so it doesn’t overlap with the ... Windows XP Service Pack 2 ...
Read more