软解析们 执行的工作并不是完全相同的。举个例子，配置会话shared SQL area在一些时候可以减少软解析们的latching，使它们更软。
正常情况下，软解析要比硬解析更合适，因为数据库跳过了优化 和行源产生的步骤，直接到执行。
下图是专有服务结构中执行 UPDATE语句时 shared pool check（检查）的简化代表图
如果检查确定语句在shared pool中有相同的hash值，那么数据库执行语义和环境检查来确定语句的意思是否相同。光语法相同是不够的。举个例子，假设两个不同的用户登录到数据库，并发布了下面的SQL语句：
CREATE TABLE my_table ( some_col INTEGER );
SELECT * FROM my_table;
两个用户发布的SELECT语句，语法相同，但my_table表，却是两个不同schema 中的。这个语义是完全不同的，它意味着第二个语句是不能重用第一个语句解析后的代码的。
即使两个语句语义一样，但是环境差异也可能会强制导致硬解析。在这种情况下，环境是指session中会对执行计划产生 造成影响的所有设置的总称，这些设置有work area size或optimizer 设置等。
思考下面 一个单独用户执行的一系列SQL语句：
ALTER SYSTEM FLUSH SHARED_POOL;
SELECT * FROM my_table;
ALTER SESSION SET OPTIMIZER_MODE=FIRST_ROWS;
SELECT * FROM my_table;
ALTER SESSION SET SQL_TRACE=TRUE;
SELECT * FROM my_table;
在前面这案例中，相同的SELECT语句，在三个不同的优化器环境中执行。理论上来说，数据库会为三个语句 分别创建三个Shared SQL area以及强制每个语句进行硬解析。
SQL Optimization（SQL优化）
如Overview of the Optimizer里面介绍的，查询优化是一个处理过程，是选择执行一个SQL语句 最效率的途径的处理过程。数据库基于收集的统计信息来优化查询。优化器会用到 行的数量，数据集的大小，以及其他因素去产生一些可能的执行计划，为每一个计划赋予一个数字化的cost（成本）。数据库将使用成本最低的计划。
数据库必须为每一个第一无二的DML语句执行最少一次的硬解析，以及在解析过程中执行优化。DDL语句永远不优化，除非它包括了一个DML组件，如一个子查询。这个DML组件需要优化。
SQL Row Source Generation（SQL行源产生）
行源产生器是一个软件，它从优化器中 接受优化后的执行计划 然后产生一个称之为query plan（查询计划）的迭代计划，它供数据库的其余部分使用。这个迭代计划是一个二进制程序，由SQL虚拟机执行，产生结果集。
查询计划采用组合多个步骤的形式。每步返回一个row set（行集）。这个里面的行要么是被下一步使用，要么被最后一步使用，然后反馈给执行SQL语句的应用。
一个row source（行源）就是一步中返回的 row set，且带有能够迭代该row set的控制结构。
行源可以是一个表，视图，或一个join或grouping操作的结果。
行源产生器 生成一个 row source tree（行源树）,它是行源的一个集合（汇总）。行源树显示了下面信息：
·语句相关的表的顺序
·在语句中提及的每个表的访问方法
·语句中join语句影响的表的 join方法
·如果filter，sort，或aggregation等的数据操作
下面案例显示了当AUTOTRACE 开启时 一个SELECT语句的执行计划。这个语句的执行计划就是row source generator 输出的东西。
Example 7-6 Execution Plan
SELECT e.last_name, j.job_title,d.department_name
FROM hr.employees e, hr.departments d, hr.jobs j
WHERE e.department_id = d.department_id
AND e.job_id = j.job_id
AND e.last_name LIKE 'A%' ;
Execution Plan
----------------------------------------------------------
Plan hash value: 975837011
---------------------------------------------------------------------------------------------
| Id |Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------------
| 0 |SELECT STATEMENT | | 3 | 189 | 7 (15)| 00:00:01 |
|* 1| HASH JOIN | | 3 | 189 | 7 (15)| 00:00:01 |
|* 2| HASH JOIN | | 3 | 141 | 5 (20)| 00:00:01 |
| 3| TABLE ACCESS BY INDEX ROWID|EMPLOYEES | 3 | 60 | 2 (0)| 00:00:01 |
|* 4| INDEX RANGE SCAN | EMP_NAME_IX | 3 | | 1 (0)| 00:00:01 |
| 5| TABLE ACCESS FULL | JOBS | 19 | 513 | 2 (0)| 00:00:01 |
| 6| TABLE ACCESS FULL | DEPARTMENTS | 27 | 432 | 2 (0)| 00:00:01 |
---------------------------------------------------------------------------------------------
Predicate Information (identified byoperation id):
---------------------------------------------------
1 -access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")
2 -access("E"."JOB_ID"="J"."JOB_ID")
4 -access("E"."LAST_NAME" LIKE 'A%')
filter("E"."LAST_NAME" LIKE 'A%')
SQL Execution（SQL执行）
在执行过程中，SQL引擎执行通过 行源产生器产生的树中的每个row source。这一步是唯一一个DML处理过程中的强制步骤。
下图是一个execution tree（执行树），也称之为 parse tree（解析树），它显示了一步的