SOFT PARSE Vs HARD PARSE | WHY CURSORS

Overview of SQL Processing :

Oracle Database Processes

In this article , we will discuss specifically General stages of SQL processing

Parsing , Optimization, row source generation , and execution.

FIG

FIG: Stages of SQL Processing

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

 SOFT PARSE Vs HARD PARSE | WHY CURSORS

PARSING IN ORACLE:

The first stage of SQL IS PARSING.

When user submit an SQL statements for processing , an Oracle SQL

statements must be PARSED at the first time that they execute. In
oracle Parsing involves following checks

During the parse call the database performs ,

SYNTAX CHECK SEMANTIC CHECK SHARED POOL CHECK

SYNTAX CHECK:

Does it follow all of the rules for SQL ?

Is the SQL statement a valid one (syntactically correct) ?
i.e. Parsing the SYNTAX to check for misspelled SQL keywords.

Ex : Statement fails because the keyword FROM is misspelled ,

SQL> SELECT * FORM emp;

SELECT * FORM emp

*
ERROR at line 1:
ORA-00923: FROM keyword not found where expected

SEMANTIC CHECK:

Does the object exist ?

Are the columns in the SQL part of the table ?
Does the user have required privileges ?
Are there ambiguities in the statement ?

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

 SOFT PARSE Vs HARD PARSE | WHY CURSORS

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

If there are two tables t1 and t2 and both have a column x , the
query "select X from T1, T2 here the query doesn't know
which table to get x from..
ROSE> select x from t1 , t2 ;
select x from t1 , t2
*
ERROR at line 1:
ORA-00918: column ambiguously defined

A Syntactically correct statement can fail a Semantic check,

ROSE> select x from t1t2 ;

select x from t1t2
*
ERROR at line 1:
ORA-00942: table or view does not exist
because there is no object in the name of t1t2.

Here , Oracle verifies referenced table and column names from the
dictionary and checks to see if the user is authorized to see the data.

POINTS TO NOTE:

A Syntax check to check the validity of the statement and a

Semantic check to ensure that the statement can execute properly.

SHARED POOL -

Oracle keeps SQL statements, packages, information on the objects and many
other things in a memory area named shared pool The information created
in memory for a session can be useful to another one Lets see.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

 SOFT PARSE Vs HARD PARSE | WHY CURSORS

Shared Pool controls execution of SQL statements .

Shared Pool contains 1) Library Cache , 2) Dictionary Cache.

LIBRARY CACHE is very important Part of shared Pool . It includes

SHARED SQL AREA and PRIVATE SQL AREA .In oracle database each
statement is associated with a shared area and a private area.

LIBRARY CACHE holds the parsed SQL statement and execution plans

and parsed PLSQL codes. DICTIONARY CACHE holds the information

about user privileges, tables and column definitions, passwords etc.
These two memory components are included in SHARED POOL.

SHARED POOL CHECK:

During the parse , Oracle database uses a Hashing Algorithm to

generate a HASH VALUE for every SQL statement. This hash value is
checked in the shared pool. If any existing (already parsed statement)
has the same hash value then It can be reused. The SQL
statement Hash value is DISTINCT.

When a user submits a SQL statement (Oracle allocates memory from

shared pool , If required , oracle may deallocate memory from previous
statements) then the database searches the SHARED - SQL AREA to see
if an existing parsed statement has the same hash value.

A SQL statement can have multiple plans in the shared pool. Each plan has a
different hash value. If the same SQL_ ID has multiple plan hash values, then
the database knows that multiple plans exist for this SQL ID.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

 SOFT PARSE Vs HARD PARSE | WHY CURSORS

SHARED SQL AREA

An area in the shared pool that contains the parse tree and execution
plan for a SQL statement. Only one shared SQL area exists for a unique
SQL statement.

HARD PARSE Vs SOFT PARSE

HARD PARSE

Loading into Shared Pool - The SQL source code is loaded into
RAM for parsing. (the "hard" parse 1st step).

If a SQL statement cannot be reused or (If it is very first time) then

the SQL statement is being loaded in the library cache.
*****************************************

When a statement is aged out of the SHARED POOL (because the

shared pool is limited in size), when it is reloaded again, this operation is
HARD PARSE. So size of t he shared pool can also affect the amount of

parse calls.

When a SQL statement is executed, and the SQL statement is either

not in the shared pool, or it is in the shared pool but it cannot be
shared. It is a Library cache miss.
The database always perform a Hard - Parse of DDL.

POINTS TO NOTE:

During the is HARD PARSE. the database accesses the library cache and
data dictionary cache numerous times to check the data dictionary.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

 SOFT PARSE Vs HARD PARSE | WHY CURSORS

SOFT PARSE

If the submitted SQL statement is SAME AS ( REUSABLE SQL STAT

i.e. existing parsed code in shared pool) already processed by some
other session then the oracle databases reuses the existing code. It
can be shared (Library cache hit). Here always performs syntax and
semantic checks.

Identical Statements

When a new statement is fired, a hash value is generated for the text
string. Oracle checks if this new hash value matches with any existing
hash value in the shared pool.

II) Next , the text string of the new statement is compared with the
hash value matching statements. Here oracle compares the text of
two statements to conclude that the statements are identical. Oracle
matches each and every character, case and spacing.

III) If match is found the objects referred in the new statement are
compared with the matching statement objects.

If tables of the same name belonging to different schema Ex: user x

and user y (both having emp table) ( read private sql area topic )

PRIVATE SQL AREA

Oracle server distinguishes when two users are executing same

statement. To manage this every statement has its own private area
which contains a copy of statement and information related to user.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

 SOFT PARSE Vs HARD PARSE | WHY CURSORS

If a match is found then , Oracle re-uses the existing parse (soft

parse). If a match is not found, Oracle goes through the process of
parsing the statement and putting it in the shared pool (hard).

The bind variable types of the new statement should be of same type
as the identified matching statement. .

A SQL statement that must be replaced with a valid value or value

address for the statement to execute successfully. Using BIND
VARIABLES , we can write a SQL statement that accepts inputs or
parameters at run time. We will discuss seperatly.

All this takes place in a fraction of a second, even less, without

the user knowing what is happening to the statement that was
fired. This is parsing .

Is this Identical Statements ?

Identical - A statement is identical to another statement , if there

is absolutely no difference between the letters.

USER is "SCOTT"
SQL> select ename from emp;
SQL> select ENAME from emp;

These are not identical but both statement clearly do same

output. Even if it provides same output but statements will have
different HASH VALUES Lets see following screen shot.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

 SOFT PARSE Vs HARD PARSE | WHY CURSORS

Different HASH VALUE for SAME SQL STATEMENT

POINTS TO NOTE :

As I said , When a SQL statement is executed, If it is in the shared

pool but it cannot be shared. It is a " Library Cache Miss .

HR> select * From user1.emp ;

U1> select * From user1.emp;

Even two statements are identical , doesnt shareable. - Why ?

An IDENTICAL SQL STATEMENT was found in the SHARED POOL but it

could n't be used for whatever reason so a child was created.
We can find out why the first statement could not be used by looking
(v$view ) v$sql_shared_cursor.

http://docs.oracle.com/cd/E11882_01/server.112/e25513/dynviews_3059.htm#sthref3628

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

 SOFT PARSE Vs HARD PARSE | WHY CURSORS

V$SQL_SHARED_CURSOR

V$SQL_SHARED_CURSOR bunch of flags that indicate the reasons. Why

a particular child cursor is not shared with existing child cursors. Each
column identifies a specific reason why the cursor cannot be shared ..

CURSORS

A CURSOR is just a handle to execute DML statement .

A cursor is a bunch of Information stored in memory about a SQL statement.
i.e. A cursor is a memory area in library cache allocated to a SQL statement
which stores various info about the SQL statement like its text, execution plan,
statistics etc. Each SQL statement has

One Parent cursor

One or more child cursors
Each parent requires atleast one child cursors.

When new SQL arrives ,the database tries to find a suitable child cursor
on the library cache. If there is no parent cursor, then HARD PARSE.

If there is a parent cursor, but it's existing children cant be reused by

this call (e.g. because of different size of bind variables, or because of
different optimizer settings, or because of different NLS setting etc.),
there will be HARD PARSE.

If existing child cursors can be reused by this call, there will be a soft
parse.There are bunch of reasons why executions of the same SQL
statement may or may not reuse existing child cursors. Check them in
v$SQL_SHARED_CURSOR. * Why not being shared ?

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

 SOFT PARSE Vs HARD PARSE | WHY CURSORS

PARENT CURSOR Vs CHILD CURSORS

PARENT CURSOR

Very basic information every SQL statement in library cache has a parent
cursor. It has a handle which is used to search hash value in library cache. The
parent cursor contains the SQL statement text only, but no execution plans.

A parent cursor have SQL_ID and the text of the query (same query_text
will always give the same SQL_ID). It stores the sql text of the cursor. When
two statements are identical textually, theyll share the same parent Cursor.

CHILD CURSOR

Child cursors also called Versions.

Execution plans are found in each child cursors.
The child cursor is really about the specific execution plan for a statement and
the various settings and parameters that caused that plan to be generated.

Let us Consider a case : Simple Example

A SQL statement was executed first time, then it would get a parent and
child cursor. If the same sql statement was executed again (with no
change to the body of SQL keeping the same hash_value ), with a different
non-shareable attributes, then a new child cursor will be added to this
parent cursor. Here , we can see, additionally child cursors associated with
a parent cursor.

Non-shareable attributed includes : such as different optimizer_mode,

different session parameters etc.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

 SOFT PARSE Vs HARD PARSE | WHY CURSORS

CHILD CURSORS from ask Tom

Consider two (2) different users (user HR , user ROSE) are issued SQL
statements. (It looks very Identical) . There will be two child cursors in
v$sql view. One for user HR and another for user ROSE ;
Even they 'll look identical but they are in fact different.

POINTS TO NOTE

We can see there are two cursors (the "parent" 0 and the child "1")
first child cursor is numbered 0 (the parent) , then 1 (first child) , then
2 and so on. Now we can check V$SQL_SHARED_CURSOR

AUTH_CHECK_MISMATCH :

Authorization/translation check failed for the existing child cursor.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

 SOFT PARSE Vs HARD PARSE | WHY CURSORS

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

HR>select CHILD_NUMBER from v$sql where SQL_ID='1bf26hh7fsa46';

CHILD_NUMBER

0
1
HR> select sql_id , auth_check_mismatch from v$sql_shared_cursor
where sql_id = '&SQLID' ;

Enter value for sqlid: 1bf26hh7fsa46

SQL_ID A

1bf26hh7fsa46 N
1bf26hh7fsa46 Y

The reason is an auth_check_mismatch, they were different schemas

seeing different objects.

Parent cursor Vs child cursor ( text file )

Parent cursor Vs Child cursor (parsing).txt

WOULD SQL_ID BE SAME ?

Different schemas are accessing their own objects. Both object

names are same but data in them differs. Both queries referring
to its own objects. will SQ_ID being same ? Let us check.

If both queries are same - character for character - YES

If both queries are any one character - NO.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

 SOFT PARSE Vs HARD PARSE | WHY CURSORS

Dfferent schemas are : ROSE , HR

SQL statements are : select * from tab1 where no=1;

Using following query , we can check both SQL statement details

SQL>select sql_id , plan_hash_value, child_number, sql_text ,address,

child_address , parsing_schema_name , from v$sql
where sql_text= text of the query ;

SQL_ID PLAN_HASH_VALUE CHILD_AD ADDRESS PARSING_SCHE

1bf26hh7fsa46 2211052296 2D6DFD74 2D4C4A0C ROSE

1bf26hh7fsa46 2211052296 2D4E0494 2D4C4A0C HR

Even (SQL_ID , PLAN_HASH_VALUE , SQL_TEXT) are same for SQL

statements , oracle differentiate them because both SQL statements
were issued by different users.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

 SOFT PARSE Vs HARD PARSE | WHY CURSORS

If (SQL_ID , PLAN_HASH_VALUE) is different , it is hard parse

Well, Any new entry that shows up in v$sql because of a hard parse.
If these values are same for both statements - Is this Soft Parse ?
No , absolutely not. Confused ? See below example .

How to determine Given is Soft Parse or Hard Parse

SQL> Select * from emp;

When giving the query , we can See the new sql_id has been generated in
V$sql, and parse_calls is 1. This is Hard Parse.
Again I am executing the same query .

SQL> Select * from emp;

Now we can See the same sql_id in V$sql, and parse_calls is 2.
This is Soft Parse.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

 SOFT PARSE Vs HARD PARSE | WHY CURSORS

POINTS TO REMEMBER

All statements , DDL/DML are parsed whenever they are executed.

The only key fact is that whether it was a Soft Parse (statement is
already used and available in memory) or a Hard Parse (all parsing
steps to be carried out) .

Oracle searches the shared pool but cannot find the same SQL statement
there. Oracle has generate SQL plan. This is called as HARD PARSE.

Oracle searches the shared pool and finds the same SQL statement there.
However, Oracle needs to test if it can be reused.

If Oracle cannot reuse, Oracle will define a child cursor, optimize and
generate SQL plan. This is called as CURSOR AUTHENTICATION.

Oracle searches the shared pool and finds the same SQL statement there.
Oracle simply reuse SQL plan and there is no optimization. This is called as
SOFT PARSE.

Oracle uses the SESSION CURSOR CACHE or PL/SQL CURSOR CACHE as

a shortcut to find a SQL statements location in the shared pool because
eliminating need to search SHARED POOL. There is no parsing involved.

A HARD PARSE is worse than a SOFT PARSE because a hard parse

is SQL statement must be re-loaded into the Shared pool.

Once loaded completely re-checked for SYNTAX and SEMANTICS and

an executable generated. A HARD PARSE is expensive in terms of CPU
used and number of shared pool latch and library cache latch.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

 SOFT PARSE Vs HARD PARSE | WHY CURSORS

In general, a soft parse is preferable to a hard parse because the

database skips the optimization and row source generation steps,
proceeding straight to execution.

The purpose of a parse call is to load the SQL statement into Oracles
memory (shared pool), optimize it and generate SQL plan for execution.
Parse call is different from parsing.

SQL Stats provides three variables to help us understand the impact of

parse calls. ( loads , Invalidation , version count').

Parse once Execute many is important in Performance Tuning.

Parsing and sharing of cursors ( text file attached)

Parsing and Sharing of Cursors.txt

BIND VARIABLES

How can i avoid un necessary Parsing ?

Use bind variables.

If our application executes the same (or similar) SQL statements multiple
times, we can try to avoid unnecessary parsing. This will improve the
overall performance of our applications.

SQL> SELECT * FROM CUSTOMER WHERE CUST_NBR = 121;

while another customer service representative will be executing:

SQL> SELECT * FROM CUSTOMER WHERE CUST_NBR = 328;

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

 SOFT PARSE Vs HARD PARSE | WHY CURSORS

These two statements are similar, but not "identical"the customer ID

numbers are different, therefore Oracle has to parse twice. Already we
have seen many examples. (please check my above examples from this
doc) especially SQL_ID for text of the SQL statements.

Because the only difference between these statements is the value used
for the customer number, this application could be rewritten to use bind
variables. See below example, now SQL statement in question ;

SQL> SELECT * FROM CUSTOMER WHERE CUST_NBR = :X;

Here oracle no needs to parse this statement twice. The actual customer
numbers would be supplied after parsing for each execution of the
statement. So, multiple, concurrently executing programs could share the
same copy of this SQL statement while at the same time supplying
different customer number values.

If a sql statement is being reused (uses proper bind variables), we can see
its executions increasing.

If bind variables are not used, then there is hard

parsing of all SQL statements. This has a severe
impact on performance, and it is Non-Scalable.

RS>DECLARE

v_value number;

v_dispaly varchar2(15);

BEGIN

v_value :=100000;

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

 SOFT PARSE Vs HARD PARSE | WHY CURSORS

select name into v_dispaly from tab1 where no = v_value;

DBMS_OUTPUT.PUT_LINE(v_dispaly);

v_value :=200000;

select name into v_dispaly from tab1 where no = v_value;

DBMS_OUTPUT.PUT_LINE(v_dispaly);

v_value :=250000;

select name into v_dispaly from tab1 where no = v_value;

DBMS_OUTPUT.PUT_LINE(v_dispaly);

END;

<<OUTPUT>>

PL/SQL procedure successfully completed.

In this program, there is no bind variable. Optimizer generated an

execution plan with bind variable to allow soft parsing since we did not
hard coded the values in WHERE condition. Total three SELECT statements
are available with different values. Optimizer has used the same execution
plan for all the three statements.

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu