LITERALS Vs BIND VARIABLES WITH CURSOR_SHARING.docx

8/10/2019 LITERALS Vs BIND VARIABLES WITH CURSOR_SHARING.docx

1/16

LITERALS , SUB STITUTION VARIABLES AND BIND VARIABLES

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

0

VARIBLE

Very simply , a variable is a programmer defined name.

Variables are used to hold data for Oracle.

Variables may be any SQL data type

Each variable declaration is must be terminated by a semicolon;

DECLARING SIMPLE VARIABLE

VARIABLE_NAME DATATYPE;

val1 number(6);

we can assign values to variables using assignment operator :=

VARIABLE_NAME := value;

val1 := 40; or

val1 number := 40

SIMPLE PL/SQL

SQL>DECLARE

v_cnt NUMBER; -- Define a number variable

BEGIN

v_cnt := 0;

WHILE v_cnt < 10 LOOP

v_cnt := v_cnt + 1;

END LOOP;

END ;

/


2/16



LITERALS

Literals are values , Oracle points a FIXED DATA VALUE.

Character Literals are ford,rose,100.

Numeric Literals are is 5001 , 6000.

Character literals are enclosed in single Quotationmarks

Example for NUMERIC LITERALS

SQL> DECLARE

v_var1 NUMBER(2) := 123;

v_var2 NUMBER(3) := 123;

v_var3 NUMBER(5,3) := 123456.123;

BEGIN

DBMS_OUTPUT.PUT_LINE('v_var1: '||v_var1);



END;

/

NUMERIC LITERAL and STRING LITERAL

SQL> DECLARE

v_var1 VARCHAR2(20);

v_var2 VARCHAR2(6);

v_var3 NUMBER(5,3);


3/16



***********************************************

BEGIN

v_var1 := 'string literal';

v_var2 := '12.345';

v_var3 := 12.345;




END;

/

v_var1: string literal

v_var1: 12.345

v_var1: 12.345

PL/SQL procedure successfully completed.

'string literal' and '12.345', are string literals because they are enclosed in

single quotes. The third value, 12.345, is a numeric literal.

SUB STITUTION VARIABLES in SQL* Plus

Substitute variable is prefixed with (&) or (&&) i.e., there are

two (2) types of SUB STITUTION VARIABLES( & and && )...

SQL*Plus finds a substitution variable define by using & ampersand.

It prompts the user to enter a value for that variable then it tries

to replace it with the value. Substitution variable may declared with

"define". they have no data type.


4/16



**********************

Simple Example

Declare

SQL>define var1 = sam

SQL>Select '&var1' from dual;

RESU

var1

Difference between & and &&

"&" is used to create a temporary substitution variable that will

prompt a value every time it is referenced.

"&&" is used to create a permanent substitution variable. Once

entered a value (defined the variable) its value will used every time

the variable is referenced. Lets see.


5/16



*************************************************

The "&&"will actually define the variable similarly to what the DEFINE

command or OLD_VALUE/NEW_VALUE clauses of a COLUMN

statement would have done.

POINTS TO NOTE :

&& substitution variable will reuse the variable value without

prompting the user everytime.

When we run a script or SQL that contains "&" symbols, we can

insert some data into database, what actually happen is SQL*Plus

will prompt the user for a value.

Here , we can use ( SET DEFINE OFF ) command to stop SQL*Plus

perform any variable substitution.


6/16



SET DEFINE ON Vs SET DEFINE OFF

SET DEFINE ON command TURNS ON for variable substitution.

There are three (3) combinations of 'SET DEFINE' , they are

: set define ON. set define OFF. set define x.

SET DEFINE ON VS SET DEFINE OFF

The SET DEFINE statement is used to specify the value of the nonalphanumeric character used to prefix substitution variables. The

default value is the apersand (&).

HR> SET DEFINE ON;

HR>SELECT '&HELLO' FROM DUAL;

Enter value for hello: THIS IS ORACLE

RESULT

THIS IS ORACLE

HR> SET DEFINE OFF;

HR>SELECT '&HELLO' RESULT FROM DUAL;

RESULT

&HELLO

If SET DEFINE ON, then it will ask the variable value. .

If SET DEFINE OFF, then it will not ask the variable value.

set define x :set define x specifies the prefix character for

substitution variables and default is . ampersand (&).


7/16



POINTS TO NOTE

What I say , as far as the database server is concerned, literals and

substitution variables are the same thing. Lets us check .

SQ>select * from dual where dummy ='&var';

SQL>select * from dual where dummy = 'X';

Both statements will be parsed separately (hard pase occurs) so I

am saying literals and substitution variables are the same thing.

BIND VARIABLES

BIND VARIABLES are differ from literals and substitution variables.

because useage of bind variables to increase query performance.

Bind variables ensures parsed representations of SQL queries are

reused by the database.

Creating bind Variables

HR>VARIABLE ret_val NUMBER

HR> BEGIN

:ret_val := 4;

END;

/


HR>PRINT ret_val;

RET_VAL

4


8/16



*******************************************POINTS TO NOTE

LITERALS are same as constants.

Variable used with : (colon) is a BIND VARIABLE not true always.

When SQL* Plus sees substitution variable it replaces particular

value , it will create many hard parses , affecting performance too.

Bind variables are used in SQL and PL/SQLstatements for holding

data. They are commonly used in SQL statements to optimize

statement performance. A statement with a BIND VARIABLEmay

be re-executed multiple times without needing to be re-parsed.

BIND VARIABLES Improves the performance because don't replace

variables place holder with the value. It just binds them.

When using bind variables database server binds values with the

variable place holder but submitted SQL query text is being same.

Examples for USING BIND VARIABLES

Hard Parses are really bad. Avoiding HARD PARSES can reduce

overall run time of given SQL statement more than once. Oracle

considers identical SQL statements to be the same, hard parses will

be performed for both of these following statements.

SQL> select * From tab1 where eid=12345;

SQL> select * From tab1 where eid=54321;

Above two SQL statements above are not identical This will result in two

different cursors being stored in the Library Cache.


9/16



************************************

We can avoid this problem through the use of bind variables used

within your SQL and PL/SQL code.

Bind variable references should be prefixed with a colon. To use a bind

variable, in SQL statement or PL/SQL block use a colon followed by a

variable name to indicate a bind variable is being used.

So we can use bind variables for input variables in any DELETE,

INSERT, SELECT, OR UPDATEstatement, or PL/SQL block.

HR> variable v_value number

HR>declare

v_display varchar2(15);

BEGIN

:v_value:=1;

select name into v_display from tab1 where no=:v_value;

dbms_output.put_line(v_display);

END;

/

sam


PL/SQL can be executed many times with different values for :v_value, and

hard parsed once. This approach not only performs better but also is a much

more scalable way of writing SQL and PL/SQL. Multiple concurrent statements

will be able to be executed.


10/16



BIND VARIABLES SMALL EXAMPLE PROGRAM

Parsing steps and the use of bind variables are the most important

things to understand for developers variable .

HR>select * from tab1 where no=1 or no=2;

NO NAME EMAIL CITY

1 sony [email protected] new jersy

2 ford [email protected] new jersy

HR> variable b1 number

HR> variable b2 varchar2(30)

HR> exec :b1:=2;


HR>BEGIN

2 select name into :b2 from tab1 where no=:b1;

3 END;

4 /


HR>print :b2;

B2

ford

POINTS TO NOTE :

Variable and exec are SQL Plus commands and are not part of the pl/sql

language. We can't use them as part of PL/SQL.


11/16



Simple Program using BIND VARIABLE with FUNCTION

HR> create or replace function test_fun

return number is

begin

return 1;

end;

/

Function created.

HR>var n number;

HR>exec :n:= test_fun;


HR>print n;

N

1

Using BIND VARIABLES to check PARSING

HR>ALTER SYSTEM FLUSH SHARED_POOL:

System altered.

SET VERIFY

SET VERIFY only has an effect on substitution variables used in SQL

and PL/SQL statements: SET VERIFY command is used to control

whether SQL*Plus echoes the old and new statement text when it

substitutes a variable's value.


12/16



*******************************************

HR> SET VERIFY ON;

HR> DEFINE VAL1=100;

HR> SELECT * FROM TAB1 WHERE NO=&VAL1;

old 1: SELECT * FROM TAB1 WHERE NO=&VAL1

new 1: SELECT * FROM TAB1 WHERE NO=100

>

HR> SET VERIFY OFF;

HR> SELECT * FROM TAB1 WHERE NO=&VAL1;

>

0

CURSOR_SHARING

CURSOR_SHARING is an init.oraparameter. Oracle database uses to control

whether it will "auto-bind" a SQL statement. It allow users to change the

shared pool's default behavior when parsing and caching SQL statements.

CURSOR_SHARING determines what kind of SQL statements can share the

same cursors. CURSOR_SHARING can have one of three values ;

FORCE SIMILAR EXACT (default)

SQL > show Parameter cursor_sharing;

Oracle offers the cursor_sharing parameter starting with oracle 8i. When

CURSOR SHARING is enabled setting of parameter CURSOR_SHARING to

FORCE/ EXACT/SIMILAR. SIMILAR is only available above oracle 8i. Oracle

will replace literal values with system generated bind values.


13/16



Oracle database can take a query of the form SELECT * FROM TABLE

WHERE COL = 'literal' and replace the 'literal' with a bind value - so the

predicate will become WHERE COL = :"SYS_B_0". This permits the reuse of

the generated query plan , to better utilization of the shared pool and a

reduction of hard parses performed by the system.

CURSOR_SHARING = EXACT- ( DEFAULT )

EXACT (default) allows SQL statements must match exactly in

order to share the parse code in shared pool. When setting

cursor_sharing to exact only textually exact statements can be

shared. The query is not rewritten to use bind variables.

CURSOR_SHARING = FORCE

This setting rewrites the query. Share the plan (forcibly) of a SQL.

If the text of SQL matches (except the literal values of the SQL) in

shared pool. CURSOR_SHARING to allows similar statements to share

SQL. Two (2) SQL statements which differ only by a literal value).

CURSOR_SHARING = SIMILAR

This is very tricky one ! This setting also rewrites the query,

replacing the literals with bind variables, but can setup different

plans for different bind variable combinations. SIMILAR might reduce

the number of plans generated because multiple plans may be

generated, the setting of SIMILAR may or may not reduce the number

of actual plans to observe in the shared pool.


14/16



EXAMPLE FOR CURSOR_SHARING = EXACT

CURSOR_SHARING= EXACT: In oracle database, every unique SQL

statement will create a new entry in V$SQL , it will be hard-parsed,

and an execution plan will be created for it.

EXACT.txt

There can be hundreds or thousands of very similar queries in the

shared pool that differ only in the literals used in the SQL

statement. This implies that the application itself is not using bind

variables, and that implies that the database is forced to hard-parse

They not only consumes a lot of CPU cycles but also leads to

decreased scalability.

Because the database cannot hard-parse hundreds or thousands of

SQL statements concurrently, the application ends up waiting for the

shared pool to become available. That was the motivation behind

adding CURSOR_SHARING=FORCE .

EXAMPLE FOR CURSOR_SHARING = FORCE

CURSOR_SHARING= FORCE : In oracle database, It is generated

only one shareable query in the shared_pool Literals are replaced

with :"SYS_B_0"and made the cursor shareable by as many sessions.

FORCE.txt
http://www.scribd.com/doc/208424570/Exact?secret_password=1bl85aj6pnu0x73qqc14http://www.scribd.com/doc/208426046/Force?secret_password=2nxy3objxzdv8xoyv2lfhttp://www.scribd.com/doc/208426046/Force?secret_password=2nxy3objxzdv8xoyv2lfhttp://www.scribd.com/doc/208424570/Exact?secret_password=1bl85aj6pnu0x73qqc14


15/16



***************************************************

In general , one query plan would be reused by many sessions. This

would turn the hard parse into a soft parse. It consumes just some

resources and simultaneously increase the scalability of the system.

Settings of CURSOR_SHARING to FORCE/SIMILAR are the same

because both resulted in a single plan. So what is the difference

between these two settings ?

EXAMPLE FOR CURSOR_SHARING = SIMILAR

If CURSOR_SHARING set to SIMILAR, the optimizer would replace all

literals with :SYS_B_? This is what we see in Oracle database.

CURSOR_SHARING = SIMLAR: is a compromise between the two

extremes: cursor_sharing = exact (which doesn't change anything) and

cursor_sharing = force (which forces replacement of literals with

system-generated bind variables wherever possible).

SIMILAR causes statements that may differ in some literals, but are

otherwise identical to share a cursor, unless the literals affect either

the meaning of the statement or the degree to which the plan is

optimized.

SIMILAR.txt

In this option cursor reuse is not guaranteed, by design.

SIMILAR is no more exists in Oracle 12c. The option has been

deprecated. in oracle 11g. Oracle metalink 1169017.1
http://www.scribd.com/doc/208429789/Cursor-Sharing-Similar?secret_password=2wky72hxfiqzu98mxh7http://www.scribd.com/doc/208429789/Cursor-Sharing-Similar?secret_password=2wky72hxfiqzu98mxh7


16/16



*****************************

DIFFERENCE BETWEEN SIMILAR AND FORCE

The CURSOR SHARING parameter is for auto binding of the literals,and it does not optimize/deoptimize the plan in anyway.

FORCE option contains so many bugs like Incorrect results ,

crashing instances etc. Oracle does NOT recommend to set FORCE.

Setting the CURSOR_SHARING to FORCE may cause the optimizer to

generate unexpected execution plans because the optimizer does not

know the values of the bind variables. This may positively or negatively

impact the database performance.

CURSOR_SHARING of FORCE/SIMILAR is something that a DBA can

occasionally use to work around poorly written applications. Ideally,

either should be a temporary measure until the developers fix the

problem code. To get light CURSOR SHARING = SIMILAR/ FORCE.

There are numerous bugs associated with CURSOR_SHARING=SIMILAR.

CURSOR_SHARING=EXACT is sufficient if the application is written

correctly. Best link from ask tom.
https://blogs.oracle.com/optimizer/entry/explain_adaptive_cursor_sharing_behavior_with_cursor_sharing_similar_and_forcehttps://blogs.oracle.com/optimizer/entry/explain_adaptive_cursor_sharing_behavior_with_cursor_sharing_similar_and_forcehttps://blogs.oracle.com/optimizer/entry/explain_adaptive_cursor_sharing_behavior_with_cursor_sharing_similar_and_forcehttp://www.oracle.com/technetwork/issue-archive/2006/06-jan/o16asktom-101983.htmlhttp://www.oracle.com/technetwork/issue-archive/2006/06-jan/o16asktom-101983.htmlhttps://blogs.oracle.com/optimizer/entry/explain_adaptive_cursor_sharing_behavior_with_cursor_sharing_similar_and_force

Documents

LITERALS Vs BIND VARIABLES WITH CURSOR_SHARING.docx