sql解析过程 metarlink

PURPOSE
~~~~~~~
The document gives a overview of Parsing.

SCOPE & APPLICATION
~~~~~~~~~~~~~~~~~~~
For users requiring a general overview of how parsing works.


Introduction
============

This article show the parsing mechanism as a flow diagram.
Its main purpose is to show the difference between a 'soft' and a
'hard' parse.

It is intended to give a feel of how parsing operates to make
explanation of parsing activity easier.


SQL Parsing Flow Diagram
========================

Statement
Submitted
|
Is it in an open cursor?--------------YES----V  
|                                            | 
NO                                           |  
|                                            |
Is SESSION_CACHED_CURSORS = Value            | 
and cursor in Server Side ------------YES----V   In these 3 cases we 
Session Cursor cache?                        |   know that the cursor has
|                                            |   already been parsed, so
NO                                           |   re-parsing is
|                                            |   unnecessary.
Is HOLD_CURSOR=Y                             |
and cursor in           --------------YES----V     
Held cursor cache?                           |      
|                                            |      
NO                                           |       
|                                            |              ^
OPEN A CURSOR                                |  CLIENT SIDE |      
|                                            | -------------|
Statement is Hashed and compared             |  SERVER SIDE |
with the Hashed value in the sql area        |              V
|                                            V
Is it in sql area? --YES-(Soft Parse)--> ---------
|                                       |         |
NO                                      | EXECUTE |
|                                       |         |
PARSE STATEMENT ('Hard' Parse)---------> ---------


NOTES
=====

1. A cursor is an address on the client that points to the memory 
   location of a SQL statement on the server.
   Multiple-client cursors may point at the same address on the server.

2. Remember that 'Client' and 'Server' sides may reside on the same
   machine - in which case Client/Server is a logical distinction.

3. If a cursor is open, then the statement will be in the sql_area,
   so no parsing is necessary.

   This is why locks may remain when a client is terminated
   abnormally (such as a PC Client being turned off without
   closing open cursors).

4. SESSION_CACHED_CURSORS is the initialisation parameter that
   specifies how many cursors to hold open for a particular session.
   The open cursor request will still be sent to the server but it will
   not be executed once a matching cursor is found in the session cursor cache.

5. HOLD_CURSOR is an precompiler parameter that specifies that an
   individual cursor should be held open.

   See Page 11-3 of the Programmer's guide to the Oracle Precompilers.

6. Both the soft and hard parse register as a parse in tkprof. Hashing the
   current statement updates the parse count.

7. Soft parse avoids many of the steps taken during the parse phase for a
   particular statement. Initial syntactic and semantic checks are made and
   then the statement is hashed and compared with hashed statements in
   the SQL area. If a match is found, then existing information is used
   and relatively expensive steps (such as query optimization etc.) are avoided.

8. The 10053 event is only invoked during a hard parse.


Additional Search Words
~~~~~~~~~~~~~~~~~~~~~~~

HARD; HOLD_CURSOR; PARSE; SESSION_CACHED_CURSORS; SOFT; SQL;

Overview of SQL Statement Processing Phases

Once a statement has been submitted to the oracle engine it goes through the following phases which determine how to best approach it. The following table is a very simplified and abstract overview of the phases involved when processing a SELECT query.

PARSE	Statement matching, syntactic and semantic checks			Statement is checked against the library cache to determine if it already exists and the syntax and structure are checked.
	Query Transformation			Certain query contructs (e.g. Views, subqueries) may be transformed at this stage to open up new join and access possibilities
	RBO - plan determined using rules (Obsolete as of Oracle 10g)	CBO	Determine object costs and cardinalities	Individual objects are costed and the number of rows (cardinality) is determined.
			Cost different join orders	Join orders and methods are evaluated and the plan with the overall lowest cost is chosen
			Build structures for runtime	Run time structures are built and stored in the library cache. At execution time these structures are used to drive the query.
EXECUTE				Memory areas are allocated for bind variables, values are filled and the plan generated by the PARSE phase are executed.
FETCH				Data blocks are retrieved, unwanted rows are removed and data is sorted as necessary. Resultant rows are presented to the application.

Oracle records individual statistics for the PARSE, EXECUTE and FETCH phases which can be seen by tracing (using SQL_TRACE). For statistic recording purposes, Query Optimization is part of the PARSE phase. Reference Note:32895.1