8/8/2019 Process of Executing SQL Statements

1/4

Process of Executing SQL Statements

(See Also:Oracle Database Concepts 10g Release 2 (10.2)||Chapter

24 SQL, PL/SQL, and Java)

Understanding the Process of Executing SQL Statements

From: BURLESON

In order to be effective at tuning SQL statements, the database professionalmust have an intimate understanding of how the SQL is transformed from theoriginal source code into an executable form. At a high level, SQL processingis broken down into several steps:

1. Parsing the source code to locate any syntax errors2. Invoking the SQL optimizer to derive an execution plan3. Create and run an executable, based on the execution plan4. Fetching the results set from the database and return it to the calling

query.

Oracle has a special RAM memory region within the System Global Area(SGA) to process SQL statements. Most relational databases contain multipleareas of RAM caches:

1. RAM cache for data blocks2. RAM cache for SQL statements3. RAM for caching the data dictionary4. RAM for caching program execution code

Just as the data caches within a relational database use a most frequentlyusedalgorithm to cache data blocks that are frequently referenced, theOracle database provides a special cache called library cache to storefrequently executed SQL statements.

Every time an SQL statements enters the Oracle system, Oracle begins bylooking to see if the SQL statement has already been processed. Oracle doesthis by invoking a hashing algorithm, using the SQL statement as input, andgoes to the RAM address to see if the SQL statement has already beenparsed. If the statement has already been parsed, Oracle grabs theexecutable and immediately re-executes the program, at the same time

incrementing the executions column in the v$sql view.

In order to make effective use of the library cache, it is important for theOracle database professional to ensure that all of the SQL in the library cacheis fully reentrant. By fully reentrant, we mean that the SQL is free of literalvariables, such that the SQL can be re-executed using different bind variablesas input. For example, the following code would not be considered reentrantbecause of the embedded literal.

8/8/2019 Process of Executing SQL Statements

2/4

select * from customer where name = BURLESON;

To make this SQL reentrant, we can replace the literals within the SQLstatement with a bind variable, thereby making the SQL fully re-entrant, andre-usable:

select * from customer where name = :var1;

To facilitate this type of literal substitution, Oracle provides a tool calledcursor_sharing. Setting cursor_sharing=force automates the process ofsubstituting out literal values within SQL statements. This is very importanttool to those Oracle database administrators whose vendor applicationsgenerate dynamic SQL that contains literal values.

The best way to locate and tune Oracle SQL statements is by extracting the

SQL directly from Oracle's library cache. The v$sql and v$sql_plan views canbe used to allow the immediate extraction of SQL statements from the librarycache. Further, the v$sql_plan view can tell us valuable information aboutthe access patterns of the SQL that are currently within the library cache.

We have to note that the process speed of executing SQL statements can bevery quick, and tens of thousands of SQL statements can be executed everyminute in a busy Oracle database. Hence, we need some kind of amonitoring tool that will tell us to salient characteristics of SQL activity overfixed periods of time. We use the Oracle STATSPACK utility for this purposeand part of your reading assignments will be to understand how we can useSTATSPACK to monitor the behavior all the library cache and see the behavior

of individual SQL statements over time.

What happens when Oracle processes an SQL Statement?From:http://www.adp-gmbh.ch

An SQL statement must always be parsed. Then, it can be executedany number of times. If it is a select statement, the result-data needs befetched for each execution.

Parse

One of the goals of the parse phase is to generate a query execution

plan (QEP). Does the statement correspond to an open cursor, ie, does thestatement already exist in the library cache. If yes, the statement needs notbe parsed anymore and can directly be executed.If the cursor is not open, it might still be that it is cached in the cursor cache.If yes, the statement needs not be parsed anymore and can directly beexecuted.If not, the statement has to be verified syntactically and semantically:

http://www.adp-gmbh.ch/ora/sql/execution_plan.htmlhttp://www.adp-gmbh.ch/ora/sql/execution_plan.htmlhttp://www.adp-gmbh.ch/ora/concepts/cursors.htmlhttp://www.adp-gmbh.ch/ora/concepts/library_cache.htmlhttp://www.adp-gmbh.ch/ora/concepts/cursors.html#cached_cursorshttp://www.adp-gmbh.ch/ora/sql/execution_plan.htmlhttp://www.adp-gmbh.ch/ora/sql/execution_plan.htmlhttp://www.adp-gmbh.ch/ora/concepts/cursors.htmlhttp://www.adp-gmbh.ch/ora/concepts/library_cache.htmlhttp://www.adp-gmbh.ch/ora/concepts/cursors.html#cached_cursors

8/8/2019 Process of Executing SQL Statements

3/4

Syntax

This step checks if the syntax of the statmenet is correct. For example,a statement like select foo frm bar is syntactically not correct (frm instead offrom).

Semantic

A statement might be invalid even if the syntax is correct. For exampleselect foo from bar is invalid if there is no table or view named bar, or if thereis such a table, but without a column named foo.Also, the table might exist, but the user trying to execute the query does nothave the necessary object privileges.If the statement is syntactically and semantically correct, it is placed into thelibrary cache (which is part of the Shared Pool).

Cursor

A cursor is just a handle to a DML statement. You need a cursor toexecute any DML in Oracle - be it an insert/update/delete/select whatever.

It is just a "handle", sort of like opening a file. Think of a select statement like"open file". Once you open the file, you can read from it, once youexecute the cursor - you can read from it.

Opening the cursor

A cursor for the statement is opened. The statement is hashed andcompared with the hashed values in the sql area. If it is in the sql area, it is asoft parse, otherwise, it's a hard parse.Only in the case of a hard parse, the statement undergoes the following steps(view merging, statement transformation, optimization)

View mergingIf the query contains views, the query might be rewritten to join the

view's base tables instead of the views.

Statement Transformation

Transforms complex statements into simpler ones through subqueryunnesting or in/or transformations

Optimization

The CBO uses "gathered??" statistics to minimize the cost to executethe query. The result of the optimization is the query evaluation plan (QEP). If

bind variable peeking is used, the resulting execution plan might bedependant on the first bound bind-value.

Execute

Memory for bind variables is allocated and filled with the actual bind-values. The execution plan is executed.Oracle checks if the data it needs for the query are already in the buffercache. If not, it reads the data off the disk into the buffer cache.

http://www.adp-gmbh.ch/ora/misc/users_roles_privs.html#object_privilegeshttp://www.adp-gmbh.ch/ora/concepts/shared_pool.htmlhttp://www.adp-gmbh.ch/ora/concepts/cursors.htmlhttp://www.adp-gmbh.ch/ora/concepts/cursors.html#soft_parsehttp://www.adp-gmbh.ch/ora/concepts/cursors.html#hard_parsehttp://www.adp-gmbh.ch/ora/sql/execution_plan.htmlhttp://www.adp-gmbh.ch/ora/concepts/bind_variables.htmlhttp://www.adp-gmbh.ch/ora/concepts/bind_variables.htmlhttp://www.adp-gmbh.ch/ora/concepts/cache.htmlhttp://www.adp-gmbh.ch/ora/concepts/cache.htmlhttp://www.adp-gmbh.ch/ora/misc/users_roles_privs.html#object_privilegeshttp://www.adp-gmbh.ch/ora/concepts/shared_pool.htmlhttp://www.adp-gmbh.ch/ora/concepts/cursors.htmlhttp://www.adp-gmbh.ch/ora/concepts/cursors.html#soft_parsehttp://www.adp-gmbh.ch/ora/concepts/cursors.html#hard_parsehttp://www.adp-gmbh.ch/ora/sql/execution_plan.htmlhttp://www.adp-gmbh.ch/ora/concepts/bind_variables.htmlhttp://www.adp-gmbh.ch/ora/concepts/bind_variables.htmlhttp://www.adp-gmbh.ch/ora/concepts/cache.htmlhttp://www.adp-gmbh.ch/ora/concepts/cache.html

8/8/2019 Process of Executing SQL Statements

4/4

The record(s) that are changedare locked. No other session must be able tochange the record while they're updated. Also, before and after imagesdescribing the changes are written to the redo log buffer and the rollbacksegments. The original block receives a pointer to the rollback segment.

Then, the data is changed.

FetchData is fetched from database blocks. Rows that don't match the

predicate are removed. If needed (for example in an order by statement),the data is sorted. The data is then returned to the application.

The execution plan

The query execution plan is also stored in the library cache. EXPLAIN PLANcan be used to see how the statement is executed.

Private SQL Area

Each session that issues an SQL statement has a private SQL area associated

with this statement. The first step for Oracle when it executes an SQLstatement is to establish a run time area (within the private SQL area) for thestatement.

Tuning SQL statements

dbms_sqltune, statspack

http://www.adp-gmbh.ch/ora/concepts/session.htmlhttp://www.adp-gmbh.ch/ora/concepts/redo_log.html#log_bufferhttp://www.adp-gmbh.ch/ora/concepts/rollbacksegs.htmlhttp://www.adp-gmbh.ch/ora/concepts/rollbacksegs.htmlhttp://www.adp-gmbh.ch/ora/sql/order_by.htmlhttp://opt/scribd/conversion/tmp/explainplan.htmlhttp://www.adp-gmbh.ch/ora/concepts/private_sql_area.htmlhttp://www.adp-gmbh.ch/ora/concepts/private_sql_area.html#run_time_areahttp://www.adp-gmbh.ch/ora/concepts/private_sql_area.htmlhttp://www.adp-gmbh.ch/ora/plsql/dbms_sqltune.htmlhttp://www.adp-gmbh.ch/ora/tuning/statspack.htmlhttp://www.adp-gmbh.ch/ora/concepts/session.htmlhttp://www.adp-gmbh.ch/ora/concepts/redo_log.html#log_bufferhttp://www.adp-gmbh.ch/ora/concepts/rollbacksegs.htmlhttp://www.adp-gmbh.ch/ora/concepts/rollbacksegs.htmlhttp://www.adp-gmbh.ch/ora/sql/order_by.htmlhttp://opt/scribd/conversion/tmp/explainplan.htmlhttp://www.adp-gmbh.ch/ora/concepts/private_sql_area.htmlhttp://www.adp-gmbh.ch/ora/concepts/private_sql_area.html#run_time_areahttp://www.adp-gmbh.ch/ora/concepts/private_sql_area.htmlhttp://www.adp-gmbh.ch/ora/plsql/dbms_sqltune.htmlhttp://www.adp-gmbh.ch/ora/tuning/statspack.html