In  Search  of  Plan  Stability  Part  2  

Karen  Morton  Sr.  Technical  Consultant  

 Now  part  of  Accenture  

karenmorton.blogspot.com  

@karen_morton  

karen.morton@enkitec.com  

Topics  

•  How  SQL  Plan  Management  (SPM)  works  •  How  SQL  Plan  Baselines  are  created  •  How  SQL  Plan  Baselines  are  evolved/enabled  for  use  •  "InteresMng"  SPM  Mdbits  

SQL  Plan  Management  (SPM)  

•  One  or  more  persistent,  opMmal  plans  per  SQL  •  Plan  Stability  – Only  known  and  accepted  plans  can  be  executed  

•  Plan  Flexibility  – Capture  new  plans  and  evaluate  their  performance  "off-­‐line"  – New  plans  are  acknowledged  but  not  executed  unMl  "evolved"  

Goal  Plan  stability  with  controlled  flexibility  

SPM  allows  execuMon  plans  for  SQL  statements  to  be  stored  so  that  the  plan  remains  consistent  throughout  various  changes  such  as  schema  changes,  database  reorgs,  data  volume  changes  and  more.  

SPM  is  an  Oracle  Enterprise  Edi3on  feature  and  does  not  require  the  tuning  pack.  For  more  details  see  the  Op3mizer  Development  Team  blog  at    hBps://blogs.oracle.com/op3mizer/entry/does_the_use_of_sql  

Configuring  SPM  

•  Stored  in  SYSAUX  tablespace  •  Two  non-­‐init.ora  parameters  – space_budget_percent  =  10  (storage  usage  in  SYSAUX)  – plan_retenMon_weeks  =  53  (purge  baselines  not  used  in  X  weeks)  

•  Use  DBMS_SPM.CONFIGURE  •  Query  configuraMon  info  from  DBA_SQL_MANAGEMENT_CONFIG  

Why  use  SPM?  

•  Since  execuMon  plan  selecMon  depends  on  many  things,  when  any  of  these  things  changes,  plans  can  change  

•  Like  what?  – Upgraded  or  patched  database  version  – StaMsMcs  changes  (for  tables,  indexes,  etc)  – Parameter  changes  – Metadata  changes  (schema  objects)  – Cardinality  feedback,  adapMve  cursor  sharing  and  more…  

How  does  SPM  work?  

•  A  repository  of  execuMon  plans  is  held  for  every  SQL  statement  (DBA_SQL_PLAN_BASELINES)  

•  At  hard  parse  Mme  – The  repository  is  searched  for  a  plan  for  the  SQL  being  executed  

– When  plan  found  (or  none  is  found),  that  plan  is  used  – When  plan  not  found,  but  other  accepted  plans  for  the  SQL  are  present,  one  of  the  accepted  plans  is  used  instead    

How  is  SPM  managed?  

•  SPM  is  controlled  by  an  init.ora  parameter  – opMmizer_use_sql_plan_baselines  =  true/false  – Can  be  altered  at  both  the  system  and  session  leveled  

•  The  supplied  packaged,  DBMS_SPM,  provides  addiMonal  management  features  

•  SPM  can  be  configured  to  work  automaMcally  or  be  manually  controlled  

SQL  Plan  Baselines  Overview  

•  A  set  of  plans  available  to  the  CBO  for  a  given  SQL  •  IniMal  occurrence  of  a  plan  is  stored  and  accepted  in  SMB  •  Any  new  (i.e.  changed)  plan  is  added  as  a  non-­‐accepted  plan  and  must  be  verified  later  

•  Accepted  plans  have  been  verified  to  not  cause  performance  regression  or  indicate  performance  improvement  

How  the  SMB  (plan  history)  works  

Parse  of  SQL0001  

ExecuMon  Plan  P1001  

SQL   Plan   Accepted?  SQL0001   P1001   Y  SQL0001   P1002   Y  SQL0001   P1003   Y  SQL0001   P1004   N  SQL0002   P2001   Y  

If  derived  plan  of  SQL0001  matches  any  SMB  plan,  use  it.    If  no  match,  choose  one  of  the    already  accepted  plans.  

Load  the  new/different  plan  in  "not  accepted"  state.  

SPM  Main  Concepts  

•  SQL  Plan  Baseline  capture  – Using  SQL  Tuning  Set  (STS)  – From  the  cursor  cache  (shared  pool/V$SQL_PLAN)  – Export  from  one  database;  import  into  another  – AutomaMcally  

•  SQL  Plan  Baseline  selecMon    •  SQL  Plan  Baseline  evoluMon  

Capture  using  SQL  Tuning  Set  

DBMS_SPM.LOAD_PLANS_FROM_SQLSET (

sqlset_name => 'name of STS' ,

sqlset_owner => 'owner of STS' , basic_filter => 'any WHERE clause' ,

fixed => 'NO (default) / YES' ,

enabled => 'YES (default) / NO' ,

commit_rows => '# plans loaded per commit'

)

Requires  Tuning  Pack  

Capture  from  Shared  Pool  

DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE ( sql_id =>

plan_hash_value => [NULL – all plans for SQL_ID]

sql_text =>

sql_handle =>

attribute_name => [SQL_TEXT, PARSING_SCHEMA_NAME, MODULE, ACTION]

attribute_value =>

fixed => 'NO (default) / YES'

enabled => 'YES (default) / NO'

)

Import  from  another  database  (1)  

DBMS_SPM.CREATE_STGTAB_BASELINE ( table_name =>

table_owner =>

)

On  source  database  

Import  from  another  database  (2)  

DBMS_SPM.PACK_STGTAB_BASELINE ( table_name => table_owner => sql_handle => plan_name => sql_text => creator => enabled => accepted => fixed => module => action =>

)

On  source  database  

Import  from  another  database  (3)  

DBMS_SPM.UNPACK_STGTAB_BASELINE ( table_name => table_owner => sql_handle => plan_name => sql_text => creator => enabled => accepted => fixed => module => action =>

)

On  target  database  

Capture  automaMcally  

ALTER SESSION SET OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES = TRUE;

•  First  plan  captured  automaMcally  accepted  •  Occurs  only  for  repeatable  statements    – SQL  must  be  executed  at  least  twice  –  IniMal  execuMon  info  kept  in  SYS.SQLLOG$  

On  target  database  

SQL  Plan  Baselines  (1)  

•  IdenMfied  by  SQL  Handle  and  Signature    – Hash  funcMon  on  SQL  Text  – DBMS_SQLTUNE.SQLTEXT_TO_SIGNATURE  

•  View  DBA_SQL_PLAN_BASELINES  – enabled  =  YES  – accepted  =  YES  

SQL  Plan  Baselines  (2)  

•  Stores  plan_hash_value  and  verifies  plan  can  be  reproduced  before  using  

•  Provides  stability  at  the  expense  of  Mme  to  review  and  evolve  new  plans  (automaMc  plan  evoluMon  available)  

•  Must  match  SQL  text  exactly  – No  opMon  for  force_matching  (as  available  with  SQL  Profiles)  

What  is  a  FIXED  baseline?  

•  When  a  baseline  plan  is  fixed  – The  plan  exists  and  is  both  accepted  and  enabled  – Can  be  set  manually  – Alters  the  selecMon  and  capture  process  •  Auto-­‐capture  won't  add  any  new  not-­‐accepted  plans  for  this  SQL  •  The  selecMon  process  will  choose  the  FIXED/ENABLED  plan  for  this  SQL  

SQL  Plan  Baseline  EvoluMon  

•  The  way  Oracle  determines  if  not  yet  accepted  plans  can  be  turned  into  accepted  plans  

•  Done  by  execuMng  waiMng  plans  and  comparing  performance  with  already  accepted  plans  in  the  baseline  

•  Use  DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE  – Run  and  accept  plan  if  performance  is  bemer  – Run  and  report  only  (but  do  not  accept)  – Run  and  accept  without  tesMng/verifying  performance  

•  Schedule  plan  evoluMon  to  occur  automaMcally  –  In  nightly  maintenance  window  (uses  STA  and  must  be  licensed)  

EVOLVE_SQL_PLAN_BASELINE  

DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE ( sql_handle =>

plan_name =>

plan_list =>

time_limit =>

verify =>

commit =>

)

Manual  SQL  Plan  Baseline  EvoluMon  

SQL> variable spm_report clob; SQL> exec :spm_report := dbms_spm.evolve_sql_plan_baseline(); PL/SQL procedure successfully completed.

SQL> print :spm_report ------------------------------------------------------------------------------- Evolve SQL Plan Baseline Report ------------------------------------------------------------------------------- Inputs: ------- SQL_HANDLE = PLAN_NAME = TIME_LIMIT = DBMS_SPM.AUTO_LIMIT VERIFY = YES COMMIT = YES Plan: SYS_SQL_PLAN_gdd261c97bcbc936 ----------------------------------- Plan was verified: Time used .2 seconds. Passed performance criterion: Compound improvement ratio >= 10.13 Plan was changed to an accepted plan. Baseline Plan Test Plan Improv. Ratio ------------- --------- ------------- Execution Status: COMPLETE COMPLETE Rows Processed: 942 942 Elapsed Time(ms): 19 15 1.27 CPU Time(ms): 18 15 1.2 Buffer Gets: 1188 116 10.24 Disk Reads: 0 0 Direct Writes: 0 0 Fetches: 0 0 Executions: 1 1 ------------------------------------------------------------------------------- Report Summary ------------------------------------------------------------------------------- Number of SQL plan baselines verified: 1.

SPM  Tidbits  

•  Statements  must  be  executed  twice  to  be  captured  – SYS.SQLLOG$  contains  single  SQL  (helps  with  literal  SQL)  

•  Baselines  don't  actually  hold  the  execuMon  plan  – Set  of  outline  hints  –  injected  into  SQL  text  to  produce  plan  – Plan  hash  ID  –  plan  produced  when  baseline  captured  

•  EvoluMon  of  baselines  on  DML  (insert/update/delete/merge)  have  to  execute  the  DML  if  VERIFY  =  YES  – Bemer  not  have  triggers  with  non-­‐transacMonal  side-­‐effects!  

SPM  Tidbits  

•  SPM  inhibits  intended  funcMon  of  cardinality  feedback  and  adapMve  cursor  sharing  

•  SPM  is  intended  to  prevent  performance  degradaMon    – Just  like  any  feature,  it's  not  a  guaranteed  "always"  

•  SPM  requires  Tuning  Pack  only  if  used  with  automaMc  evoluMon  and  the  SQL  Tuning  Advisor  

12c  Enhancements  

•  New  evolve  auto  task  –  sys_auto_spm_evolve_task  – See  DBA_ADVISOR_TASKS  – Use  DBMS_SPM.REPORT_AUTO_EVOLVE_TASK  

•  Integrated  into  EM  – Maintains  persistent  store  of  evoluMon  reports  

•  In  addiMon  to  plan  hash,  plan  rows  stored  – Aids  in  diagnosis  when  plan  cannot  be  reproduced  

Wrap-­‐up  

•  SPM  is  about  controlled  plan  flexibility    •  SPM  must  be  able  to  reproduce  a  plan  in  order  to  use  it  •  SPM  can  have  mulMple  accepted  plans  in  a  baseline  •  SPM  typically  requires  some  Mme/resource  commitment  to  manage  well  

Thank  You!