软解析、硬解析、软软解析区别.docx

先来张大图：结合上图来说明一下解析的各个步骤涉及的锁。软解析、硬解析、软软解析区别的简单说明：为了将用户写的sql文本转化为oracle认识的且可执行的语句，这个过程就叫做解析过程。解析分为硬解析和软解析，SQL语句第一次解析时必须进行硬解析一句话说明硬解析与软解析的区别是：硬解析=需要生成执行计划 软解析=不需要生成执行计划在Oracle中存在两种类型的SQL语句，一类为DDL语句，不共享使用，也就是每次执行都需要进行硬解析。还有一类就是DML语句，会进行硬解析或软解析。硬解析变成软解析：绑定变量软解析变成软软解析：设置session_cached_cursors，详见图中涉及的各结构简单介绍：涉及的各结构的简单介绍： 详见：父游标:保存HASH值，SQL文本-相同SQL语句，就只有一个父游标父游标里主要包含两种信息：sql文本以及优化目标。父游标在第一次打开时被锁定，直到其他所有的session都关闭该游标后才被解锁。当父游标被锁定的时候是不能被交换出librarycache的，只有在解锁以后才能被交换出library cache。父游标被交换出内存时父游标对应的所有子游标也被交换出library cache。子游标:一个父游标下会有多个子游标，各个子游标的执行计划不一样-多版本.一个父下必有一个子游标，可以有多个子游标。子游标包括游标所有的信息，比如具体的执行计划、绑定变量等。子游标随时可以被交换处library cache，当子游标被交换出library cache时，oracle可以利用父游标的信息重新构建出一个子游标出来，这个过程叫做reload（重载）。父HANDLE，里面有父游标堆0的地址。父游标堆0:有指向一个或多个子游标的HANDLE够句柄地址子游标的HANDLE:有子游标堆0地址子游标堆0:有SQL语句依赖关系，并指向子游标的堆6子游标堆6:存有SQL语句的执行计划SQL语句在Library cache执行的第一次检查过程：1.通过语法语义权限等检查的SQL语句进入Library cache2.将SQL文本转化为ASCII值(大小写ASCII不同)并进行hash函数的运算4.得到一个HASH值对应到hash bucket的号码#以上检查通过后，进入以下解析过程软软解析：-通过设置session_cached_cursors参数实现-SQL执行=3次（可以不是一个会话执行的SQL），堆6的DS-堆描述符地址被放入UGA(属于PGA)-LOCK变为1-NULL标记语句为缓存并保证内存不被释放(堆6释放堆0才能释放)。也就是SQL执行3次，被缓存。第四次，就是软软解析了。-优化目标：命中率90%以上。会话发起SQL，会首先在User Global Area中查找CURSOR信息。此时，在父游标handle,子游标handle和子游标堆6上使用NULL 1。软解析：1.获得library cacheLatch -如未获得将产生：Latch:library cache2.获得library cache lock，检索bucket上的父游标handle，得到所指向的父游标堆0-LCO的内存地址。3.获得library cache pin，读取父游标堆0-LCO，得到子游标handle地址。4.获得library cache lock，检索子游标handle，得到所指向的子游标堆0-子LCO的内存地址。5.获得library cache pin，读取子游标堆0-子LCO从而得到子游标堆6地址。6.读取子游标堆6，得到SQL执行计划。#找到child lco后，增加parsecount(total)统计值。SQL开始执行：此时以共享模式获得library cache lock和library cache pin，并执行SQL。FETCH阶段：执行完成进入FETCH阶段，SQLCURSOR将library cache lock转换为null模式，释放library cache pin。#在尝试软解析时：-如果未检索到相同的父游标LCO或子游标LCO时，发生硬解析。-如果子游标堆6上不能加共享library cachepin或者child lco中信息不完整，需要重建执行计划-记录为硬解析。硬解析：如果未检索到相同的父游标LCO或子游标LCO时，发生硬解析。进程会一直持有library cache latch，直到硬解析结束为止。1.获取shared pool latch,从freelist的bucket上查找合适大小的CHUNK。不存在大小合适的CHUNK会分割大CHUNK，剩余的会再进入相应的BUCKET。如 果不能从free list的bucket上查找到合适大小的CHUNK，则进入 lru list;如果仍不能获取到CHUNK，则从shared pool剩余内在中分配。如果CURSOR达到 _shared_pool_reserved_min_alloc隐含参数的大小标准(11.2.0.4中是4400），则从保留池中分配CHUNK;如 果这些分配CHUNK操作都失败，报错：ORA-04031。如bucket列表过长或者碎片严重，产生latch:shared pool争用。2.分配到CHUNK后。获得library cachelock-独占模式，创建父游标handle3.获得library cache pin，创建父游标堆0-父LCO的信息。-library cache lock转为NULL4.获得library cache lock，创建子游标handle5.获得library cache pin，创建子游标堆0-子LCO的信息。6.library cache pin，创建子游标堆6-执行计划的信息（通过优化器创建一个最优的执行计划，这个过程会根据数据字典里面记录的对象的统计信息，来计算最优的执行计划，这一步涉及的运算量很大，最耗CPU资源）。SQL开始执行：此时以共享模式获得library cache lock和library cache pin，并执行SQL。FETCH阶段：执行完成进入FETCH阶段，SQLCURSOR将library cache lock转换为null模式，释放library cache pin。关于MUTEX与图中librarycache Latch/PIN/LOCK的对应：关于MUTEX，可以简单的把library cache Latch/PIN/LOCK当做MUTEX的不同模式来套入此步骤。在10G中，Mutex主要保护 handle和LCO-替代library cache PIN/LOCK在11G中，Mutex可以保护bufket上链表，handle和LCO-替代library cache Latch/PIN/LOCK句柄上访问竞争：Cursor:mutex 堆的访问竞争：Cursor:pin解析时MUTEX的相关争用1、相关锁（1）、计算HASH值，找到Bucket，搜索HASH链表，查找句柄。LIbrary Cache Latch（11G后被Mutex取代）（2）、在父游标句柄中查找父游标堆0mutex（取代Library cache lock latch) ，Library cache lock（3）、在父游标堆0中，查找子游标句柄。 两次mutex。两种类型的Mutex。取代了Librarycache pin latch和Library cache pin 。（4）、在子游标句柄中，查找子游标堆0地址。mutex（取代Library cache lock latch) ，L