本文转载自：https://blog.csdn.net/holandstone/article/details/50108501
提到软解析(soft prase)和硬解析(hard prase)，就不能不说一下Oracle对sql的处理过程。当你发出一条sql语句交付Oracle，在执行和获取结果前，Oracle对此sql将进行几个步骤的处理过程：
1、语法检查(syntax check)
检查此sql的拼写是否语法。
2、语义检查(semantic check)
诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。
3、对sql语句进行解析(prase)
利用内部算法对sql进行解析，生成解析树(parse tree)及执行计划(execution plan)。
4、执行sql，返回结果(execute and return)
其中，软、硬解析就发生在第三个过程里。
Oracle利用内部的hash算法来取得该sql的hash值，然后在library cache里查找是否存在该hash值；
假设存在，则将此sql与cache中的进行比较；
假设“相同”，就将利用已有的解析树与执行计划，而省略了优化器的相关工作。这也就是软解析的过程。
诚然，如果上面的2个假设中任有一个不成立，那么优化器都将进行创建解析树、生成执行计划的动作。这个过程就叫硬解析。
创建解析树、生成执行计划对于sql的执行来说是开销昂贵的动作，所以，应当极力避免硬解析，尽量使用软解析。
这就是在很多项目中，倡导开发设计人员对功能相同的代码要努力保持代码的一致性，以及要在程序中多使用绑定变量的原因。当客户端进程，将SQL语句通过监听器发送到Oracle时, 会触发一个Server process生成，来对该客户进程服务。Server process得到SQL语句之后，对SQL语句进行Hash运算，然后根据Hash值到library cache中查找，如果存在，则直接将library cache中的缓存的执行计划拿来执行，最后将执行结果返回该客户端，这种SQL解析叫做软解析；如果不存在，则会对该SQL进行解析parse，然后执行，返回结果，这种SQL解析叫做硬解析。
1.硬解析的步骤
硬解析一般包括下面几个过程：
1）对SQL语句进行语法检查，看是否有语法错误。比如select from where 等的拼写错误，如果存在语法错误，则推出解析过程；
2）通过数据字典(row cache)，检查SQL语句中涉及的对象和列是否存在。如果不存在，则推出解析过程。
3）检查SQL语句的用户是否对涉及到的对象是否有权限。如果没有则推出解析；
4）通过优化器创建一个最优的执行计划。这个过程会根据数据字典中的对象的统计信息，来计算多个执行计划的cost，从而得到一个最优的执行计划。这一步涉及到大量的数据运算，从而会消耗大量的CPU资源；(library cache最主要的目的就是通过软解析来减少这个步骤)；
5）将该游标所产生的执行计划，SQL文本等装载进library cache中的heap中。
2.软解析
所谓软解析，就是因为相同文本的SQL语句存在于library cache中，所以本次SQL语句的解析就可以去掉硬解析中的一个活多个步骤。从而节省大量的资源的耗费。
一、Shared pool 作用：缓存SQL语句及SQL语句的执行计划 SQL语句执行三步：解析（parse）------执行（exec）------获取数据（fetch）
shared pool的组成： 3块区域：free、librarycache、row cache（dictionary cache） library cache：缓存SQL语句以及SQL语句的执行计划 dictionary cache：Oracle数据库自身的信息（数据库中有多少表、多少用户、表有多少列、列名是什么、列的数据类型、每个表多大）存放在dictionary中
数据字典举例：想知道数据库中有没有T1表 1、create table t1 as select * from dba_objects; 2、desc dba_tables; ---------------数据字典信息表 3、select table_name,owner from dba_tables where table_name like 'T1%’; 所有数据字典信息可在官方文档中查找booksàreferenceàdba_tables
1、查看librarycache大小 select * from v$sgastat a where a.NAME = 'library cache'; 2、free空间大小 select * from v$sgastat a where a.pool = 'shared pool' anda.NAME = 'free memory'; 3、row cache空间大小 select * from v$sgastat a where a.NAME = 'row cache';
二、解析：(hard parse,soft parse) 硬解析步骤：1、server process判断SQL语句语法是否有错误 2、查看SQL语句所涉及的对象是否存在（表是否存在等等） 3、执行SQL的用户对对象是否有相应权限（系统权限、对象权限） 4、生成执行计划--------一条SQL语句有多种执行方案，在N中执行方案中挑选出最优的一个最优的执行方案作为这条SQL执行计划--------最消耗资源 软解析：没有上述第四步，仅仅是常规判断
什么时候发生硬解析： Server process 拿着SQL语句在librarycache中找，如果这条SQL语句在library cache中没有，说明这条SQL语句和他的执行计划在library cache中没有-------硬解析 有--------软解析 无论hard parse还是soft parse，解析过程中用到很多数据库自身信息（权限信息、对象信息、对象统计信息------字典信息）；即对SQL语句进行解析（软硬）的时候，都要频繁的访问数据字典信息----------所以row cache放在shared pool和library cache在一起
软硬解析的具体情况 select name,value from v$sysstat where name like 'parse%'
六、总结
1.尽可能的避免硬解析，因为硬解析需要更多的CPU资源，闩等。
2.cursor_sharing参数应权衡利弊，需要考虑使用similar与force带来的影响。
3.尽可能的使用绑定变量来避免硬解析
我们都知道在Oracle中每条SQL语句在执行之前都需要经过解析，这里面又分为软解析和硬解析。在Oracle中存在两种类型的SQL语句，一类为 DDL语句(数据定义语言)，他们是从来不会共享使用的，也就是每次执行都需要进行硬解析。还有一类就是DML语句(数据操纵语言)，他们会根据情况选择要么进行硬解析，要么进行软解析。
DML:INSERT,UPDATE,DELETE,SELECT
DDL:CREATE,DROP,ALTER
一. SQL 解析过程
Oracle对此SQL将进行几个步骤的处理过程：
1、语法检查(syntax check): 检查此sql的拼写是否语法。
2、语义检查(semantic check): 诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。
3、对sql语句进行解析(prase): 利用内部算法对sql进行解析，生成解析树(parse tree)及执行计划(execution plan)。
4、执行sql，返回结果(execute and return)
二． 解析过程详解
2.1 语法检测
判断一条SQL语句的语法是否符合SQL的规范，比如执行：
SQL> selet * from emp;
我们就可以看出由于Select关键字少了一个“c”，这条语句就无法通过语法检验的步骤了。
2.2 语义检查
语法正确的SQL语句在解析的第二个步骤就是判断该SQL语句所访问的表及列是否准确？用户是否有权限访问或更改相应的表或列？ 比如如下语句：
SQL> select * from emp;
select * from emp
*
ERROR at line 1:
ORA-00942: table or view does not exist
由于查询用户没有可供访问的emp对象，因此该SQL语句无法通过语义检查。
2.3 解析(Parse)
2.3.1 Parse主要分为三种：
1、Hard Parse (硬解析)
2、Soft Parse (软解析)
3、Soft Soft Parse(好像有些资料中并没有将这个算在其中)
Hard Parse： 就是上面提到的对提交的Sql完全重新从头进行解析(当在Shared Pool中找不到时候将会进行此操作)，总共有一下5个执行步骤：
1：语法分析
2：权限与对象检查
3： 在共享池中检查是否有完全相同的之前完全解析好的. 如果存在，直接跳过4和5，运行Sql, 此时算soft parse.
4：选择执行计划
5：产生执行计划
注：创建解析树、生成执行计划对于sql的执行来说是开销昂贵的动作，所以，应当极力避免硬解析，尽量使用软解析。这就是在很多项目中，倡导开发设计人员对功能相同的代码要努力保持代码的一致性，以及要在程序中多使用绑定变量的原因。
Soft Parse： 就如果是在Shared Pool中找到了与之完全相同的Sql解析好的结果后会跳过Hard Parse中的后面的两个步骤。
Soft Soft Parse： 实际上是当设置了session_cursor_cache这个参数之后，Cursor被直接Cache在当前Session的PGA中的，在解析的时候只需要对其语法分析、权限对象分析之后就可以转到PGA中查找了，如果发现完全相同的Cursor，就可以直接去取结果了，也就就是实现了 Soft Soft Parse.