SOFT PARSE Vs HARD PARSE.pdf

SOFT PARSE Vs HARD PARSE | WHY CURSORS

Exploring the Oracle DBA Technology by Gunasekaran ,Thiyagu

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



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 ?



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

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.



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.



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.



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.



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.



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



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 ?



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.



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.



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

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.



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.



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.



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.



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;



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;



select name into v_dispaly from tab1 where no = v_value;

DBMS_OUTPUT.PUT_LINE(v_dispaly);

v_value :=200000;



v_value :=250000;



END;

/

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.

Documents

SOFT PARSE Vs HARD PARSE.pdf