Part 1 of this webinar set discussed the performance challenges caused by plan instability. Using SQL profiles and SQL patches are mechanisms that can provide targeted relief to individual SQL statements that have plan regressions. However, Oracle provides SQL Plan Management features that are intended to prevent plan regressions from creating challenges in the first place. In this webinar, attendees will learn: - How SQL Plan Management (SPM) works - How SQL Plan Baselines are created - How SQL Plan Baselines are evolved/enabled for use - Limitations of SPM Featured speaker: Karen Morton, Enkitec

1. In
Search
of
Plan
Stability
Part
2
Karen
Morton
Sr.
Technical
Consultant
Now
part
of
Accenture

2. karen.morton@enkitec.com
karenmorton.blogspot.com
@karen_morton

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

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

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

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

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

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

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

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

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

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

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

14. 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'
)

15. Import
from
another
database
(1)
DBMS_SPM.CREATE_STGTAB_BASELINE (
table_name =>
table_owner =>
)
On
source
database

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

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

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

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

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

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

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

23. EVOLVE_SQL_PLAN_BASELINE
DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE (
sql_handle =>
plan_name =>
plan_list =>
time_limit =>
verify =>
commit =>
)

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

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

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

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

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

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

30. Thank
You!