library cache

这里简单发表下对库告诉缓存的认识,大家知道共享池是有library cache和data dictionary cache和控制部分组成,首先sql执行的过程显示语法分析阶段,然后是语意分析阶段,也就是验证下对象权限等一些列的东西,再下面就是SQL进行hash运算,运算后匹配library cache里的hash桶,再匹配hash桶上面的handle,也就是句柄,如果匹配成功,那么去找子游标,如果不成功,那么就生成一个handle,这里也就是硬解析,挂载hash桶上。
这里如果是不同用户或者,期间对象权限更改,就算是SQL文本一样,也是无法共享子游标的,生成handle,其实就是要想共享池申请空闲的内存,期间获得shared pool latch ,那么很容易产生冲突。handle其实就是存放的父游标,真正的执行计划是存放在子游标上的,也就是heap6上,一个父游标可能对应多个子游标,比如,不同用户下的相同SQL,就会造成1个父对多个子游标,这种父游标存在,而要重新生成子游标,就是relaod,需要耗硬件资源,数据库性能也就十分低下,所以我们要避免硬解析和reload,解析过程中很消耗资源,而且容易造成 latch的冲突,父游标里主要包含SQL文本,父游标打开时,是被锁住的,也就是不能交换出library cache ,子游标主要包含执行计划和绑定变量,这个就很重要。这里再介绍下软解析,其实只要在hash桶里可以匹配对应的SQL文本,那么就是软解析,说明之前运行过该sql,其实sql执行期间只要步骤可以跳过,那么我们就可以定位为软解析。这里还有软软解析,这个是最好性能,session_cached_cursors,当会话相同的CURSOR第三次访问是,那么会话会在PGA里做个标记,就算会话结束,cursor也不会从library cache交换出去,这里不需要访问library cache,只和PGA有关联,共享的东西这里我们没去访问,也就是不争用资源,性能得到提升。
你活着,证明了什么?