Boost SQL Perormance with

cursor_sharing
.v Oract 7cbvicat !bit Papr
]vty 21
Boost SQL Perormance with cursor_sharing Page 2
Boost SQL Perormance with cursor_sharing
EXECUTIVE OVERVIEW
This paper describes enhancements to the cursor sharing inrastructure, added in
Oracle8i Release 2, and Oracle9i. These enhancements are controlled by a new
parameter cursor_sharing.
The goal o cursor_sharing is to improe serer perormance or applications
that don`t use bind ariables eerywhere.
NEED FOR CURSOR_SHARING
This section explains why applications not using bind ariables run into
perormance problems.
Applications execute similar SQL statements repeatedly
Applications that use an Oracle database to manage their data must access,modiy
it using SQL statements. These SQL statements are either directly issued by an
application through OtI, OttI, DBt, PL,SQL etc., or indirectly issued through
other utilities or libraries e.g. dbms_sql,.
An application typically proides a ixed collection o unctions to the end user
depending on the type o application, e.g. an lR application might proide
unctionality like adding a new employee, modiying personal inormation about an
employee, etc. Lery such unctionality eentually accesses and,or modiies data
using SQL. Since applications repeatedly execute such unctionality, an
application`s interaction with an Oracle database consists o repeated execution o
similar SQL statements.
Steps involved in executing SQL
To execute a SQL statement, a client program can go through a ew dierent
interaces. For example, through OtI a client creates a statement handle, then
prepares the statement, binds, deines, and executes the statement handle. Or, a
SQL statement can be executed through a PL,SQL procedure by directly
embedding it in the procedure text.
Regardless o the client interace, an Oracle database always goes through some
ixed steps by deault,.
Boost SQL Perormance with cursor_sharing Page 3
1. open a user cursor A user cursor is a handle to all other user state
associated with any SQL statement like execution memory, reerence to the
shared cursor, current state o the user cursor, etc.
2. parse a SQL statement into the open user cursor Doing this associates the
SQL statement with the user cursor, it also creates a shared cursor, which
corresponds to the parsed orm o the SQL statement. The shared cursor
may also be typechecked and optimized as a part o the parse, in some cases.
The process o parsing, typechecking and optimizing a SQL statement is
typically ery resource intensie in terms o tPU, memory and latch
contention.
3. bind ariables, i necessary This proides Oracle with the necessary
inormation about the type, size, alue, etc. o the bind ariables in the
statement.
4. typecheck and optimize the shared cursor, i not already done
5. execute the user cursor This step does the actual work o executing the
statement, and will use up tPU and session memory depending on the
complexity o the statement.
Note that parse, typecheck and optimization collectiely called compilation in this
document, comprise the bulk o the oerhead in executing a SQL statement, and
can limit capacity and scalability o the database.
Shared cursors
Gien that a typical application repeatedly executes similar statements, a lot o
optimizations in the Oracle database or SQL processing target repeated
executions. The most important optimization is shared cursors, which tries to
remoe the oerhead o compilation or an aerage execution, by sharing the result
o compilation between dierent executions o the same statement either
happening concurrently, or at ery dierent times,. The picture below illustrates
how this is done.
User Session 1
Private
execution
state
User Session 2
Private
execution
state
Shared Cursor
Boost SQL Perormance with cursor_sharing Page 4
To enable sharing cursors, Oracle splits up the statement execution state into a
shared cursor, and a perexecution instantiation. The shared cursor is the result o
compilation and contains the execution plan, it is cached in the shared pool. Lach
session executing the statement has its priate copy o perexecution state like the
user cursor, alues o runtime ariables, etc.
In the parse step step 2 mentioned earlier,, Oracle irst searches or an existing
shared cursor that can be shared by the user session. Oracle breaks down this
search into two steps. indexing based on the SQL text to ind cursors built or the
same SQL text, and selecting the right cursor based on other criteria like optimizer
modes, base objects accessed, etc. I a sharable cursor is ound then no
compilation needs to happen, and the process is called a sot parse. Llse, a new
shared cursor is built by compiling the SQL statement, and the process is called a
hard parse.
Vhen most o the statements issued by an application can share the same set o
cursors, most o the parses become sot parses, and improe the database serer
capacity,throughput by reducing memory and tPU usage,, responsetime by
reducing the time taken by the parse phase,, and scalability by reducing latch
contention,.
Why cursors are not shared
Assuming that other actors like conigurable instance,session,transaction leel
parameters are the same, cursors or two statements S1 and S2 can theoretically be
shared i they perorm the same operations on the same underlying set o
rows,objects, using the same plan. This can be ery hard and computation
intensie to igure out, potentially destroying the beneits o sharing cursors in the
irst place! lence, Oracle`s cursor sharing criteria don`t share cursors in all the
possible scenarios, but they are designed to be eicient, without losing out on
most o the common cases. Until 8i Release 2, two statements S1 and S2 could
share the same cursor i both S1 and S2 were textually identical, and a ew other
conditions were met any object names in the statements translate to the same base
objects, optimizer modes or the sessions issuing the statements match, etc.,
This causes a cursor sharing problem when applications use literals instead o bind
ariables in statements. Such applications end up producing statements that dier
in some o the literals een when the rest o the statement text is identical. For
example, an application that does not use bind ariables, might issue the ollowing
two statements, at dierent times or rom dierent sessions.
I`IR7 I`7O 7 1.IUI}1, `foo`, 4)
I`IR7 I`7O 7 1.IUI}2, `bar`, )
Since the two statements aren`t textually identical, they end up building separate
cursors.
There are arious reasons why some applications don`t use bind ariables.
Boost SQL Perormance with cursor_sharing Page 5
it`s just easier to write SQL statements with literals, especially with some
tools
older Oracle releases didn`t support bind ariables at least there was no
cursor sharing adantage to using them until Oracle,, and it requires some
work to retroit bind ariables to existing applications
all database endors don`t support bind ariables, or een i they do, the
syntax aries, hence applications lose interoperability with other databases by
using Oracleonly syntax,eatures
I a statement uses bind ariables, then it always uses the same plan. This can
be a problem i the optimal plans or dierent bind alues can be ery
dierent. For example, consider the ollowing statements.
IIIC7 FROM 71, 72 !HIRI }71.` ~ 1) .`D }71.`1 ~ 72.`2)
IIIC7 FROM 71, 72 !HIRI }71.` ~ ) .`D }71.`1 ~ 72.`2)
These two statements can hae dierent optimal plans, depending on the
distribution o alues in the column N. Thus, using a bind ariable, producing.
IIIC7 FROM 71, 72 !HIRI }71.` ~ :`) .`D }71.`1 ~ 72.`2)
will cause the plan to be suboptimal or some alues o the bind ariable. This can
orce applications especially, in a DSS enironment, to use literals instead o bind
ariables.
CONCEPTS
This section describes some necessary concepts, beore going into the solution.
Similar statements
A set o statements will be called similar i any two statements in the set dier only
in the literals.
This is a purely syntactic criterion.
Lxample. The ollowing statements are similar.
I`IR7 I`7O 7 1.IUI}1, `foo`, 4)
I`IR7 I`7O 7 1.IUI}2, `bar`, )
I`IR7 I`7O 7 1.IUI}, `atpba`, 11)
I`IR7 I`7O 7 1.IUI}1, `appa`, 1)
Optimally sharable statements
Similar statements may or may not hae the same execution plans. For example,
the ollowing two statements will hae the same execution plans.
I`IR7 I`7O 7 1.IUI}1, `foo`, 4)
Boost SQL Perormance with cursor_sharing Page 6
I`IR7 I`7O 7 1.IUI}2, `bar`, )
Such statements will be called optimally sharable statements, in this document.
Thus.
Optimally sharahle statements are similar statements that have the same
optimal plan.
This also implies that optimally sharahle statements can share the same cursor,
without any impact on the execution costs.
Sub-optimally sharable statements
On the other hand, the ollowing two statements.
IIIC7 FROM 71, 72 !HIRI }71.` ~ 1) .`D }71.`1 ~ 72.`2)
IIIC7 FROM 71, 72 !HIRI }71.` ~ ) .`D }71.`1 ~ 72.`2)
can hae dierent optimal plans, depending on the rows that satisy N ~ 100,
and N ~ 500,, the distribution o alues in column N, the aailability o an index
on N, N1 or N2, etc. For instance, the irst statement may use an index on T1 and
the second statement may do a ull table scan on T1. Or, the irst statement may
do a hash join and the second statement may do a nested loop join. Such
statements will be reerred to as suboptimally sharahle statements. Thus.
Suh-optimally sharahle statements are similar statements that can have
ditterent optimal plans.
This also implies that i suboptimally sharahle statements share the same cursor,
then there may be a penalty in terms o execution costs.
Optimally sharable vs. suboptimally sharable statements
The distinction between optimally sharahle and suboptimally sharahle statements
is not purely syntactic. It depends on actors like.
the position o literals in the statement e.g. in the VALULS clause, or the
VlLRL clause,
the access paths aailable e.g. presence o an index,
the data distribution statistics, and its aailability, i a literal occurs in a
predicate inoling a column e.g. N ~ 100 with column statistics aailable
on N,
algorithms used by the optimizer, to exploit literals e.g. constant olding, or
partition pruning,
Non-sharable statements
There are cases where similar statements cannot share the same cursor, because
using the same cursor would produce incorrect results. These are similar
Boost SQL Perormance with cursor_sharing Page
statements that mean dierent things, or do something ery dierent during
execution. The ollowing statements illustrate the point.
IIIC7 FROM 7 ORDIR Y 1, 4,
IIIC7 FROM 7 ORDIR Y 2, ,
In the aboe example, the literals 1, 2, 3, and 4 reer to items in the select list. Such
statements will be called nonsharahle statements. Thus.
Non-sharahle statements are similar statements that cannot share the same
execution plan.
The important point to note here is. i two nonsharahle statements share the
same cursor, one o them will get wrong results.
THE SOLUTION
This section describes the solution proided through cursor_sharing.
Overview
The new parameter cursor_sharing allows sharing cursors or similar statements
wheneer possible. Depending on the alue o the parameter, similar statements
can be always orced to share the same cursor potentially using suboptimal plans,,
or can share the same cursor without compromising the optimality o the
underlying plan.
Vith cursor_sharing set to either SIMILAR or FORtL, Oracle irst searches or
a cursor with exactly the same statement text. I such a cursor is not ound, Oracle
searches or a cursor with a similar statement text.
Usage
Parameter: cursor_sharing
A new dynamic parameter cursor_sharing has been introduced starting with 8i
Release 2. In 8i, the parameter can hae two possible alues. FORtL and
LXAtT. Starting with 9i, a new alue SIMILAR has been added.
The deault alue is LXAtT. It only allows statements with the exact same text to
share a cursor. This is the behaior o earlier releases.
The alue SIMILAR causes similar statements to share the same cursors, without
compromising execution plans, i.e. only optimally sharahle statements share
cursors.
Setting the parameter to FORtL will orce Oracle to share cursors or similar
statements, at the risk o suboptimal plans, i.e. both optimally sharahle and
suboptimally sharable statements can share the same cursor. The parameter should
be set to FORtL only when the risk o suboptimal plans is outweighed by the
improements in cursor sharing, e.g. i there are seere perormance problems
caused by too many hard parses o suboptimally shareable statements.
Boost SQL Perormance with cursor_sharing Page 8
SQL statements
A new hint tURSOR_SlARING_LXAtT is allowed in SQL statements to
control cursor sharing at the statement leel. The hint behaes similar to the
initialization parameter, cursor_sharing set to LXAtT, and oerrides the existing
deault behaior based on any setting o the parameter, i.e. it causes the statement
to share a cursor built or a statement with an exact match.
ALTLR S\STLM and ALTLR SLSSION commands allow the new parameter
cursor_sharing to be set or changed. The syntax is as ollows.
ALTLR S\STLM SLT cursor_sharing ~ FORtL | SIMILAR | LXAtT}
ALTLR SLSSION SLT cursor_sharing ~ FORtL | SIMILAR | LXAtT}
Dynamic views
The ollowing our dynamic iews show inormation about bind ariables.
GV$SQL_BIND_MLTADATA
V$SQL_BIND_MLTADATA
GV$SQL_BIND_DATA
V$SQL_BIND_DATA.
These iews will also contain inormation about internal bind ariables. Internal
bind ariables can be distinguished rom user bind ariables, based on the alue o
the column SlARLD_FLAG2 in |GV$SQL_BIND_DATA, by looking at lag
alue 256.
To see only the rows corresponding to internal binds, a user can issue the
ollowing statement.
IIIC7 FROM 1`QI_I`D_D.7. !HIRI
I7.`D}H.RID_FI.C2, 2) ~ 2
Key benefits and tradeoffs
tonsider an application not using bind ariables. Such an application will issue
similar statements repeatedly, and most such executions will incur a hard parse.
A typical application not using binds can be expected to hae all categories o
statements. optimally shareable, suboptimally shareable and nonshareable. For
optimally shareable statements, sharing cursors is clearly an improement, non
shareable statements cannot share the same cursor.
There is no simple answer or suboptimally shareable statements. sharing cursors
s. getting the optimal plan represents a tradeo that needs to be decided by
weighing the acuteness o the hard parsing oerhead on the system s. the
deterioration that can be caused by orcing such statements to use the same plan.
Thus, the right answer will ary depending on the system load, application
characteristics, resource constraints, etc. That`s the reason Oracle leaes this
Boost SQL Perormance with cursor_sharing Page 9
decision up to the user, by exposing two dierent alues or cursor_sharing.
SIMILAR and FORtL. SIMILAR is a more conseratie choice, which causes
only optimally shareable statements to share cursors. Vith FORtL, both optimally
shareable and suboptimally shareable statements are orced to share cursors, and
the outcome is less predictable, since cursors may be shared but execution plans
may also deteriorate. lence, using FORtL makes sense in situations where
perormance is signiicantly aected due to hard parsing, and there is a ery high
percentage o suboptimally shareable statements. Another way to think about this
is. it is better to try SIMILAR beore resorting to FORtL.
Vhen similar statements share cursors as a result o cursor_sharing, hard parses
get conerted to sot parses. Note that these sot parses are a little more expensie
than a sot parse or an application already using bind ariables, due to the
additional cost o determining the similarity o the statement done internally by
replacing literals with bind ariables,. loweer, the net saings in tPU, memory
and latch contention will still be considerable.
Note that with cursor_sharing, Oracle still searches or an exact match irst. Only
when a cursor with exactly the same statement text is not ound, Oracle searches
or a cursor with a similar statement text. This is done to ensure that when the
same SQL text is being issued with no hard coded literals, there is no impact on
perormance.
Since replacement o literals is done beore looking or a cursor, other Oracle
optimizations like session_cached_cursors, and cursor_space_or_time can be
adantageously combined with cursor_sharing. For example, with both
cursor_sharing and session_cached_cursors set to a reasonable alue, a similar
statement will be able to use a cached open cursor, ater literals are replaced with
internal bind ariables.
A summary o the key beneits ollows.
No application change is needed.
There is no negatie impact on those statements, that already use bind
ariables.
Vith SIMILAR, cursors are shared more oten without impacting
execution plans.
All similar statements can be orced to share cursors with FORtL, as a
inal resort.
Caveats
Mixed statements
Mixed statements are statements that hae both bind ariables and hard coded
literals. For example.
I`IR7 I`7O 7 1.IUI}, `atpba`, :`)
Boost SQL Perormance with cursor_sharing Page 10
Similar statements that are mixed don`t share cursors through cursor_sharing, i
they are issued by a client using Oracle OtI, they share cursors with later
ersions starting with Oracle8 OtI,. In particular, this also applies to SQL issued
rom PL,SQL stored procedures in the serer, since PL,SQL in the serer uses an
older client interace.
Static SQL through PL/SQL
Cursor_sharing does not hae any eect on static embedded, SQL in PL,SQL.
Stored outlines
Any stored outlines created without cursor_sharing set to FORtL or SIMILAR,
don`t get picked up when cursor_sharing is set to FORtL or SIMILAR,. That`s
because stored outlines are indexed by the SQL text, and the current
implementation o cursor_sharing modiies the statement text. To use stored
outlines with cursor_sharing, they must be recreated using the
create_stored_outlines parameter and NOT using the create outline statement,.
Overhead
There is an oerhead inoled with FORtL or SIMILAR, which consists o
searching or a cursor built or a similar statement. As mentioned earlier, this
comprises o.
searching or a cursor with the original statement text
replacing literals with internal bind ariables, and searching based on the new
text
This oerhead will not matter when cursor_sharing works, since a large
percentage o hard parses will be replaced by sot parses, which are slightly more
expensie. loweer, when there isn`t a signiicant increase in cursor sharing, these
oerheads can negatiely impact perormance. There are three scenarios when this
can happen.
a. an application not using binds, issuing the same statements, and not haing
any similar statements
This can happen i an application always executes the same statements with
the same literals hard coded in them. Such an application does sot parses by
deault, and setting cursor_sharing to FORtL or SIMILAR, will make the
sot parses more expensie.
There is a trick that can be used in the case o such an application.
cursor_sharing can be set to FORtL or SIMILAR, ater the shared pool is
warmed up, i.e. ater all the statements that hae the same literals are already
compiled. That way, Oracle will always ind cursors or those statements
right away, aoiding the extra oerhead.
Boost SQL Perormance with cursor_sharing Page 11
This can be particularly useul, i there are some statements in an application
that always use the same literals, and others that keep changing literals.
b. an application issuing structurally dierent statements, and thus not haing
any similar statements
Such an application does hard parses by deault, and setting cursor_sharing
to FORtL or SIMILAR, will make the hard parses slightly more expensie.
c. an application not using binds, with most o the similar statements being
suboptimally shareable, using cursor_sharing set to SIMILAR
Such an application does hard parses by deault, and mostly sot parses with
cursor_sharing set to FORtL. Setting cursor_sharing to SIMILAR, will
make the hard parses slightly more expensie.
Using FORCE
Using FORtL can potentially cause a ery bad execution plan to be used. The
dierence between a good plan and a bad plan can be crucial in some situations,
e.g. a DSS enironment. lence, Oracle does not recommend using FORtL is
such scenarios.
When should you use cursor_sharing?
This section makes some recommendations on using cursor_sharing.
Using cursor_sharing=SIMILAR
As mentioned earlier, cursor_sharing does not hurt the perormance o
applications written using bind ariables. Setting cursor_sharing to SIMILAR
improes perormance o applications not using bind ariables, in most cases two
exceptions mentioned in the preious section,. lence, cursor_sharing can be set
to SIMILAR with minimal risk, in case o perormance problems with applications
that don`t use bind ariables eerywhere. Parts o the application that use bind
ariables continue to share cursors, and those parts that issue statements with hard
coded literals beneit rom some cursor sharing.
Vhether cursor_sharing~SIMILAR will improe perormance depends on the
answers to the ollowing questions.
Is perormance bad due to a ery high number o hard parses
This can be inerred by monitoring seeral metrics like the aerage number
o hard parses, the number o parses,number o executions, aerage
response times, wait eents or sessions, etc.
Are there lots o similar statements in the shared pool, with hard coded
literals
This can be checked through dynamic iews like $sql or $sqlarea.
Boost SQL Perormance with cursor_sharing Page 12
I the answer to both the aboe questions is positie, then it is ery likely that
cursor_sharing~SIMILAR will improe perormance.
Using cursor_sharing=FORCE
Using cursor_sharing~FORtL can be considered in the ollowing cases.
The percentage o suboptimally shareable statements is ery high, so that
SIMILAR isn`t useul enough.
There is no easy way to ind the percentage o suboptimally shareable
statements, short o examining all the statements. The only other way o
determining this might be to try setting cursor_sharing to SIMILAR, i hard
parsing problems due to similar statements not sharing cursors persist, then
there are many suboptimally shareable statements, and FORtL is the only
solution.
The application has hard coded literals, and there is little deterioration in
execution time by orcing similar statements to use the same cursor.
Again, this is not easy to tell. Vhen an application uses bind ariables, it
implicitly makes this assumption, to some extent such an application
ensures that the plan works reasonably well or all alues o bind ariables
by structuring the statement in certain ways, using optimizer hints, creating
the right indexes, etc. There is some likelihood o the reerse working, iz.
or an application not using binds, using the rulebased optimizer, with
indexes on most o the interesting columns, orcing similar statements to
share the same cursor may produce reasonable execution times.
Neertheless, this is a risky approach that may remoe the hard parsing
bottleneck, and introduce a new problem o tuning SQL.
Thus, it is useul to think o FORtL as a last resort, when using SIMILAR doesn`t
help.
When should you not use cursor_sharing?
There are three scenarios, mentioned earlier in "Caveats",, when using
cursor_sharing can hurt. These are cases where there aren`t any similar
statements that can share cursors with a certain alue o cursor_sharing, and
using it only adds to the parsing oerhead.
The other thing to keep in mind is the ollowing. cursor_sharing proides a
solution or the DBA aced with an application using literals. It is not a substitute,
howeer, or writing applications using bind ariables, which also allows exploiting
other optimizations proided by Oracle. For example, an application can keep
requently executed statements parsed in some open cursors, and only issue
executes on them, as needed. Such optimizations are based on deeper application
knowledge, and can`t be matched by using cursor_sharing.
Boost SQL Perormance with cursor_sharing Page 13
CONCLUSION
The use o cursor_sharing can sole perormance problems caused by hard
parsing, in case o applications not using bind ariables eerywhere. The parameter
should be set judiciously, based on application and database characteristics and
system resources.
APPENDIX: SOME PERFORMANCE MEASUREMENTS
This section describes an experiment done with Oracle8i Release 2, to alidate
cursor_sharing.
Description
The purpose o this experiment was to do a basic alidation. The maximum
throughput o the serer was measured by repeatedly issuing a single statement by
a ew clients order o 100s,. The experiment was done 3 times, with the ollowing
characteristics.
1. using only bind ariables
The purpose was twoold. to establish a baseline, and to ensure that using
cursor_sharing did not impact the perormance or such a statement.
2. using only literals, with each iteration haing a dierent literal
This scenario issued similar statements, and was expected to beneit the
most by cursor_sharing.
3. using literals with the same literal with each iteration.
This scenario wasn`t expected to beneit rom cursor_sharing, on the
contrary, it was expected to deteriorate. The reason or testing it out was to
measure the oerhead o cursor_sharing on a sot parse.
Only the parse throughput number o parses per second, was measured in each
case.
Results
The results are shown below.
7yp
cvror_barivg~I`.C7 cvror_barivg~FORCI
Binds only 2650 2650
Similar statements 860 2500
1 statement with literals 3300 2600
Oracle8.1.7 Parse Throughput numhers with cursor_sharing (parses/sec)
Boost SQL Performance with cursor_sharing
July 2001
Author: Sanjay Kaluskar
Contributing Authors: Brajesh Goyal, Namit Jain
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracle.com
Oracle Corporation provides the software
that powers the internet.
Oracle is a registered trademark of Oracle Corporation. Various
product and service names referenced herein may be trademarks
of Oracle Corporation. All other product and service names
mentioned may be trademarks of their respective owners.
Copyright 2000 Oracle Corporation
All rights reserved.