sql 执行步骤

A、软解析

1、语法、语义、权限检查

2、运用HASH算法，得到一个HASH值，这个值可以通过V$SQLAREA.HASH_VALUE 查看

3、到shared pool 中的 library cache 中查找是否有相同的HASH值，如果存在且语句完全一致、运行环境完全一致，则无需硬解析，进行软解析（使用现有解析树+执行计划）。其他信息具体见附录。
4、带入绑定变量

5、生成ORACLE能运行的二进制代码，运行该代码并且返回结果给用户

B、硬解析

 1、语法、语义、权限检查

 2、运用hash算法，得到hash值

3、在shared pool 分配内存，使用优化器基于统计信息生成解析树、执行计划

4、带入绑定变量

5、生成oracle可以运行的二进制代码，并返回结果给用户

以上均需要先打开游标执行完成后关闭游标。

附录：软解析详细步骤:

 检查共享池中是否有相同的语句存在。假如执行的SQL语句已经在共享池中存在同样的副本，那么该SQL语句将会被软解析，也就是可以重用已解析过的语句的执行计划和优化方案，可以忽略语句解析过程中最耗费资源的步骤，这也是我们为什么一直强调避免硬解析的原因。这个步骤又可以分为两个步骤：
（1）验证SQL语句是否完全一致。在这个步骤中，Oracle将会对传递进来的SQL语句使用HASH函数运算得出HASH值，再与共享池中现有语句的HASH值进行比较看是否一一对应。现有数据库中SQL语句的HASH值我们可以通过访问v$sql、v$sqlarea、v$sqltext等数据字典中的HASH_VALUE列查询得出。如果SQL语句的HASH值一致，那么ORACLE事实上还需要对SQL语句的语义进行再次检测，以决定是否一致。那么为什么Oracle需要再次对语句文本进行检测呢？不是SQL语句的HASH值已经对应上了？事实上就算是SQL语句的HASH值已经对应上了，并不能说明这两条SQL语句就已经可以共享了。我们首先参考如下一个例子：
假如用户A有自己的一张表EMP，他要执行查询语句：select * from emp；用户B也有一张EMP表，同样要查询select * from emp；这样他们两条语句在文本上是一模一样的，他们的HASH值也会一样，但是由于涉及到查询的相关表不一样，他们事实上是无法共享的。假如这时候用户C又要查询同样一条语句，他查询的表为scott下的公有同义词，还有就是SCOTT也查询同样一张自己的表emp，情况会是如何呢？

代码:--------------------------------------------------------------------------------
SQL> connect a/a
Connected.
SQL> create table emp ( x int );

Table created.

SQL> select * from emp;

no rows selected
SQL> connect b/b
Connected.
SQL> create table emp ( x int );

Table created.

SQL> select * from emp;

no rows selected

SQL> conn scott/tiger
Connected.
SQL> select * from emp;
SQL> conn c/c
Connected.
SQL> select * from emp;
SQL> conn/as sysdba
Connected.
SQL> select address,hash_value, executions, sql_text
  2    from v$sql
  3   where upper(sql_text) like 'SELECT * FROM EMP%'
  4  /

ADDRESS  HASH_VALUE EXECUTIONS SQL_TEXT
-------- ---------- ---------- ------------------------
78B89E9C 3011704998          1 select * from emp
78B89E9C 3011704998          1 select * from emp
78B89E9C 3011704998          2 select * from emp
...--------------------------------------------------------------------------------

我们可以看到这四个查询的语句文本和HASH值都是一样的，但是由于查询的对象不同，只有后面两个语句是可以共享的，不同情况的语句还是需要硬解析的。因此在检查共享池共同SQL语句的时候，是需要根据具体情况而定的。

我们可以进一步查询v$sql_shared_cursor以得知SQL为何不能共享的原因：

代码:--------------------------------------------------------------------------------
SQL> select kglhdpar, address,
  2         auth_check_mismatch, translation_mismatch
  3    from v$sql_shared_cursor
  4   where kglhdpar in
  5   ( select address
  6       from v$sql
  7      where upper(sql_text) like 'SELECT * FROM EMP%' )
  8  /

KGLHDPAR ADDRESS  A T
-------- -------- - -
78B89E9C 786C9D78 N N
78B89E9C 786AC810 Y Y
78B89E9C 786A11A4 Y Y
...--------------------------------------------------------------------------------

TRANSLATION_MISMATCH表示SQL游标涉及到的数据对象是不同的；AUTH_CHECK_MISMATCH表示对同样一条SQL语句转换是不匹配的。

（2）验证SQL语句执行环境是否相同。比如同样一条SQL语句，一个查询会话加了/*+ first_rows */的HINT，另外一个用户加/*+ all_rows */的HINT，他们就会产生不同的执行计划，尽管他们是查询同样的数据。我们下面就一个实例来说明SQL执行环境对解析的影响，我们通过将会话的workarea_size_policy变更来查看对同样一条SQL语句执行的影响：

代码:--------------------------------------------------------------------------------
SQL> alter system flush shared_pool;

System altered.

SQL> show parameter workarea_size_policy

NAME                                 TYPE        VALUE
------------------------------------ ----------- --------------
workarea_size_policy                 string      AUTO

SQL> select count(*) from t;

  COUNT(*)
----------
      5736

SQL> alter session set workarea_size_policy=manual;

Session altered.

SQL> select count(*) from t;

  COUNT(*)
----------
      5736

SQL> select sql_text, child_number, hash_value, address
  2    from v$sql
  3   where upper(sql_text) = 'SELECT COUNT(*) FROM T'
  4  /

SQL_TEXT                       CHILD_NUMBER HASH_VALUE ADDRESS
------------------------------ ------------ ---------- --------
select count(*) from t                    0 2199322426 78717328
select count(*) from t                    1 2199322426 78717328

...--------------------------------------------------------------------------------

可以看到由于不同会话workarea_size_policy设置得不同，即使是同样一条SQL语句还是无法共享的。通过进一步查询v$sql_shared_cursor我们可以发现两个会话的优化器环境是不同的：

代码:--------------------------------------------------------------------------------
SQL> select optimizer_mismatch
  2    from v$sql_shared_cursor
  3   where kglhdpar in
  4   ( select address
  5       from v$sql
  6      where upper(sql_text) = 'SELECT COUNT(*) FROM T' );

O
-
N
Y

...--------------------------------------------------------------------------------

通过如上三个步骤检查以后，如果SQL语句是一致的，那么就会重用原有SQL语句的执行计划和优化方案，也就是我们通常所说的软解析。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/cn_chenfeng/archive/2007/09/04/1771934.aspx