为了将用户写的SQL文本转化为Oracle认识的且可执行的语句，这个过程就叫做解析过程。

解析分为硬解析和软解析。

一条SQL语句在第一次被执行时必须进行硬解析。

当客户端发出一条SQL语句（也可以是一个存储过程或者一个匿名PL/SQL块）进入shared pool时（注意，我们从前面已经知道，Oracle对这些SQL不叫做SQL语句，而是称为游标。

因为Oracle在处理SQL时，需要很多相关的辅助信息，这些辅助信息与SQL语句一起组成了游标），Oracle首先将SQL文本转化为ASCII值，然后根据hash函数计算其对应的hash值（hash_value）。

根据计算出的hash值到library cache中找到对应的bucket，然后比较bucket里是否存在该SQL语句。

如果不存在，则需要按照我们前面所描述的，获得shared pool latch，然后在shared pool 中的可用chunk链表（也就是bucket）上找到一个可用的chunk，之后释放shared pool latch。

在获得了chunk以后，这块chunk就可以认为是进入了library cache。

接下来，进行硬解析过程。

硬解析包括以下几个步骤。

对SQL语句进行文法检查，看是否有文法错误。

比如没有写from、select拼写错误等。

如果存在文法错误，则退出解析过程。

到数据字典里校验SQL语句涉及的对象和列是否都存在。

如果不存在，则退出解析过程。

这个过程会加载dictionary cache。

将对象进行名称转换。

比如将同名词翻译成实际的对象等。

比如select * from t中，t是一个同名词，指向hr.t1，于是Oracle将t转换为hr.t1。

如果转换失败，则退出解析过程。

检查发出SQL语句的用户是否具有访问SQL语句里所引用的对象的权限。

如果没有权限，则退出解析过程。

通过优化器创建一个最优的执行计划。

这个过程会根据数据字典里记录的对象的统计信息，来计算最优的执行计划。

这一步牵涉大量数学运算，是最消耗CPU资源的。

将该游标所产生的执行计划、SQL文本等装载进library cache的heap中。

在硬解析的过程中，进程会一直持有library cache latch，直到硬解析结束为止。

硬解析结束以后，会为SQL语句产生两个游标，一个是父游标，另一个是子游标。

父游标里主要包含两种信息：SQL文本以及优化目标（optimizer goal）。

父游标在第一次打开时被锁定，直到其他所有的session都关闭该游标后才被解锁。

当父游标被锁定的时候是不能被交换出library cache的，只有在解锁以后才能被交换出library cache。

父游标被交换出内存时，父游标对应的所有子游标也被交换出library cache。

子游标包括游标所有的信息，比如具体的执行计划、绑定变量等。

子游标随时可以被交换出library cache，当子游标被交换出library cache
从记录父游标的视图v$sqlarea的version_count列可以看到，该SQL语句有2个子游标。

而从记录子游标的视图v$sql里可以看到，该SQL文本确实有两条记录，而且它们的SQL
文本所处的地址（ADDRESS列）也是一样的，但是子地址（CHILD_ADDRESS）却不一样。

这里的子地址实际就是子游标所对应的heap 0的句柄。

由此我们也可以看到，存在许多因素可能导致SQL语句不能共享。

常见的因素包括SQL 文本大小写不一致、SQL语句的绑定变量的类型不一致、SQL语句涉及的对象名称虽然一致但是位于不同的schema下、SQL的优化器模式不一致（比如添加提示、修改了optimizer_mode参数等）等。