Using Adaptive Cursor Sharing (ACS) to produce multiple Optimal Plans

Copyright © 2013, Oracle and/or its affiliates. All rights reserved.1

Using Adaptive Cursor Sharing (ACS) to produce multiple Optimal PlansCarlos SierraConsulting Technical Advisor


Carlos Sierra

SQL Tuner handyman: developer, advisor, trainer, support IT: Oracle(17), UNISYS(12), Ford(3), others(3) Florida(17), Venezuela(3), Puerto Rico(6), Michigan(1), Mexico(X) Tools: SQLTXPLAIN(SQLT), SQLHC, TRCANLZR(TRCA), others Motto: Life is good!

Oracle Server Technologies(ST) Center of Expertise(CoE)


Adaptive Cursor Sharing (ACS)

Motivation Mechanics Test Case Demo Remarks


ACS Motivation


SQL Processing

Hard parse side effects– CPU consumption– Latch contention

Excessive hard parsing – Affects concurrency– Restricts scalability

Mitigating hard parsing– Cursor sharing

Hard parsing is expensive!


Implementing Cursor SharingReplacing literals with bind variables


Before Bind Peeking

Predicate– WHERE channel_id = :b1

Unknowns– Is :b1 between low and high values of channel_id?– Is :b1 a popular value of channel_id?– Are there any rows with value :b1 for channel_id?

Penalty– Possible suboptimal plans

Before 9i CBO was blind to values passed


With Bind Peeking

Predicate– WHERE channel_id = :b1

Plan is determined by peeked values– EXEC :b1 := 9;

Optimal plan for 1st execution– CBO can use low/high and histograms on channel_id

Penalty– Possible suboptimal plans for subsequent executions on skewed data

9i offers a partial solution


With Adaptive Cursor Sharing

Some queries are ACS candidates Sophisticated non-persistent mechanism Selectivity of predicates determine plan Multiple optimal plans for a query!

– If ACS is successfully applied Penalty

– Marginal increase in CPU and memory overhead

11g improves cursor sharing


ACS Mechanics


ACS high-level OverviewHigh level overview

If SQL with binds meets some requirements – Flag cursor as bind sensitive– Start monitoring data volume manipulated by cursor

If bind sensitive and data volume manipulated by cursor varies significantly

– Flag cursor as bind aware– Start generating multiple optimal plans for this query on next hard parse

If bind aware then use selectivity of predicates to decide on plan


Bind Sensitive

SQL has explicit binds – Or literals and cursor_sharing is “force”

Predicate: column + operand + bind_variable– Equality operand “=“ and histogram on column

Ex: channel_id = :b1– Non-equality operand (range) regardless of histogram on column

“>”, “>=“, “<“, ‘<=“, BETWEEN, LIKE

Minimum requirements


Bind Aware

Significant changes in data volume manipulated by cursor– A few rows versus a few thousands of rows– A few thousands of rows versus a few millions of rows

Specifying /*+ BIND_AWARE */ CBO Hint– Bypasses the monitoring phase on data volume

How to become bind aware?


Plan Selection

Evaluate selectivity of predicates at soft parse Compare to a non-persistent selectivity profile If within ranges of a known profile then select associated plan Else hard parse

– Compute and execute newly generated plan– Create selectivity profile for new plan or update profile of existing plan

If ranges on selectivity profiles overlap then merge profiles

Based on selectivity profile of predicates


V$ dynamic views for ACS

V$SQL– Shareable, bind sensitive and bind aware flags

V$SQL_CS_STATISTICS– Data volume manipulated (rows processed)

V$SQL_CS_HISTOGRAM– Record keeping of data volume per execution (small, medium, large)

V$SQL_CS_SELECTIVITY– Predicates selectivity profiles

ACS non-persistent performance views


ACS Test Case


Our Query with LiteralsGuesstimate execution plan then verify it with demo 0


Possible Access Paths?


Optimal Execution Plan


Our Query with Bind VariablesHow many optimal execution plans can you foresee?


Multiple Optimal Plans for one QueryGuesstimate optimal plan (access paths) for each query

Query :b1 :b2 AP1 AP2q1 9 33 N1 N2

q2 5 32

q3 2 999

q4 9 999

q5 2 33


Multiple Optimal Plans for one QueryGuesstimate optimal plan (access paths) for each query

Query :b1 :b2 AP1 AP2q1 9 33 N1 N2

q2 5 32 N1 N2

q3 2 999 FTS FTS

q4 9 999 N1 FTS

q5 2 33 FTS N2


Multiple Optimal Plans for one QueryExecute demos 1-5 and verify access paths

Query :b1 :b2 AP1 AP2q1 9 33 N1 N2q2 5 32 N1 N2q3 2 999 FTS FTSq4 9 999 N1 FTSq5 2 33 FTS N2


Bind Sensitive: Rows Processed

Data volume manipulated– Fuzzy representation– S: few rows– M: thousands or rows– L: millions of rows

v$sql_cs_histogram– Bucket(0): S– Bucket(1): M– Bucket(2): L

Monitor v$sql_cs_statistics.rows_processed

Query :b1 :b2 OptimalRows

Processedq1 9 33 N1/N2 37,382

q2 5 32 N1/N2 2

q3 2 999 FTS/FTS 8,021,324

q4 9 999 N1/FTS 6,233,815

q5 2 33 FTS/N2 1,825,131


ACS Demo


Demo 6: When Cursor becomes Bind Aware?


Processed Bucket Aware Child Actualq1 9 33 N1/N2 37,382

q2 5 32 N1/N2 2

q3 2 999 FTS/FTS 8,021,324

q4 9 999 N1/FTS 6,233,815

q5 2 33 FTS/N2 1,825,131

Obtain rows processed from demo 1-5 then guesstimate aware flag




Processed Bucket Aware Child Actualq1 9 33 N1/N2 37,382 1

q2 5 32 N1/N2 2 0

q3 2 999 FTS/FTS 8,021,324 2

q4 9 999 N1/FTS 6,233,815 2

q5 2 33 FTS/N2 1,825,131 2





Processed Bucket Aware Child Actualq1 9 33 N1/N2 37,382 1 N

q2 5 32 N1/N2 2 0 N

q3 2 999 FTS/FTS 8,021,324 2 Y

q4 9 999 N1/FTS 6,233,815 2 Y

q5 2 33 FTS/N2 1,825,131 2 Y





Processed Bucket Aware Child Actualq1 9 33 N1/N2 37,382 1 N 0 N1/N2

q2 5 32 N1/N2 2 0 N 0 N1/N2

q3 2 999 FTS/FTS 8,021,324 2 Y 1 FTS/FTS

q4 9 999 N1/FTS 6,233,815 2 Y 2 N1/FTS

q5 2 33 FTS/N2 1,825,131 2 Y 3 FTS/N2





Processed Bucket Aware Child Actualq1 9 33 N1/N2 37,382 1 N 0 N1/N2

q2 5 32 N1/N2 2 0 N 0 N1/N2

q3 2 999 FTS/FTS 8,021,324 2 Y 1 FTS/FTS

q4 9 999 N1/FTS 6,233,815 2 Y 2 N1/FTS

q5 2 33 FTS/N2 1,825,131 2 Y 3 FTS/N2





Processed Bucket Aware Child Actualq5 2 33 FTS/N2 1,825,131

q4 9 999 N1/FTS 6,233,815

q3 2 999 FTS/FTS 8,021,324

q2 5 32 N1/N2 2

q1 9 33 N1/N2 37,382

Compute bucket and guesstimate aware flag and actual plan




Processed Bucket Aware Child Actualq5 2 33 FTS/N2 1,825,131 2

q4 9 999 N1/FTS 6,233,815 2

q3 2 999 FTS/FTS 8,021,324 2

q2 5 32 N1/N2 2 0

q1 9 33 N1/N2 37,382 1





Processed Bucket Aware Child Actualq5 2 33 FTS/N2 1,825,131 2 N

q4 9 999 N1/FTS 6,233,815 2 N

q3 2 999 FTS/FTS 8,021,324 2 N

q2 5 32 N1/N2 2 0 N

q1 9 33 N1/N2 37,382 1 Y





Processed Bucket Aware Child Actualq5 2 33 FTS/N2 1,825,131 2 N 0 FTS/N2

q4 9 999 N1/FTS 6,233,815 2 N 0 FTS/N2

q3 2 999 FTS/FTS 8,021,324 2 N 0 FTS/N2

q2 5 32 N1/N2 2 0 N 0 FTS/N2

q1 9 33 N1/N2 37,382 1 Y 1 N1/N2






q4 9 999 N1/FTS 6,233,815 2 N 0 FTS/N2

q3 2 999 FTS/FTS 8,021,324 2 N 0 FTS/N2

q2 5 32 N1/N2 2 0 N 0 FTS/N2

q1 9 33 N1/N2 37,382 1 Y 1 N1/N2





Processed Bucket Aware Child Actualq5 2 33 FTS/N2 1,825,131 2

q4 9 999 N1/FTS 6,233,815 2

q3 2 999 FTS/FTS 8,021,324 2

q1 9 33 N1/N2 37,382 1

q2 5 32 N1/N2 2 0

Guesstimate aware flag and actual plan




Processed Bucket Aware Child Actualq5 2 33 FTS/N2 1,825,131 2 N

q4 9 999 N1/FTS 6,233,815 2 N

q3 2 999 FTS/FTS 8,021,324 2 N

q1 9 33 N1/N2 37,382 1 N

q2 5 32 N1/N2 2 0 N






q4 9 999 N1/FTS 6,233,815 2 N 0 FTS/N2

q3 2 999 FTS/FTS 8,021,324 2 N 0 FTS/N2

q1 9 33 N1/N2 37,382 1 N 0 FTS/N2

q2 5 32 N1/N2 2 0 N 0 FTS/N2






q4 9 999 N1/FTS 6,233,815 2 N 0 FTS/N2

q3 2 999 FTS/FTS 8,021,324 2 N 0 FTS/N2

q1 9 33 N1/N2 37,382 1 N 0 FTS/N2

q2 5 32 N1/N2 2 0 N 0 FTS/N2



Closing Remarks


Remarks on Bind Sensitivity

Monitor V$SQL_CS_STATISTICS.rows_processed– If small number of rows then

V$SQL_CS_HISTOGRAM.bucket_id(0)++– If medium number of rows then

V$SQL_CS_HISTOGRAM.bucket_id(1)++– If large number of rows then

V$SQL_CS_HISTOGRAM.bucket_id(2)++

Based on experimental observation


Remarks on Bind Aware

Some cases where cursor may become bind aware– bucket_id(0) = bucket_id(1) > 0– bucket_id(1) = bucket_id(2) > 0– bucket_id(0) > 0 and bucket_id(2) > 0– /*+ BIND_AWARE */ CBO Hint

Based on experimental observation


Understanding Selectivity ProfileFrom demo 6

Query :b1 :b2 Childq3 2 999 1

q4 9 999 2

q5 2 33 3




q4 9 999 2

q5 2 33 3




q4 9 999 2

q5 2 33 3


Conclusions

ACS only applies to a subset of queries with binds ACS requires a ramp-up process (few executions) In some cases cursor may fail to become bind aware To force a cursor become bind aware use CBO Hint ACS is not persistent ACS works well with SQL Plan Management

ACS can produce multiple optimal plans for one query


Give Away

Creates a SQL Patch for one SQL_ID Turns “on” EVENT 10053 for SQL_ID Hints on SQL Patch

– GATHER_PLAN_STATISTICS – MONITOR – BIND_AWARE

Instructions how to drop SQL Patch and turn “off” EVENT 10053

Script sqlt/utl/coe_gen_sql_patch.sql (MOS 215187.1)


References and Contact Info

https://blogs.oracle.com/optimizer/– Insight into the workings of the Optimizer

Oracle Optimizer Blog

[email protected] http://carlos-sierra.net @csierra_usa


Documents

Using Adaptive Cursor Sharing (ACS) to produce multiple Optimal Plans