Professional Documents
Culture Documents
FIG
PARSING IN ORACLE:
SYNTAX CHECK:
SEMANTIC CHECK:
**********************************************************************
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
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:
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.
LIBRARY CACHE holds the parsed SQL statement and execution plans
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.
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
Loading into Shared Pool - The SQL source code is loaded into
RAM for parsing. (the "hard" parse 1st step).
parse calls.
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
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.
The bind variable types of the new statement should be of same type
as the identified matching statement. .
USER is "SCOTT"
SQL> select ename from emp;
SQL> select ENAME from emp;
POINTS TO NOTE :
http://docs.oracle.com/cd/E11882_01/server.112/e25513/dynviews_3059.htm#sthref3628
V$SQL_SHARED_CURSOR
a particular child cursor is not shared with existing child cursors. Each
column identifies a specific reason why the cursor cannot be shared ..
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 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
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
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.
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 :
********************************************
0
1
HR> select sql_id , auth_check_mismatch from v$sql_shared_cursor
where sql_id = '&SQLID' ;
1bf26hh7fsa46 N
1bf26hh7fsa46 Y
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 .
POINTS TO REMEMBER
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.
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.
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.
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 ;
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.
RS>DECLARE
v_value number;
v_dispaly varchar2(15);
BEGIN
v_value :=100000;
DBMS_OUTPUT.PUT_LINE(v_dispaly);
v_value :=200000;
DBMS_OUTPUT.PUT_LINE(v_dispaly);
v_value :=250000;
DBMS_OUTPUT.PUT_LINE(v_dispaly);
END;
<<OUTPUT>>