LITERALS Vs BIND VARIABLES WITH CURSOR_SHARING.docx

LITERALS , SUB STITUTION VARIABLES AND BIND VARIABLES 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 ; /

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

LITERALS , SUB STITUTION VARIABLES AND BIND VARIABLES

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 ‘Quotation marks’ 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); DBMS_OUTPUT.PUT_LINE('v_var2: '||v_var2); DBMS_OUTPUT.PUT_LINE('v_var3: '||v_var3); END; / NUMERIC LITERAL and STRING LITERAL

SQL> DECLARE v_var1 VARCHAR2(20); v_var2 VARCHAR2(6); v_var3 NUMBER(5,3);


LITERALS , SUB STITUTION VARIABLES AND BIND VARIABLES *********************************************** BEGIN v_var1 := 'string literal'; v_var2 := '12.345'; v_var3 := 12.345; DBMS_OUTPUT.PUT_LINE('v_var1: '||v_var1); DBMS_OUTPUT.PUT_LINE('v_var2: '||v_var2); DBMS_OUTPUT.PUT_LINE('v_var3: '||v_var3); 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.


LITERALS , SUB STITUTION VARIABLES AND BIND VARIABLES **********************

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.


LITERALS , SUB STITUTION VARIABLES AND BIND VARIABLES *************************************************

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.


LITERALS , SUB STITUTION VARIABLES AND BIND VARIABLES 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 non – alphanumeric 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 (&). Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

LITERALS , SUB STITUTION VARIABLES AND BIND VARIABLES 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; / PL/SQL procedure successfully completed. HR>PRINT ret_val; RET_VAL

4


LITERALS , SUB STITUTION VARIABLES AND BIND VARIABLES ******************************************* 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/SQL statements for holding data. They are commonly used in SQL statements to optimize statement performance. A statement with a BIND VARIABLE may 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. Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

LITERALS , SUB STITUTION VARIABLES AND BIND VARIABLES ************************************

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 UPDATE statement, 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 procedure successfully completed. 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. Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu


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; PL/SQL procedure successfully completed. HR>BEGIN 2 select name into :b2 from tab1 where no=:b1; 3 END; 4 / PL/SQL procedure successfully completed. 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. Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

LITERALS , SUB STITUTION VARIABLES AND BIND VARIABLES 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; PL/SQL procedure successfully completed. 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.


LITERALS , SUB STITUTION VARIABLES AND BIND VARIABLES *******************************************

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 << output >> HR> SET VERIFY OFF; HR> SELECT * FROM TAB1 WHERE NO=&VAL1; << output >> 0

CURSOR_SHARING CURSOR_SHARING is an init.ora parameter. 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. Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu


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.



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


LITERALS , SUB STITUTION VARIABLES AND BIND VARIABLES ***************************************************

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


LITERALS , SUB STITUTION VARIABLES AND BIND VARIABLES *****************************

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=EXACT

CURSOR_SHARING=SIMILAR.

is sufficient if the application is written

correctly. Best link from ask tom.


LITERALS Vs BIND VARIABLES WITH CURSOR_SHARING.docx

Recommend Documents