This presentation is about understanding all 3 components of SPM and how we can use this technology to efficiently migrate "good" Execution Plans from one Release to another, or from one System to another.
4. Plan
Flexibility
• Cost-‐based
OpPmizer
(CBO)
– Introduced
in
Oracle
7
– Computes
an
OpPmal
Plan
based
on
• HeurisPcs
• Query
Predicates
• Schema
Object
StaPsPcs
• Several
Others
Enkitec
(c)
2014
4
5. Flexibility:
Good
or
Evil?
• CBO
Mission
– Compute
an
OpPmal
Plan
for
a
given
SQL
and
its
Data
• Plans
have
many
and
complex
Dependencies
• CBO
Performance
– Successful
most
of
the
Pmes
• Produces
a
sub-‐opPmal
Plan
some,mes
Enkitec
(c)
2014
5
6. DBA
Recurrent
Nightmare
• A
business
criPcal
process
experiences
an
occasional
slow
down
– Same
SQL
usually
runs
quickly
– Developers
claim
they
haven’t
changed
anything
– Users
claim
they
do
the
same
every
Pme
– Business
keeps
reporPng
this:
to
YOU!
Enkitec
(c)
2014
6
7. Why
Plans
Perform
Inconsistently?
(1)
• Concurrency
with
some
other
Process
• State
of
Buffer
Cache
• RAC
Node
Affinity
• CPU
StarvaPon
• Sudden
Changes
on
Data
Volume
• Inconsistent
Performance
through
Database
Link
Enkitec
(c)
2014
7
9. Why
a
Plan
Flips?
(1)
• Bind
Variable
Peeking
with
Histograms
• Outdated
Schema
Object
(SO)
StaPsPcs
• Missing
SO
StaPsPcs
• Fresh
SO
StaPsPcs
• New
Empty
ParPPons
Enkitec
(c)
2014
9
10. Why
a
Plan
Flips?
(2)
• Incomplete
set
of
CBO
Hints
– Either
on
SQL
Text
or
SQL
Profile
• Dropped,
Invalid,
Invisible
or
new
Indexes
• Index
or
Table
rebuild
• Two
or
more
Plans
with
similar
Cost
Enkitec
(c)
2014
10
11. Why
a
Plan
Flips?
(3)
• Database
Parameters
Changes
• CBO
System
StaPsPcs
Changes
• Asynchronous
SO
StaPsPcs
Gathering
• Many
Others…
Enkitec
(c)
2014
11
12. How
to
MiPgate
Plan
Flipping?
• Solid
CBO
StaPsPcs
• Default
CBO
Parameters
• Avoid
Global
Changes
Enkitec
(c)
2014
12
15. SQL
Plan
Management
• 11g+
• MulPple
Persistent
OpPmal
ExecuPon
Plans
per
SQL
• Only
“accepted”
and
“enabled”
Plans
are
Executed
• New
Plans
are
acknowledged
but
not
Executed
• Goal:
Plan
Stability
with
controlled
Flexibility
Enkitec
(c)
2014
15
16. SQL
Plan
Baseline
• A
set
of
Plans
available
to
the
CBO
for
a
given
SQL
– IdenPfied
by
SQL
Handle
and
Signature
• Hash
funcPon
on
SQL
Text
• dbms_sqltune.sqltext_to_signature
– View
dba_sql_plan_baselines
• enabled
=
YES
• accepted
=
YES
• reproduced
=
YES
Enkitec
(c)
2014
16
17. Plan
History
• Content
of
dba_sql_plan_baselines
• Includes
SQL
Plan
Baseline
• Includes
Pending
Plans
– accepted
=
NO
and
last_verified
is
NULL
• Includes
Rejected
Plans
– accepted
=
NO
and
last_verified
is
not
NULL
• Includes
Disabled
Plans
Enkitec
(c)
2014
17
18. Methods
to
Create
a
Plan
Baseline
1. Capture
2. Load
a. Cursor
Cache
(CUR)
b. SQL
Tuning
Set
(STS)
c. Stored
Outline
3. MigraPon
Enkitec
(c)
2014
18
1. Capture
2. Load
a. CUR
b. STS
c. AWR
d. SPA
e. TRC
3. MigraPon
19. Capturing
a
SQL
Plan
Baseline
(1)
• Set
opPmizer_use_sql_plan_baselines
to
TRUE
(default)
• Set
opPmizer_capture_sql_plan_baselines
to
TRUE
(default
is
FALSE)
– Set
this
parameter
at
SESSION
level
• Execute
SQL
2
Pmes
• Set
opPmizer_capture_sql_plan_baselines
to
FALSE
Enkitec
(c)
2014
19
21. Loading
SQL
Plan
Baseline
from
Cache
• dbms_spm.load_plans_from_cursor_cache
– Inputs
• sql_id
• plan_hash_value
(opt)
– Outputs
• Number
of
Plans
loaded
Enkitec
(c)
2014
21
22. 22
DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE
(
sql_id
IN
VARCHAR2,
plan_hash_value
IN
NUMBER
:=
NULL,
sql_text
IN
CLOB,
fixed
IN
VARCHAR2
:=
'NO',
enabled
IN
VARCHAR2
:=
'YES')
RETURN
PLS_INTEGER;
DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE
(
sql_id
IN
VARCHAR2,
plan_hash_value
IN
NUMBER
:=
NULL,
sql_handle
IN
VARCHAR2,
fixed
IN
VARCHAR2
:=
'NO',
enabled
IN
VARCHAR2
:=
'YES')
RETURN
PLS_INTEGER;
DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE
(
sql_id
IN
VARCHAR2,
plan_hash_value
IN
NUMBER
:=
NULL,
fixed
IN
VARCHAR2
:=
'NO',
enabled
IN
VARCHAR2
:=
'YES')
RETURN
PLS_INTEGER;
DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE
(
attribute_name
IN
VARCHAR2,
attribute_value
IN
VARCHAR2,
fixed
IN
VARCHAR2
:=
'NO',
enabled
IN
VARCHAR2
:=
'YES')
RETURN
PLS_INTEGER;
Enkitec
(c)
2014
One
of
possible
attribute
names:
• 'SQL_TEXT'
(like)
• 'PARSING_SCHEMA_NAME'
(equality)
• 'MODULE'
(equality)
• 'ACTION'
(equality)
SQL
text
to
use
in
identifying
the
SQL
plan
baseline
into
which
the
plans
are
loaded.
If
the
SQL
plan
baseline
does
not
exist,
it
is
created.
The
use
of
text
is
crucial
when
the
user
tunes
a
SQL
statement
by
adding
hints
to
its
text
and
then
wants
to
load
the
resulting
plan(s)
into
the
SQL
plan
baseline
of
the
original
SQL
statement.
SQL
handle
to
use
in
identifying
the
SQL
plan
baseline
into
which
the
plans
are
loaded.
The
sql_handle
must
denote
an
existing
SQL
plan
baseline.
The
use
of
handle
is
crucial
when
the
user
tunes
a
SQL
statement
by
adding
hints
to
its
text
and
then
wants
to
load
the
resulting
plan(s)
into
the
SQL
plan
baseline
of
the
original
SQL
statement.
Plan
identifier.
Default
NULL
means
capture
all
plans
present
in
the
cursor
cache
for
the
SQL
statement
identified
by
SQL_ID.
23. SQL
Plan
Baseline
Loading
OpPons
• Load
a
Plan
from
a
Hinted
version
of
a
SQL
into
SQL
Baseline
of
Original
SQL
– Use
SQL
Text
if
there
is
no
pre-‐exisPng
SQL
Baseline
– Use
SQL
Handle
if
SQL
Baseline
already
exists
• Load
one
or
more
Cursor
Plans
(memory)
for
a
SQL
• Load
Plans
for
Subset
of
Cursors
based
on
Schema,
SQL
Text
“like”
or
ApplicaPon
(Module
or
AcPon)
Enkitec
(c)
2014
23
24. Demo
6
• Load
Plans
for
Query
out
of
Demo
5
– demo5.sql
(1st
Pme)
– load_plans.sql
• Execute
Demo
5
again
and
review
Plan
History
– demo5.sql
(2nd
Pme)
– list_plans.sql
• Execute
demo5.sql
2x
(3rd
&
4th)
and
verify
results
Enkitec
(c)
2014
24
25. Demo
6
Results
(aqer
3rd
demo5.sql)
CHILD
EXECUTIONS
BUFFER_GETS
PLAN_HASH_VALUE
SHAR
SENS
AWRE
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐
-‐-‐-‐-‐
-‐-‐-‐-‐
0
3
9090
3600618656
Y
Y
N
CHILD
BUCKET_ID
COUNT
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
0
0
0
0
1
1
0
2
2
Note
-‐-‐-‐-‐-‐
-‐
SQL
plan
baseline
SQL_PLAN_652hmt7yxthdwc0e59472
used
for
this
statement
CREATED
PLAN_NAME
ENA
ACC
REP
FIX
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐
-‐-‐-‐
-‐-‐-‐
-‐-‐-‐
21-‐JUN-‐14
02.00.10.000000
PM
SQL_PLAN_652hmt7yxthdw80508062
YES
YES
YES
NO
21-‐JUN-‐14
02.00.10.000000
PM
SQL_PLAN_652hmt7yxthdwc0e59472
YES
YES
YES
NO
21-‐JUN-‐14
02.00.10.000000
PM
SQL_PLAN_652hmt7yxthdwe00bee24
YES
YES
YES
NO
21-‐JUN-‐14
02.00.19.000000
PM
SQL_PLAN_652hmt7yxthdwc82a6b0c
YES
NO
YES
NO
Enkitec
(c)
2014
25
26. Demo
6
Results
(aqer
4th
demo5.sql)
CHILD
EXECUTIONS
BUFFER_GETS
PLAN_HASH_VALUE
SHAR
SENS
AWRE
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐
-‐-‐-‐-‐
-‐-‐-‐-‐
0
2
723482
847574763
N
Y
N
1
1
2404
3600618656
Y
Y
Y
2
1
1977
189372815
Y
Y
Y
3
1
568
847574763
Y
Y
Y
Note
-‐-‐-‐-‐-‐
-‐
SQL
plan
baseline
SQL_PLAN_652hmt7yxthdw80508062
used
for
this
statement
CREATED
PLAN_NAME
ENA
ACC
REP
FIX
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐
-‐-‐-‐
-‐-‐-‐
-‐-‐-‐
28-‐DEC-‐13
02.03.43.000000
PM
SQL_PLAN_652hmt7yxthdw501f1424
YES
YES
YES
NO
28-‐DEC-‐13
02.03.43.000000
PM
SQL_PLAN_652hmt7yxthdwb6c39290
YES
YES
YES
NO
28-‐DEC-‐13
02.03.43.000000
PM
SQL_PLAN_652hmt7yxthdwd624c0cd
YES
YES
YES
NO
28-‐DEC-‐13
02.03.50.000000
PM
SQL_PLAN_652hmt7yxthdwc82a6b0c
YES
NO
YES
NO
Enkitec
(c)
2014
26
27. Demo
7
• Drop
SQL
Plan
Baseline
– drop_plans.sql
• Create
SQL
Patch
with
/*+
BIND_AWARE
*/
Hint
– sqlpch.sql
for
8u0n7w1jug5dg
connected
as
SYS
• Load
Plans
for
Query
out
of
Demo
5
– demo5.sql
– load_plans.sql
Enkitec
(c)
2014
27
28. Demo
7
Results
CHILD
EXECUTIONS
BUFFER_GETS
PLAN_HASH_VALUE
SHAR
SENS
AWRE
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐
-‐-‐-‐-‐
-‐-‐-‐-‐
0
1
2191
847574763
N
Y
Y
1
1
3030
2048551027
Y
Y
Y
2
1
2404
3600618656
Y
Y
Y
3
1
1977
189372815
Y
Y
Y
4
1
568
847574763
Y
Y
Y
CREATED
PLAN_NAME
ENA
ACC
REP
FIX
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐
-‐-‐-‐
-‐-‐-‐
-‐-‐-‐
21-‐JUN-‐14
02.09.14.000000
PM
SQL_PLAN_652hmt7yxthdw80508062
YES
YES
YES
NO
21-‐JUN-‐14
02.09.14.000000
PM
SQL_PLAN_652hmt7yxthdwc0e59472
YES
YES
YES
NO
21-‐JUN-‐14
02.09.14.000000
PM
SQL_PLAN_652hmt7yxthdwc82a6b0c
YES
YES
YES
NO
21-‐JUN-‐14
02.09.14.000000
PM
SQL_PLAN_652hmt7yxthdwe00bee24
YES
YES
YES
NO
Enkitec
(c)
2014
28
29. Demo
8
• Execute
queries
1-‐5
and
observe
how
number
of
ExecuPons
increases
per
Child
Cursor
– flush.sql
– demo8.sql
– demo8.sql
– demo8.sql
Enkitec
(c)
2014
29
30. Demo
8
Results
CHILD
EXECUTIONS
BUFFER_GETS
PLAN_HASH_VALUE
SHAR
SENS
AWRE
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐
-‐-‐-‐-‐
-‐-‐-‐-‐
0
1
3030
2048551027
Y
Y
Y
1
1
2404
3600618656
Y
Y
Y
2
1
1977
189372815
Y
Y
Y
3
1
568
847574763
N
Y
Y
4
1
724
847574763
Y
Y
Y
Note
-‐-‐-‐-‐-‐
-‐
SQL
patch
"sqlpch_8u0n7w1jug5dg"
used
for
this
statement
-‐
SQL
plan
baseline
SQL_PLAN_652hmt7yxthdwb6c39290
used
for
this
statement
CHILD
EXECUTIONS
BUFFER_GETS
PLAN_HASH_VALUE
SHAR
SENS
AWRE
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐
-‐-‐-‐-‐
-‐-‐-‐-‐
0
2
6060
2048551027
Y
Y
Y
1
2
4808
3600618656
Y
Y
Y
2
2
3954
189372815
Y
Y
Y
3
1
568
847574763
N
Y
Y
4
3
2016
847574763
Y
Y
Y
Enkitec
(c)
2014
30
31. Evolving
a
Plan
(1)
• Evolving
a
Plan
means
“accepPng”
it
– PromoPng
it
from
Plan
History
into
SQL
Plan
Baseline
• dbms_spm.evolve_sql_plan_baseline
– sql_handle
(opt)
– plan_name
(opt)
– verify
(default
YES)
– commit
(default
YES)
Enkitec
(c)
2014
31
32. Enkitec
(c)
2014
32
DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE
(
sql_handle
IN
VARCHAR2
:=
NULL,
plan_name
IN
VARCHAR2
:=
NULL,
time_limit
IN
INTEGER
:=
DBMS_SPM.AUTO_LIMIT,
verify
IN
VARCHAR2
:=
'YES',
commit
IN
VARCHAR2
:=
'YES')
RETURN
CLOB;
DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE
(
plan_list
IN
DBMS_SPM.NAME_LIST,
time_limit
IN
INTEGER
:=
DBMS_SPM.AUTO_LIMIT,
verify
IN
VARCHAR2
:=
'YES',
commit
IN
VARCHAR2
:=
'YES')
RETURN
CLOB;
Evolving
a
Plan
(2)
33. Demo
9
• Drop
SQL
Plan
Baseline
– drop_plans.sql
• Capture
SQL
Plan
Baseline
with
1
accepted
Plan
– demo9.sql
– list_plans.sql
• Evolve
all
Plans
on
Plan
History
– evolve.sql
Enkitec
(c)
2014
33
34. FIXED
Flag
• When
set
to
YES
– Only
FIXED
Plans
are
considered
for
Plan
SelecPon
– No
more
Plans
are
Captured
into
Plan
History
Enkitec
(c)
2014
34
35. Alter
SQL
Plan
Baselines
Enkitec
(c)
2014
35
DBMS_SPM.ALTER_SQL_PLAN_BASELINE
(
sql_handle
IN
VARCHAR2
:=
NULL,
plan_name
IN
VARCHAR2
:=
NULL,
attribute_name
IN
VARCHAR2,
attribute_value
IN
VARCHAR2)
RETURN
PLS_INTEGER;
Attribute
Names
&
Values:
enabled
'YES'
or
'NO'
fixed
'YES'
or
'NO'
autopurge
'YES'
or
'NO'
plan_name
String
of
up
to
30-‐characters
description
String
of
up
to
500-‐characters
36. Plan
SelecPon
(1)
• At
hard
parse
when
SQL
Plan
Baseline
(SPB)
exists
1. CBO
computes
an
“OpPmal”
Plan
(OP)
• AdapPve
Cursor
Sharing
is
used
if
applicable
2. If
OP
exists
in
SPB
then
execute
this
OP
3. If
OP
does
not
exist
in
SPB
then
store
it
in
Plan
History
a. If
there
are
FIXED
Plans
in
SPB
i. Re-‐cost
all
FIXED
Plans
using
Binds
and
execute
cheapest
b. If
there
are
no
FIXED
Plans
in
SPM
i. Re-‐cost
all
Plans
using
Binds
and
execute
cheapest
Enkitec
(c)
2014
36
38. Demo
10
• FIX
one
Plan
from
SQL
Plan
Baseline
– alter_plans.sql
• Verify
only
one
Plan
was
Executed
– flush.sql
– demo8.sql
– demo8.sql
Enkitec
(c)
2014
38
39. SPM
Summary
Enkitec
(c)
2014
39
• SPM
provides
much
desired
Plan
Stability
– Only
“approved”
Plans
are
allowed
to
Execute
• ACS
can
generate
a
healthy
stock
of
OpPmal
Plans
– You
can
restrict
them
to
work
under
SPM
• Combining
ACS
and
SPM
you
can
obtain
– Plan
Flexibility
and
Plan
Stability
40. ACS
Suggested
Strategy
• Use
sys.dbms_sqldiag_internal.i_create_patch
to
SQL
Patch
with
BIND_AWARE
the
SQL
on
Baselines
• Use
free
script
sqlpch.sql
Enkitec
(c)
2014
40
41. SPM
Suggested
Strategies
1. ConservaPve
– One
SQL
at
a
Pme
2. Moderate
– One
ApplicaPon
at
a
Pme
(Module
or
AcPon)
– One
Schema
at
a
Pme
3. Aggressive
(a.k.a.
Cowboy
method)
– All
ApplicaPon
Schemas
at
once
Enkitec
(c)
2014
41