SOFT PARSE Vs HARD PARSE.pdf

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 Let’s 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 SHARED SQL AREA and PRIVATE SQL AREA

Pool . It includes

.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 , doesn’t 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 can’t 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, they’ll 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

1bf26hh7fsa46 1bf26hh7fsa46

PLAN_HASH_VALUE

2211052296 2211052296

CHILD_AD

2D6DFD74 2D4E0494

ADDRESS

2D4C4A0C 2D4C4A0C

PARSING_SCHE

ROSE 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 statement’s 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 Oracle’s 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; / 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