• Save
Understanding how is that adaptive cursor sharing (acs) produces multiple optimal plans
Upcoming SlideShare
Loading in...5
×
 

Understanding how is that adaptive cursor sharing (acs) produces multiple optimal plans

on

  • 390 views

 

Statistics

Views

Total Views
390
Views on SlideShare
374
Embed Views
16

Actions

Likes
1
Downloads
0
Comments
0

1 Embed 16

https://www.enkitec.com 16

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Understanding how is that adaptive cursor sharing (acs) produces multiple optimal plans Understanding how is that adaptive cursor sharing (acs) produces multiple optimal plans Presentation Transcript

  • Understanding  how     Adap1ve  Cursor  Sharing  (ACS)     produces  mul1ple  Op1mal  Plans   Carlos  Sierra  
  • Carlos  Sierra   •  Consultant/Developer/DBA   •  Oracle  Performance   •  SQLTXPLAIN  (SQLT)   •  SQL  Tuning   •  Tools   Enkitec  (c)  2014   2  
  • Topics   •  Adap1ve  Cursor  Sharing  (ACS)   – Mechanics   – Demos   Enkitec  (c)  2014   3  
  • Plan  Flexibility  Allies   •  CBO  Parameters   •  CBO  Sta1s1cs   •  Dynamic  Sampling   •  Cardinality  Feedback   •  Cursor  Sharing   •  Adap%ve  Cursor  Sharing  (ACS)   Enkitec  (c)  2014   4  
  • Plan  Stability  Tools   •  CBO  Hints   •  Stored  Outlines   •  SQL  Profiles   •  SQL  Plan  Management  (SPM)   Enkitec  (c)  2014   5  
  • Cursor  Sharing   •  Use  of  Bind  Variables  instead  of  Literals   – AND  p.prod_category  LIKE  'So[ware%’   – AND  p.prod_category  LIKE  :b5   •  Goal:  Reduce  Hard  Parsing   – Improve  Scalability   •  Reduce  CPU  u1liza1on   •  Reduce  Shared  Memory  footprint   Enkitec  (c)  2014   6  
  • Cursor  Sharing  Shortcomings   •  Flipping  Plans   – Exacerbated  by  Histograms  on  Skewed  Data     – AND  c.cust_marital_status  =  :b2   •  :b2  :=  ‘married’   •  :b2  :=  ‘widow’   – Plan  is  computed  at  hard  parse   •  Plan  becomes  a  long  term  moving  target   Enkitec  (c)  2014   7  
  • Adap1ve  Cursor  Sharing  (ACS)   •  11g+   •  Mul1ple  Op1mal  Plans  per  SQL   – As  per  “Selec1vity”  of  Predicates   •  :b2  :=  ‘married’  (close  to  60%  maybe)   •  :b2  :=  ‘widow’  (this  one  is  more  selec1ve)   Enkitec  (c)  2014   8  
  • ACS  Challenges   •  Minimize  Resources  Impact   – Monitor  only  a  subset  of  SQL  Statements   – Ac1vate  ACS  only  for  a  subset  of  the  monitored  SQL   – Share  Execu1ons  Plans  through  a  “Selec1vity  Profile”   Enkitec  (c)  2014   9   All  Statements   Bind  Sensi1ve   Bind  Aware   ACS  
  • Becoming  Bind  Sensi1ve   1.  SQL  has  Range  Predicates  on  Bind  Variables   –  AND  c.cust_year_of_birth  BETWEEN  :b3  AND  :b4   –  AND  p.prod_category  LIKE  :b5   2.  SQL  has  Equality  Predicates  on  Bind  Variables  and   Column  has  a  Histogram   –  AND  c.cust_marital_status  =  :b2   –  AND  TO_CHAR(s.1me_id,  'YYYY')  =  :b6   Enkitec  (c)  2014   10  
  • Becoming  Bind  Aware   1.  Rows  Processed  change  substan1ally  between   Execu1ons   – Between  a  few  rows  to  millions   2.  Rows  Processed  oscillate  significantly  between   Execu1ons   – Between  a  few  rows  and  a  few  thousand   – Between  a  few  thousand  and  millions   Enkitec  (c)  2014   11  
  • ACS  Monitoring   •  V$SQL  (State)   – is_shareable   – is_bind_sensi1ve   – is_bind_aware   •  V$SQL_CS_STATISTICS  (Rows  Processed)   •  V$SQL_CS_HISTOGRAM  (3  Buckets  S/M/L)   •  V$SQL_CS_SELECTIVITY  (Selec1vity  Profile)   Enkitec  (c)  2014   12  
  • Rows  Processed   •  v$sql_cs_sta1s1cs.rows_processed   •  Updated  only  at  hard  parse   •  A  measure  of  amount  of  work  on  Execu1on  Plan   •  Three  sizes:  S/M/L   – 0:  Small     – 1:  Medium     – 2:  Large   Enkitec  (c)  2014   13  
  • Rows  Processed   •  v$sql_cs_sta1s1cs.rows_processed   •  Updated  only  at  hard  parse   •  A  measure  of  amount  of  work  on  Execu1on  Plan   •  Three  sizes:  S/M/L   – 0:  Small  (less  than  1K  rows)   – 1:  Medium  (between  1k  and  1m  rows)   – 2:  Large  (more  than  1m  rows)   Enkitec  (c)  2014   14  
  • ACS  Buckets   •  v$sql_cs_histogram.bucket_id   – 0:  Small   – 1:  Medium   – 2:  Large   •  v$sql_cs_histogram.count   – Incremented  with  each  Execu1on  as  per   •  v$sql_cs_sta1s1cs.rows_processed   Enkitec  (c)  2014   15  
  • Rows  Processed  and  ACS  Buckets   IF        v$sql_cs_statistics.rows_processed  <  1K  THEN              v$sql_cs_histogram.count(0)++   ELSIF  v$sql_cs_statistics.rows_processed  <  1M  THEN              v$sql_cs_histogram.count(1)++   ELSE                  v$sql_cs_histogram.count(2)++   END  IF         Enkitec  (c)  2014   16  
  • Becoming  Bind  Aware   1.  Small  and  Large  buckets  have  a  value   – bucket_id.count(0)  >  0  AND  bucket_id.count(2)  >  0   2.  Two  adjacent  buckets  have  same  non-­‐zero  value   – bucket_id.count(0)  =  bucket_id.count(1)  >  0   – bucket_id.count(1)  =  bucket_id.count(2)  >  0     Enkitec  (c)  2014   17  
  • Rows  Processed  per  Execu1on   •  10(0)…  50(0)…  3,000,000(2)…  BA   •  30(0)…  3,000(1)…  BA   •  2,000,000(2)…  1(0)…  BA   •  0(0)…  10,000(1)…  BA   •  3,000(1)…  2,000(1)…  200(0)…  300(0)…  BA   •  10…  100…  500…  2,000…  3,000…  5,000…  BA   •  rows_processed(bucket_id)…  Bind  Aware(BA)   Enkitec  (c)  2014   18  
  • WHY  becoming  BA  is  important?   •  Mul1ple  Op1mal  Plans  are  created  a[er  Cursor   becomes  Bind  Aware   Enkitec  (c)  2014   19  
  • Sample  Query  (1)   SELECT  p.prod_subcategory_desc  subcatagory,                SUM(amount_sold)  amount_sold      FROM  sh.customers  c,                sh.products  p,                sh.sales  s    WHERE  c.cust_gender  =  'M'        AND  c.cust_marital_status  =  'single'        AND  c.cust_year_of_birth  BETWEEN  1913  AND  1990        AND  p.prod_category  LIKE  'Software%'        AND  TO_CHAR(s.time_id,  'YYYY')  =  '2001'        AND  s.cust_id  =  c.cust_id        AND  s.prod_id  =  p.prod_id    GROUP  BY                p.prod_subcategory_desc    ORDER  BY                p.prod_subcategory_desc;   Enkitec  (c)  2014   20  
  • Sample  Query  (2)   •  Based  on  Sample  Schema  SH   – With  CBO  Histograms  in  all  Columns   •  Not  a  requirement  for  this  ACS  test   •  3  Tables  with  Filter  Predicates   •  2  Joins   •  6  possible  Join  Orders   •  Several  possible  Execu1on  Plans   Enkitec  (c)  2014   21  
  • Demo  1   •  5  Execu1ons  of  Sample  Query  using  Literals   – Different  values  for  each  Execu1on   •  Sequence  1,  2,  3,  4  and  5   – Each  Execu1on  performs  a  Hard  Parse   – Each  Execu1on  computes  a  “new”  Plan   – Each  seems  to  be  an  “Op1mal”  Plan   Enkitec  (c)  2014   22  
  • Demo  2   •  5  Execu1ons  of  Sample  Query  using  Binds   – Different  values  for  each  Execu1on   •  Sequence  1,  2,  3,  4  and  5   – Each  Execu1on  performs  a  Hard  Parse   •  Forced  with  a  Cursor  Flush  before  the  Execu1on   – Each  computes  a  “new”  Op1mal  Plan   •  Almost  same  as  “with  Literals”   Enkitec  (c)  2014   23  
  • Demo  2  Results   Query   Rows  Processed   ACS  Bucket   Plan  Hash  Value   1   1,483,124   2   2048551027   2   1,272,154   2   3022804314   3   1,014,876   2   2326939410   4   716,168   1   2163719564   5   530   0   2163719564   Enkitec  (c)  2014   24  
  • Demo  3   •  5  Execu1ons  of  Sample  Query  using  Binds   – Different  values  for  each  Execu1on   •  Sequence  1,  2,  3,  4  and  5   – No  Cursor  Flush  between  Execu1ons   – First  Execu1on  computes  a  “new”  Op1mal  Plan   – All  Execu1ons  use  same  Plan…   Enkitec  (c)  2014   25  
  • Demo  3  Results   Query   Rows  Processed   ACS  Bucket   Op%mal  Plan   ACS  Aware   Executed   1   1,483,124   2   2048551027   N   2048551027   2   1,272,154   2   3022804314   N   2048551027   3   1,014,876   2   2326939410   N   2048551027   4   716,168   1   2163719564   N   2048551027   5   530   0   2163719564   N   2048551027   Enkitec  (c)  2014   26  
  • Demo  4   •  5  Execu1ons  of  Sample  Query  using  Binds   – Different  values  for  each  Execu1on   •  Sequence  5,  4,  3,  2  and  1   – No  Cursor  Flush  between  Execu1ons   – Cursor  becomes  Bind  Aware  a[er  2nd  Execu1on   – All  Execu1ons  used  an  Op1mal  Plan   Enkitec  (c)  2014   27  
  • Demo  4  Results   Query   Rows  Processed   ACS  Bucket   Op%mal  Plan   Bind  Aware   Executed   5   530   0   2163719564   N   2163719564   4   716,168   1   2163719564   N   2163719564   3   1,014,876   2   2326939410   Y   2326939410   2   1,272,154   2   3022804314   Y   3022804314   1   1,483,124   2   2048551027   Y   2048551027   Enkitec  (c)  2014   28  
  • Demo  5   •  5  Execu1ons  of  Sample  Query  using  Binds   – Different  values  for  each  Execu1on   •  Sequence  5,  1,  2,  3  and  4   – No  Cursor  Flush  between  Execu1ons   – Cursor  becomes  Bind  Aware  a[er  2nd  Execu1on   – All  but  one  Execu1ons  used  an  Op1mal  Plan   Enkitec  (c)  2014   29  
  • Demo  5  Results   Query   Rows  Processed   ACS  Bucket   Op%mal  Plan   Bind  Aware   Executed   5   530   0   2163719564   N   2163719564   1   1,483,124   2   2048551027   N   2163719564   2   1,272,154   2   3022804314   Y   3022804314   3   1,014,876   2   2326939410   Y   2326939410   4   716,168   1   2163719564   Y   2163719564   Enkitec  (c)  2014   30  
  • Controlling  ACS  with  CBO  Hint   •  /*+  BIND_AWARE  */   – Bypasses  the  monitoring  phase  of  a  Bind  Sensi1ve  SQL   •  /*+  NO_BIND_AWARE  */   – Turns  off  ACS  for  given  SQL   Enkitec  (c)  2014   31  
  • Controlling  ACS  with  SQL  Patch   •  SYS.DBMS_SQLDIAG_INTERNAL.I_CREATE_PATCH   – sql_text   – hint_text  =>  BIND_AWARE   •  Script  sqlpch.sql   Enkitec  (c)  2014   32  
  • ACS  Plan  Selec1on   •  On  every  Execu1on  of  Bind  Aware  Cursor   – Compute  Selec1vity  of  each  qualifying  Predicate   – Search  Selec1vity  within  Range  of  values  on  ACS   Selec1vity  Profile   – If  within  Range,  lookup  Child  Number  and  use  its  Plan   – Else,  Hard  Parse  and  Execute  newly  computed  Plan   •  If  same  as  exis1ng  Plan,  then  update  Selec1vity  Profile   •  Else,  create  Selec1vity  Profile  for  new  Child  Number   Enkitec  (c)  2014   33  
  • Selec1vity  Profile  (1)   •  v$sql_cs_selec1vity   – predicate   – range_id   •  low  and  high  (selec1vi1es)   – child_number   Enkitec  (c)  2014   34  
  • Selec1vity  Profile  (2)              CHILD  PREDICATE          RANGE_ID  LOW                HIGH   -­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐  -­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐  -­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐  -­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐  -­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐                      1  <=B4                                  0  0.860941      1.052262                      1  =B1                                    0  0.602369      0.736229                      1  =B2                                    0  0.455337      0.556523                      1  >=B3                                  0  0.182445      0.222988                      1  B5                                      0  0.306250      0.374306                      2  <=B4                                  0  0.892666      1.091036                      2  =B1                                    0  0.297574      0.363702                      2  =B2                                    0  0.455337      0.556523                      2  >=B3                                  0  0.077947      0.095268                      2  B5                                      0  0.306250      0.374306                      3  <=B4                                  0  0.836835      1.022798                      3  =B1                                    0  0.297574      0.363702                      3  =B2                                    0  0.002085      0.002548                      3  >=B3                                  0  0.221447      0.270657                      3  B5                                      0  0.306250      0.374306   Enkitec  (c)  2014   35  
  • ACS  Summary   •  ACS  is  capable  of  producing  mul1ple  Op1mal   Execu1on  Plans  per  SQL   •  During  ramp-­‐up  sub  Op1mal  Plans  may  happen   •  ACS  Metadata  resides  in  Memory  (not  Persistent)   •  ACS  provides  desirable  Plan  Flexibility   •  ACS  does  not  address  the  Plan  Stability  concern   Enkitec  (c)  2014   36  
  • ACS  Suggested  Strategy   •  Use  sys.dbms_sqldiag_internal.i_create_patch  to   SQL  Patch  with  BIND_AWARE  the  SQL  on  Baselines     Enkitec  (c)  2014   37  
  • SPM  Suggested  Strategy   •  Use  dbms_applica1on_info.set_module  in  your   code  to  set  MODULE  and  ACTION   •  Use  dbms_spm.load_plans_from_cursor_cache   filtering  with  MODULE  or  ACTION   •  Use  dbms_spm.evolve_sql_plan_baseline  to  verify   and  evolve  periodically  good  performing  Plans   Enkitec  (c)  2014   38  
  • References  (1)   •  Using  SQL  Patch  to  add  hints  to  a  packaged   applica1on   – hxps://blogs.oracle.com/op1mizer/entry/ how_can_i_hint_a   Enkitec  (c)  2014   39  
  • References  (2)   •  Oracle®  Database  PL/SQL  Packages  and  Types   Reference   – 11g  Release  2  (11.2)   – Part  Number  E25788-­‐04   Enkitec  (c)  2014   40  
  • Contact  Informa1on   •  carlos.sierra@enkitec.com   •  carlos-­‐sierra.net   •  @csierra_usa   Enkitec  (c)  2014   41