【转载】Oracle绑定变量、硬解析、软解析

转载地址：http://cjjwzs.iyunv.com/blog/1010263

Oracle在执行SQL语句时，普遍存在以下几个步骤：
当SQL语句首次执行，Oracle将确认该句语句的语法是否正确（语法解析Syntax parse）并进一步确认语句相关表和列的存在性等因素(语义解析semantic parse)以及优化器决定执行计划等步骤。整个过程称之为硬解析，硬解析消耗大量的CPU时间和系统资源。硬解析过多会有效降低系统性能。
若之前已进行过硬解析，且解析后的分析树和执行计划仍存在于共享池中，则同样的SQL仅需要软解析。软解析将输入的SQL语句转换为哈希代码，同共享池内哈希链表上的已有记录进行对比，找出对应的游标信息，使用已有的执行计划执行。
绑定变量,将实际的变量值代入SQL语句中。
执行SQL语句，查询语句将返回结果集。
不使用绑定变量的SQL语句，Oracle无法将它们视为相同的，如以下两句语句：
select * from emp where empno=1234
select * from emp where empno=5678
因为自由变量的不同，Oracle认为以上是2句不同的语句，则当第一条被硬解析后，第二条SQL执行时仍无法避免硬解析。实际在以上不使用绑定变 量的情况中，只要自由变量有所改变则需要一次硬解析。这是强烈建议使用绑定变量的主要原因，使用绑定变量的语句变量的实际值仅在SQL执行的最后阶段被代 入。如以下语句：
select * from emp where empno=:x
该语句使用绑定值:x替代自由变量，在应用中语句可能以预编译或普通编译的方式存在，仅在执行阶段代入变量值，多次执行仅需要一次硬解析，较不使用绑定变量情况性能大大提升。
同时过多的硬解析还会引发共享池碎片过多的问题。因为每当需要硬解析一个SQL或者PLSQL语句时，都需要从shared pool中分配一块连续的空闲空间来存放解析结果。Oracle首先扫描shared pool查找空闲内存，如果没有发现大小正好合适的空闲chunk，就查找更大的chunk，如果找到比请求的大小更大的空闲chunk，则将它分裂，多 余部分继续放到空闲列表中。因为过多的硬解析加剧了内存段分配的需求，这样就产生了碎片问题。系统经过长时间运行后，就会产生大量小的内存碎片。当请求分 配一个较大的内存块时，尽管shared pool总空闲空间还很大，但是没有一个单独的连续空闲块能满足需要。这时，就可能产生 ORA-4031错误。
通常我们可以通过以下SQL语句将系统中非绑定变量的语句找出：
SELECT substr(sql_text,1,40) “SQL”,
count(*) ,
sum(executions) “TotExecs”
FROM v$sqlarea
WHERE executions < 5 –-语句执行次数
GROUP BY substr(sql_text,1,40)
HAVING count(*) > 30 –-所有未共享的语句的总的执行次数
ORDER BY 2;
以上语句在实际使用中substr函数截取到的字符串长度需要视乎实际情况予以变化。
对于非绑定变量且短期内无法修改的应用，Oracle存在参数cursor_sharing可以改善其表现。cursor_sharing默认为 exact,对使用自由变量的语句不做额外处理；当设为force时，非绑定变量的SQL语句被进一步处理以达到共享SQL的目的，但以上处理步骤同样要 消耗一定的CPU时间；当设为similar时，若数据库存在语句相关统计信息则其表现如exact,若无统计信息则表现为force。 cursor_sharing参数是Oracle针对无法修改的非绑定变量应用所提出的折中方案，但cursor_sharing为force值时存在一 定SQL引发bug或语句无效的情况，且额外的处理操作同样需要消耗一定量的CPU时间和系统资源。故针对系统性能的最优方案往往是直接修改应用代码，使 用绑定变量特性。