3_软硬软软解析大致工作流程

软解析：
1.用户发布sql
2.oracle 检查sql 的语法和权限，确保所有的对象都存在并且可访问
3.在library cache 中对sql文本（sql text）进行hash 计算，根据hash 值找到合适的hash bucket
4.申请持有保护hash bucket 的library cache latch,如申请latch成功，则进一步检索该bucket下是否存在相同的child lco。如果chain 很长，则检索LCO时间就会变长，那么library cache latch 争用的概率就会增大。
5.如果存在相同的child lco，则增加parse count(total)统计值。
6.对sql cursor 以shared 模式获得library cache lock 和library cache pin ,并执行sql.这个阶段称之为执行阶段
7.sql cursor 执行结束之后进入fetch 阶段，在fetch 数据阶段，sql cursor 将library cache lock 变换为null 模式，并释放library cache pin

软解析的目的是最大限度地重用保存在library cache 中的LCO信息，所以经常可以看到软解析高的系统里shared pool 的利用率不高。

硬解析：
当软解析失败，无法在hash bucket 中定位到相同的LCO 信息（也包含子LCO信息）时，oracle就会使用硬解析。以下为硬解系的解析过程：
1.获得shared pool latch,从free list 的bucket 中查找合适大小的free chunk.如果free list 中的bucket列表过长或者shared pool 碎片化严重，那么在多个进程同时请求分配内存时，则会发生shared pool latch 争用。
2.如果不存在大小合适的free chunk ,则分割较大的free chunk,分割后的free chunk 重新挂载到适当大小的bucket下。如果不存在free chunk,则检索LRU LIST.如果在LRU LIST中也不能获取大小合适的bucket,则从shared pool的剩余空闲内存中分配。如果cursor大小大于_shared_pool_reserved_min_alloc 隐含参数设定的阈值，那么在reserved list 中寻找free chunk .如果以上过程均失败，则出现ora-04031 错误。
3.若找到大小合适的chunk,则对cursor相应的handle(library cache handle)以exclusive模式获得library cache lock,并创建lco信息。在创建LCO信息之后，library cache lock 变换为null 模式，然后以exclusive 模式获得library cache pin,并创建执行计划等信息。硬解析执行成功后oracle增加parse count(hard)统计值。
4.执行阶段，和软解析类似。
5.数据获取阶段，和软解析类似。

软软件解析：
由于在软解析过程中，需要获得library cache latch,所以在高并发软解析的系统中，依然会出现与latch:library cache 相关的等待事件，从而导致性能缓慢。软软解析的核心原理是通过设置session_cached_cursors 参数，将某个会话中常用的SQL放入UGA的缓冲区中，当会话发起相同的sql时，可以快速的从UGA中取得cursor信息，从而减少共享池的争用。当一个cursor被解析3次以上（包含3次）时就会被放入UGA会话缓冲区。