Managing SQL Profiles
Managing SQL Profiles
can use
Part VI Optimizer Controls About SQL Pro�le
DBMS_SQLTUNE Implementation
A SQL pro�le is
a database
object that
contains
auxiliary
statistics
speci�c to a SQL
statement.
Conceptually, a
SQL pro�le is to
a SQL statement
what object-
level statistics
are to a table or
index. SQL
pro�les are
created when a
DBA invokes
SQL Tuning
Advisor.
See Also:
"About SQL
Tuning Advisor"
Purpose of
SQL Pro�les
When pro�ling a
SQL statement,
SQL Tuning
Advisor uses a
speci�c set of
bind values as
input.
The advisor
compares the
optimizer
estimate with
values obtained
by executing
fragments of the
statement on a
data sample.
When signi�cant
variances are
found, SQL
Tuning Advisor
bundles
corrective
actions together
in a SQL pro�le,
and then
recommends its
acceptance.
The corrected
statistics in a
SQL pro�le can
improve
optimizer
cardinality
estimates, which
in turn leads the
optimizer to
select be�er
plans. SQL
pro�les provide
the following
bene�ts over
other
techniques for
improving plans:
• Unlik
e
hints
and
store
d
outli
nes,
SQL
pro�l
es do
not
tie
the
opti
mizer
to a
speci
�c
plan
or
subpl
an.
SQL
pro�l
es �x
incor
rect
estim
ates
while
givin
g the
opti
mizer
the
�exib
ility
to
pick
the
best
plan
in
di�er
ent
situat
ions.
• Unlik
e
hints,
no
chan
ges
to
appli
catio
n
sourc
e
code
are
nece
ssary
when
using
SQL
pro�l
es.
The
use
of
SQL
pro�l
es by
the
data
base
is
trans
pare
nt to
the
user.
See Also:
• "In�u
encin
g the
Opti
mizer
with
Hints
"
• "Anal
yzing
SQL
with
SQL
Tunin
g
Advis
or"
Concepts for
SQL Pro�les
A SQL pro�le is
a collection of
auxiliary
statistics on a
query, including
all tables and
columns
referenced in
the query.
The pro�le is
stored in an
internal format
in the data
dictionary. The
user interface is
the
DBA_SQL_PROF
ILES dictionary
view. The
optimizer uses
this information
during
optimization to
determine the
most optimal
plan.
See Also:
Oracle Database
Reference to
learn more
about
DBA_SQL_PROF
ILES
Statistics in
SQL Pro�les
A SQL pro�le
contains, among
other statistics,
a set of
cardinality
adjustments.
The cardinality
measure is
based on
sampling the
WHERE clause
rather than on
statistical
projection. A
pro�le uses
parts of the
query to
determine
whether the
estimated
cardinalities are
close to the
actual
cardinalities
and, if a
mismatch exists,
uses the
corrected
cardinalities. For
example, if a
SQL pro�le
exists for
SELECT *
FROM t WHERE
x=5 AND y=10,
then the pro�le
Starting in
Oracle Database
��c, SQL Tuning
Advisor can
recommend an
Exadata-aware
SQL pro�le. On
Oracle Exadata
Database
Machine, the
cost of smart
scans depends
on the system
statistics I/O
seek time
(ioseektim),
multiblock read
count (mbrc),
and I/O transfer
speed
(iotfrspeed).
The values of
these statistics
usually di�er on
Exadata and can
thus in�uence
the choice of
plan. If system
statistics are
stale, and if
gathering them
improves
performance,
then SQL
Tuning Advisor
recommends
accepting an
Exadata-aware
SQL pro�le.
See Also:
• "Per
mane
nt
Table
Statis
tics"
• Oracl
e
Data
base
Perfo
rman
ce
Tunin
g
Guid
e to
learn
abou
t
syste
m
statis
tics
• Oracl
e
Exad
ata
Data
base
Mach
ine
Syste
m
Over
view
SQL Pro�les
and
Execution
Plans
determine a
speci�c plan.
Internally, a SQL
pro�le is
implemented
using hints that
address
di�erent types
of problems.
These hints do
not specify any
particular plan.
Rather, the hints
correct errors in
the optimizer
estimation
algorithm that
lead to
suboptimal
plans. For
example, a
pro�le may use
the
TABLE_STATS
hint to set object
statistics for
tables when the
statistics are
missing or stale.
When choosing
plans, the
optimizer has
the following
sources of
information:
• The
envir
onm
ent,
whic
h
conta
ins
the
data
base
con�
gurat
ion,
syste
m
statis
tics,
bind
varia
ble
value
s,
opti
mizer
statis
tics,
data
set,
and
so on
• The
suppl
emen
tal
statis
tics
in the
SQL
pro�l
e
The following
�gure shows the
relationship
between a SQL
statement and
the SQL pro�le
for this
statement. The
optimizer uses
the SQL pro�le
and the
environment to
generate an
execution plan.
In this example,
the plan is in the
SQL plan
baseline for the
statement.
Figure ��-�
SQL Pro�le
Description of
"Figure ��-�
SQL Pro�le"
If either the
optimizer
environment or
SQL pro�le
changes, then
the optimizer
can create a new
plan. As tables
grow, or as
indexes are
created or
dropped, the
plan for a SQL
pro�le can
change. The
pro�le continues
to be relevant
even if the data
distribution or
access path of
the
corresponding
statement
changes.
In general, you
do not need to
refresh SQL
pro�les. Over
time, however,
pro�le content
can become
outdated. In this
case,
performance of
the SQL
statement may
degrade. The
statement may
appear as high-
load or top SQL.
See Also:
• "Di�e
rence
s
Betw
een
SQL
Plan
Basel
ines
and
SQL
Pro�l
es"
• "Intro
ducti
on to
Opti
mizer
Statis
tics"
• Oracl
e
Data
base
SQL
Lang
uage
Refer
ence
to
learn
abou
t SQL
hints
SQL Pro�le
Recommenda
tions
SQL Tuning
Advisor invokes
Automatic
Tuning
Optimizer to
generate SQL
pro�le
recommendatio
ns.
Recommendatio
ns to implement
SQL pro�les
occur in a
�nding, which
appears in a
separate section
of the SQL
Tuning Advisor
report. When
you implement
(or accept) a
SQL pro�le, the
database
creates the
pro�le and
stores it
persistently in
the data
dictionary.
However, the
SQL pro�le
information is
not exposed
through regular
dictionary views.
Example ��-�
SQL Pro�le
Recommendati
on
In this example,
the database
found a be�er
plan for a
SELECT
statement that
uses several
expensive joins.
The database
recommends
running
DBMS_SQLTUNE
.ACCEPT_SQL_
PROFILE to
implement the
pro�le, which
enables the
statement to run
��.��% faster.
----------------------------
Copy SECTION (2 findings
FINDINGS
----------------------------
Recommendation (estimated
--------------------------
- Consider accepting the r
execute dbms_sqltune.acc
object_id => 3,
Validation results
------------------
The SQL profile was tested
plan and measuring their r
have been only partially e
completion in less time.
O
-
Completion Status:
Elapsed Time(us):
CPU Time(us):
User I/O Time(us):
Buffer Gets:
Disk Reads:
Direct Writes:
Rows Processed:
Fetches:
Executions:
Notes
-----
1. The SQL profile plan wa
2. Statistics for the SQL
Sometimes SQL
Tuning Advisor
may
recommend
implementing a
pro�le that uses
the Automatic
Degree of
Parallelism
(Auto DOP)
feature. A
parallel query
pro�le is only
recommended
when the
original plan is
serial and when
parallel
execution can
signi�cantly
reduce the
elapsed time for
a long-running
query.
When it
recommends a
pro�le that uses
Auto DOP, SQL
Tuning Advisor
gives details
about the
performance
overhead of
using parallel
execution for
the SQL
statement in the
report. For
parallel
execution
recommendatio
ns, SQL Tuning
Advisor may
provide two SQL
pro�le
recommendatio
ns, one using
serial execution
and one using
parallel.
The following
example shows
a parallel query
recommendatio
n. In this
example, a
degree of
parallelism of �
improves
response time
signi�cantly at
the cost of
increasing
resource
consumption by
almost ��%. You
must decide
whether the
reduction in
database
throughput is
worth the
increase in
response time.
Recommendation (estimated
--------------------------
Copy
Number of executions
Percent of total activity
Percent of samples with #A
Weekly DB time (in sec)
See Also:
• "SQL
Pro�l
ing"
• Oracl
e
Data
base
VLDB
and
Partit
ionin
g
Guid
e to
learn
more
abou
t
Auto
DOP
• Oracl
e
Data
base
PL/
SQL
Pack
ages
and
Type
s
Refer
ence
to
learn
abou
t the
DBMS
_SQL
TUNE
.ACC
EPT_
SQL_
PROF
ILE
proce
dure
SQL Pro�les
and SQL Plan
Baselines
No strict
relationship
exists between
the SQL pro�le
and a SQL plan
baseline. If a
statement has
multiple plans in
a SQL plan
baseline, then a
SQL pro�le is
useful because it
enables the
optimizer to
choose the
lowest-cost plan
in the baseline.
See Also:
"Overview of
SQL Plan
Management"
User
Interfaces
for SQL
Pro�les
Oracle
Enterprise
Manager Cloud
Control (Cloud
Control) usually
handles SQL
pro�les as part
of automatic
SQL tuning.
On the
command line,
you can manage
SQL pro�les
with the
DBMS_SQLTUNE
package. To use
the APIs, you
must have the
ADMINISTER
SQL
MANAGEMENT
OBJECT
privilege.
See Also:
• Oracl
e
Data
base
PL/
SQL
Pack
ages
and
Type
s
Refer
ence
for
infor
mati
on
abou
t the
DBMS
_SQL
TUNE
pack
age
• Oracl
e
Data
base
Get
Start
ed
with
Perfo
rman
ce
Tunin
g to
learn
how
to
mana
ge
SQL
pro�l
es
with
Clou
d
Contr
ol
Basic Tasks
for SQL
Pro�les
Basic tasks
include
accepting
(implementing)
a SQL pro�le,
altering it, listing
it, and dropping
it.
The following
graphic shows
the basic
work�ow.
Figure ��-�
Managing SQL
Pro�les
Description of
"Figure ��-�
Managing SQL
Pro�les"
Typically, you
manage SQL
pro�les in the
following
sequence:
�. Imple
ment
a
reco
mme
nded
SQL
pro�l
e.
"Impl
emen
ting a
SQL
Pro�l
e"
descr
ibes
this
task.
�. Obtai
n
infor
mati
on
abou
t SQL
pro�l
es
store
d in
the
data
base.
"Listi
ng
SQL
Pro�l
es"
descr
ibes
this
task.
�. Optio
nally,
modi
fy
the
imple
ment
ed
SQL
pro�l
e.
"Alter
ing a
SQL
Pro�l
e"
descr
ibes
this
task.
�. Drop
the
imple
ment
ed
SQL
pro�l
e
when
it is
no
longe
r
need
ed.
"Dro
ppin
ga
SQL
Pro�l
e"
descr
ibes
this
task.
To tune SQL
statements on
another
database, you
can transport
both a SQL
tuning set and a
SQL pro�le to a
separate
database.
"Transporting a
SQL Pro�le"
describes this
task.
See Also:
Oracle Database
PL/SQL
Packages and
Types Reference
for information
about the
DBMS_SQLTUNE
package
Implement
ing a SQL
Pro�le
Implementing a
SQL pro�le
means storing it
persistently in
the database.
Implementing a
pro�le is the
same as
accepting it. A
pro�le must be
accepted before
the optimizer
can use it as
input when
generating
plans.
About SQL
Pro�le
Implementa
tion
As a rule of
thumb,
implement a
SQL pro�le
recommended
by SQL Tuning
Advisor.
If the database
recommends
both an index
and a SQL
pro�le, then
either use both
or use the SQL
pro�le only. If
you create an
index, then the
optimizer may
need the pro�le
to pick the new
index.
In some
situations, SQL
Tuning Advisor
may �nd an
improved serial
plan in addition
to an even
be�er parallel
plan. In this
case, the advisor
recommends
both a standard
and a parallel
SQL pro�le,
enabling you to
choose between
the best serial
and best parallel
plan for the
statement.
Implement a
parallel plan
only if the
increase in
response time is
worth the
decrease in
throughput.
To implement a
SQL pro�le,
execute the
DBMS_SQLTUNE
.ACCEPT_SQL_
PROFILE
procedure.
Some important
parameters are
as follows:
• prof
ile_
type
Set
this
para
mete
r to
REGU
LAR_
PROF
ILE
for a
SQL
pro�l
e
witho
ut a
chan
ge to
parall
el
exec
ution
, or
PX_P
ROFL
E for
a
SQL
pro�l
e
with
a
chan
ge to
parall
el
exec
ution
.
• forc
e_ma
tch
This
para
mete
r
contr
ols
state
ment
matc
hing.
Typic
ally,
an
acce
pted
SQL
pro�l
e is
assoc
iated
with
the
SQL
state
ment
throu
gh a
SQL
signa
ture
that
is
gene
rated
using
a
hash
funct
ion.
This
hash
funct
ion
chan
ges
the
SQL
state
ment
to
uppe
r
case
and
remo
ves
all
extra
white
spac
e
befor
e
gene
ratin
g the
signa
ture.
Thus,
the
same
SQL
pro�l
e
work
s for
all
SQL
state
ment
s in
whic
h the
only
di�er
ence
is
case
and
white
spac
es.
By
se�in
g
forc
e_ma
tch
to
true
, the
SQL
pro�l
e
additi
onall
y
targe
ts all
SQL
state
ment
s that
have
the
same
text
after
the
literal
value
s in
the
WHER
E
claus
e
have
been
repla
ced
by
bind
varia
bles.
This
se�in
g
may
be
usefu
l for
appli
catio
ns
that
use
only
literal
value
s
beca
use it
enabl
es
SQL
with
text
di�er
ing
only
in its
literal
value
s to
share
a
SQL
pro�l
e. If
both
literal
value
s and
bind
varia
bles
are in
the
SQL
text,
or if
forc
e_ma
tch
is set
to
fals
e
(defa
ult),
then
the
literal
value
s in
the
WHER
E
claus
e are
not
repla
ced
by
bind
varia
bles.
See Also:
Oracle Database
PL/SQL
Packages and
Types Reference
for information
about the
ACCEPT_SQL_P
ROFILE
procedure
Implementin
g a SQL
Pro�le
To implement a
SQL pro�le, use
the
DBMS_SQLTUNE
.ACCEPT_SQL_
PROFILE
procedure.
Assumptions
This tutorial
assumes the
following:
• The
SQL
Tunin
g
Advis
or
task
STA_
SPEC
IFIC
_EMP
_TAS
K
inclu
des a
reco
mme
ndati
on to
creat
ea
SQL
pro�l
e.
• The
name
of
the
SQL
pro�l
e is
my_s
ql_p
rofi
le.
• The
PL/
SQL
block
acce
pts a
pro�l
e
that
uses
parall
el
exec
ution
(pro
file
_typ
e).
• The
pro�l
e
uses
force
matc
hing.
To implement a
SQL pro�le:
�. In
SQL*
Plus
or
SQL
Devel
oper,
log in
to
the
data
base
as a
user
with
the
nece
ssary
privil
eges.
�. Exec
ute
the
ACCE
PT_S
QL_P
ROFI
LE
funct
ion.
For
exam
ple,
exec
ute
the
follo
wing
PL/
SQL:
DECLARE
my_sqlprofile_nam
BEGIN
my_sqlprofile_nam
task_name =>
, name =>
, profile_type =>
, force_match =>
);
END;
/
See Also:
Oracle Database
PL/SQL
Packages and
Types Reference
to learn about
the
DBMS_SQLTUNE
.ACCEPT_SQL_
PROFILE
procedure
Listing
SQL
Pro�les
The data
dictionary view
DBA_SQL_PROF
ILES stores SQL
pro�les
persistently in
the database.
The pro�le
statistics are in
an Oracle
Database
internal format,
so you cannot
query pro�les
directly.
However, you
can list pro�les.
To list SQL
pro�les:
�. In
SQL*
Plus
or
SQL
Devel
oper,
log in
to
the
data
base
as a
user
with
the
nece
ssary
privil
eges.
�. Quer
y the
DBA_
SQL_
PROF
ILES
view.
For
exam
ple,
exec
ute
the
follo
wing
quer
y:
Sam
ple
outp
ut
appe
ars
belo
w:
NAME
-------------------
SYS_SQLPROF_01285f6
See Also:
Oracle Database
Reference to
learn about the
DBA_SQL_PROF
ILES view
Altering a
SQL Pro�le
The CATEGORY
a�ribute
determines
which sessions
can apply a
pro�le. View the
CATEGORY
a�ribute by
querying
DBA_SQL_PROF
ILES.CATEGOR
Y. By default, all
pro�les are in
the DEFAULT
category, which
means that all
sessions in
which the
SQLTUNE_CATE
GORY
initialization
parameter is set
to DEFAULT can
use the pro�le.
By altering the
category of a
SQL pro�le, you
determine which
sessions are
a�ected by
pro�le creation.
For example, by
se�ing the
category to DEV,
only sessions in
which the
SQLTUNE_CATE
GORY
initialization
parameter is set
to DEV can use
the pro�le.
Other sessions
do not have
access to the
SQL pro�le and
execution plans
for SQL
statements are
not impacted by
the SQL pro�le.
This technique
enables you to
test a pro�le in a
restricted
environment
before making it
available to
other sessions.
The example in
this section
assumes that
you want to
change the
category of the
SQL pro�le so it
is used only by
sessions with
the SQL pro�le
category set to
TEST, run the
SQL statement,
and then
change the
pro�le category
back to
DEFAULT.
To alter a SQL
pro�le:
�. In
SQL*
Plus
or
SQL
Devel
oper,
log in
to
the
data
base
as a
user
with
the
nece
ssary
privil
eges.
�. Use
the
ALTE
R_SQ
L_PR
OFIL
E
proce
dure
to set
the
attr
ibut
e_na
me.
For
exam
ple,
exec
ute
the
follo
wing
code
to set
the
a�rib
ute
CATE
GORY
to
TEST
�. Chan
ge
the
initial
izatio
n
para
mete
r
se�in
g in
the
curre
nt
data
base
sessi
on.
For
exam
ple,
exec
ute
the
follo
wing
SQL:
SESSION SET S
ALTER
�. Test
the
pro�l
ed
SQL
state
ment
.
�. Use
the
ALTE
R_SQ
L_PR
OFIL
E
proce
dure
to set
the
attr
ibut
e_na
me.
For
exam
ple,
exec
ute
the
follo
wing
code
to set
the
a�rib
ute
CATE
GORY
to
DEFA
ULT:
See Also:
• Oracl
e
Data
base
Refer
ence
to
learn
abou
t the
SQLT
UNE_
CATE
GORY
initial
izatio
n
para
mete
r
• Oracl
e
Data
base
PL/
SQL
Pack
ages
and
Type
s
Refer
ence
to
learn
abou
t the
ALTE
R_SQ
L_PR
OFIL
E
proce
dure
Dropping a
SQL Pro�le
Assumptions
This section
assumes the
following:
• You
want
to
drop
my_s
ql_p
rofi
le.
• You
want
to
ignor
e
error
s
raise
d if
the
name
does
not
exist.
To drop a SQL
pro�le:
�. In
SQL*
Plus
or
SQL
Devel
oper,
log in
to
the
data
base
as a
user
with
the
nece
ssary
privil
eges.
�. Use
the
DBMS
_SQL
TUNE
.DRO
P_SQ
L_PR
OFIL
E
proce
dure.
The
follo
wing
exam
ple
drop
s the
pro�l
e
nam
ed
my_s
ql_p
rofi
le:
BEGIN
DBMS_SQLTUNE.DROP
name => 'my_sql
);
END;
/
See Also:
• Oracl
e
Data
base
PL/
SQL
Pack
ages
and
Type
s
Refer
ence
to
learn
abou
t the
DROP
_SQL
_PRO
FILE
proce
dure
• Oracl
e
Data
base
Refer
ence
to
learn
abou
t the
SQLT
UNE_
CATE
GORY
initial
izatio
n
para
mete
r
Transporti
ng a SQL
Pro�le
Table ��-�
shows the main
procedures and
functions for
managing SQL
pro�les.
Procedure or
Function
CREATE_STGTA
B_SQLPROF
PACK_STGTAB_
SQLPROF
UNPACK_STGTA
B_SQLPROF
The following
graphic shows
the basic
work�ow of
transporting
SQL pro�les.
Figure ��-�
Transporting
SQL Pro�les
Description of
"Figure ��-�
Transporting
SQL Pro�les"
Assumptions
This tutorial
assumes the
following:
• You
want
to
trans
port
my_p
rofi
le
from
a
prod
uctio
n
data
base
to a
test
data
base.
• You
want
to
creat
e the
stagi
ng
table
in the
dba1
sche
ma.
To transport a
SQL pro�le:
�. Conn
ect
SQL*
Plus
to
the
data
base
with
the
appr
opria
te
privil
eges,
and
then
use
the
CREA
TE_S
TGTA
B_SQ
LPRO
F
proce
dure
to
creat
ea
stagi
ng
table
to
hold
the
SQL
pro�l
es.
The
follo
wing
exam
ple
creat
es
my_s
tagi
ng_t
able
in the
dba1
sche
ma:
BEGIN
DBMS_SQLTUNE.CREA
table_name =>
, schema_name =>
);
END;
/
�. Use
the
PACK
_STG
TAB_
SQLP
ROF
proce
dure
to
expo
rt
SQL
pro�l
es
into
the
stagi
ng
table.
The
follo
wing
exam
ple
popu
lates
dba1
.my_
stag
ing_
tabl
e
with
the
SQL
pro�l
e
my_p
rofi
le:
BEGIN
DBMS_SQLTUNE.PACK
profile_name
, staging_table_n
, staging_schema_
);
END;
/
�. Move
the
stagi
ng
table
to
the
data
base
wher
e you
plan
to
unpa
ck
the
SQL
pro�l
es.
Move
the
table
using
your
utility
of
choic
e. For
exam
ple,
use
Oracl
e
Data
Pum
p or a
data
base
link.
�. On
the
data
base
wher
e you
plan
to
impo
rt the
SQL
pro�l
es,
use
UNPA
CK_S
TGTA
B_SQ
LPRO
F to
unpa
ck
SQL
pro�l
es
from
the
stagi
ng
table.
The
follo
wing
exam
ple
show
s
how
to
unpa
ck
SQL
pro�l
es in
the
stagi
ng
table:
BEGIN
DBMS_SQLTUNE.UNPA
replace
, staging_table_
);
END;
/
See Also:
• Oracl
e
Data
base
PL/
SQL
Pack
ages
and
Type
s
Refer
ence
for
comp
lete
refer
ence
infor
mati
on
abou
t
DBMS
_SQL
TUNE
• Oracl
e
Data
base
Utiliti
es to
learn
how
to
use
Oracl
e
Data
Pum
p
Previous Page
Next Page
© Oracle About Oracle Contact Us Products A-Z Terms of Use & Privacy Cookie Preferences Ad Choices