标签：
提到软解析(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%‘
关于MySQL的解析
MySQL并没有所谓的软解析和硬解析，它全部操作都是硬解析，由于MySQL的解析树代价比较小，也就是硬解析代价不像Oracle那么大，所以MySQL的硬解析并不会成为它的瓶颈。
Oracle中的软软解析（Soft Soft Parse）
(好像有些资料中并没有将这个算在其中)
所谓的软软解析，就是不解析。当设置了session_cached_cursors参数时，当某个session第三次执行相同的SQL语句时，则会把该SQL语句的游标信息转移到该session的PGA中。这样，当该session在执行该SQL语句时，会直接从PGA中取出执行计划，从而跳过硬解析的所有步骤。
标签：
原文地址：http://www.cnblogs.com/cto6608/p/5476119.html
