PLSQL_性能优化系列07_Oracle Parse Bind Variables解析绑定变量

2014-09-25 BaoXinjian

一、绑定变量用法和使用场合



使用绑定变量的重要性:如果不使用绑定变量而使用常量,会导致大量硬解析。由于硬解析的种种危害,不使用绑定变量往往是影响oracle性能和扩展性的最大问题

以下为一些错误写法和正确写法的例子

1. PLSQL中普通查询

(1). 错误写法

SELECT * FROM emp WHERE empno=123;

(2). 正确写法(未使用绑定变量)

Empno:=123;
SEELCT* FROM emp WHERE empno=:empno;

2. PLSQL中在使用动态SQL

(1). 错误的写法

sqlstr:= ‘select * from emp where empno=‘||empno;Execute immediate for sqlstr;

EXECUTE IMMEDIATE FOR sqlstr;

(2). 正确的写法

sqlstr:= ‘select * from  empno=‘||empno;

EXECUTE IMMEDIATE FOR sqlstr;

因为前者使用字符串拼接较容易,很多人会这么用。

二、如何判断和定位系统中未使用绑定变量的语句



在awr的load profile部分,有个Hard parses指标,表示每秒的hard parse。

另外在Instance Efficiency Percentages部分,Soft Parse %这个指标反映的是硬解析占所有解析的比例。

这两个指标一个是绝对值,一个是相对值。每秒hard parse指标应该比较低,而soft parse%应该较高(有人说应大于95%)。

具体合理指标和系统大小、业务量、业务类型都有关,可以参考的是siebel系统中这两个值是11和98%。如果这两个指标超出合理范围,则说明硬解析太多,应引起重视,分析产生的原因。

例子: 未使用绑定变量是导致硬解析的最常见原因,那么如何找出这些SQL

Step1. 可以用以下语句找到哪些SQL:

  SELECT substr(sql_text,1,50) "SQL",  count(*), sum(executions) "TotExecs"
    FROM v$sqlarea
   WHERE executions < 5
GROUP BY substr(sql_text,1,50)
  HAVING count(*)> 30
ORDER BY 2; 

Step2. 用以下语句找到运行这些sql的用户和模块

SELECT service, module, parsing_schema_name, sql_text
  FROM v$sql where sql_text LIKE ‘select rownum as ….id%’;

三、减少解析,包括硬解析和软解析



1. 问题由来

Sql优化(六) 中我们介绍了soft parse/hard parse的概念,以及通过使用绑定变量减少hard parse的技术。

在生产环境中,我们发现soft parse太多也会引起性能问题,例如较高的library cachelatch contention等待,尽管soft parse相比hard parse,性能开销已经小很多。

最高境界是no parse;减少parse的诀窍是oracle的cursor。

2. Sql的执行过程和parse分类,oracle运行sql时,过程如下:

(1). Sql cursor是否open?如果是则跳到5) 这种情况即为no parse,为方便比较,我们也作为parse的一种类型

(2). cursor是否在session cache中(pga),如果存在,则跳到5)这种情况oracle专家tom称其softer soft parse

(3). 进行syntax check和 semantic check,然后在shared pool的hash表中寻找,如果匹配到则跳到step 5),这称为soft parse

(4). 如果匹配失败,则需要security-check,optimize,生成query plan等等,这称为hard parse(硬解析),可以想像成源程序先编译后运行。

(5). execute

3. 各类parse的开销

我们分别比较上面几种parse类型的开销

可见hard parse开销最大,soft parse其次。Parse引起的latch contention不仅影响程序运行速度,而且影响程序的扩展性(scalable)

4.  如何减少hard parse

(1). 使用绑定变量

这是编程方法中最影响性能的因素之一,具体做法由其他文章介绍

(2). 编程规范,良好的编程习惯

编程规范可以规定表名、关键字是否用大写,空格怎么用等等,所有程序员遵循统一的规范。

举个例子说明其意义,在数据库中cursor_sharing缺省值为exact,这意味着oracle对sql进行匹配时,以下两句是不匹配的,第二句会引起hard parse

select count(*) from test_table where tracking_id=1234567688;

select count(*) from TEST_TABLE where tracking_id=1234567688;

当然第一点远比第二点重要,大家可以想象。

5. 如何减少soft parse

即no parse和softer soft parse,诀窍是oracle 的cursor,具体来说有两种方法

Step1. Skip parse

在子程序中,跳过parse,采用以下写法:

if (firsttime)

parse

end if

bind

execute

而不要这么写,因为每次调用都进行了parse

parse

bind

execute

close

例如在java中,通过prepareStatement,每个session对该sql prepare一次,而不是每次调用都prepare一次。

2. PLSQL自动cache cursor

在PLSQL中,所有static sql都是被cache的,重复调用时不会进行soft parse。注意动态sql除外。

declare
   i number;
   j number;
   k number;
begin
   i:=1;
   k:=12345678;
   while i<=10000 loop
     select count(*) into j from test_table where tracking_id=k;
     i:=i+1;
   end loop;
end;
/

3. SESSION_CACHED_CURSORS参数

如果该参数非0,则在sqlplus中,当同一sql进行了三次soft parse,oracle会将cursor 移到cache中,第4次调用时则不需soft parse,但仍会注册为parse,

parse count (total)仍会增加,同时session cursor cache hits也会增加。

该参数影响以下工具:

  • 1)Sqlplus
  • 2)Plsql中的native dynamic sql
  • 3)Java中不好的写法,如不进行prepare而直接execute 的sql
  • 4)Oracle产生的recursive sql

各个版本的区别:

Oracle9i中session_cached_cursors默认为0,oracle 10g中似乎为20,ora11g默认为50,因此在oracle9i中,如果要使用此特性,需要修改默认值。

另外一点要注意的是,soft parse表示一个session进行了hard pasre之后,只要仍在shared pool中,所以其他session都不需再hard parse。

而session_cached_cursor,是针对同一session而言的。因此如果一个程序频繁logon/logoff,是无法用到这一特性的。

********************作者:鲍新建********************

时间: 2024-08-01 00:27:05

PLSQL_性能优化系列07_Oracle Parse Bind Variables解析绑定变量的相关文章

PLSQL_性能优化系列16_Oracle DataScan数据扫描

对数据的读取操作是非常消耗资源的,如何减少对数据的扫描,是提升sql效率的一个重要方面,例如物化视图技术.本篇介绍几种sql写法,分别是CASE expression/DML with returning clause /multitable insert.[@[email protected]] 一. 用CASE EXPRESSION将多句查询组合在一起SELECT COUNT (*)FROM employeesWHERE salary < 2000;SELECT COUNT (*)FROM

PLSQL_性能优化系列06_Oracle Soft Parse / Hard Parse软硬解析

2014-08-11 BaoXinjian 一.摘要 Oracle硬解析和软解析是我们经常遇到的问题,所以需要考虑何时产生软解析何时产生硬解析,如何判断 1. SQL的执行过程 当发布一条SQL或PL/SQL命令时,Oracle会自动寻找该命令是否存在于共享池中来决定对当前的语句使用硬解析或软解析. 通常情况下,SQL语句的执行过程如下: Step1. SQL代码的语法(语法的正确性)及语义检查(对象的存在性与权限). Step2. 将SQL代码的文本进行哈希得到哈希值. Step3. 如果共享

PLSQL_性能优化系列04_Oracle Optimizer优化器

2014-09-25 BaoXinjian 一.摘要 1. Oracle优化器介绍 本文讲述了Oracle优化器的概念.工作原理和使用方法,兼顾了Oracle8i.9i以及最新的10g三个版本.理解本文将有助于您更好的更有效的进行SQL优化工作. 2. RBO优化器 RBO是一种基于规则的优化器,随着CBO优化器的逐步发展和完善,在最新的10g版本中Oracle已经彻底废除了RBO. 正在使用Oracle8i或9i的人们或多或少的都会碰到RBO,因此在详细介绍CBO之前,我们有必要简单回顾一下古

PLSQL_性能优化系列01_Oracle Index索引

2014-06-01 BaoXinjian 一.摘要 在PLSQL查询优化中,使用和接触最多的应该是索引Index这个概念,个人也觉得对Index选择和优化是程式优化过程中比较重要的概念,特别是刚开始接触PLSQL性能优化 索引的一些概念 一个索引可以由一个或多个列组成, 对列设置索引其实就是对列的内容按一定的方式进行排序,检索数据的时候,检索排过序的数据,检索到最后一个有效数据之后就跳出检索 这样就不必进行全表扫描了,同时可以应用很多算法提高检索效率 数据库多用二分法检索数据 索引的连接方式

PLSQL_性能优化系列08_Oracle Insert / Direct Insert性能优化

2014-09-25 BaoXinjian 一.Insert 性能影响 应用设计不合理导致的session之间的互锁(enqueue)是影响程序可扩展性最常见的原因.此外,一些共享资源的争用,也会导致性能下降. 本篇介绍两个由并发insert操作导致的等待事件(wait event),以及如何通过优化物理设计来进行改善. 普通Insert操作本身产生的是行锁,因此进程相互之间不会锁住(enqueue),但当很多进程insert同一张表时,会有资源上冲突. 以下是两个例子: 1. Buffer b

PLSQL_性能优化系列02_Oracle Join关联

2014-09-25 BaoXinjian 一.摘要 Oracle三种主要连接方式的比较 1. Hash Join (1).概述 i. 读取一个表的资料,并将放置到内存中,并建立唯一关键字的位图索引 ii. 读取另一个表,和内存中表通过Hash算法进行比较 (2).适用对象 i. 大表连接小表 ii. 两个大表 2. Nested Loops (1).概述 i. 循环外表记录 ii. 进行逐个比对和内标的连接是否符合条件 (2).适用对象 小表驱动大表,返回较少的结果集 3. Merge Joi

PLSQL_性能优化系列05_Oracle Hint提示

2014-06-20 BaoXinjian 一.摘要 手工指定SQL语句的执行计划 尽管oracle优化器很智能,但有时候你想自己选择执行计划,可以通过hint实现.在开发测试环境中,可以通过hint测试不同执行计划的性能. Hint的缺点是增加了管理代码的额外负担,当数据库或环境发生变化时,如果不修改hint,可能导致性能下降.例如,代码中用hint指定索引,但重建索引时索引名变化. 因此oracle建议使用hint测试性能后,用其他工具来管理执行计划,如oracle 10g以后的sql tu

PLSQL_性能优化系列14_Oracle Index Anaylsis索引分析

2014-10-04 BaoXinjian 一.摘要 1. 索引质量 索引质量的高低对数据库整体性能有着直接的影响. 良好高质量的索引使得数据库性能得以数量级别的提升,而低效冗余的索引则使得数据库性能缓慢如牛,即便是使用高档的硬件配置. 因此对于索引在设计之初需要经过反复的测试与考量. 那对于已经置于生产环境中的数据库,我们也可以通过查询相关数据字典得到索引的质量的高低,通过这个分析来指导如何改善索引的性能. 2. 索引创建的基本指导原则 索引的创建应遵循精而少的原则 收集表上所有查询的各种不同

PLSQL_性能优化系列15_Oracle Index Rebuild索引重建

2014-10-04 BaoXinjian 一.摘要 索引重建是一个争论不休被不断热烈讨论的议题.当然Oracle官方也有自己的观点,我们很多DBA也是遵循这一准则来重建索引,那就是Oracle建议对于索引深度超过4级以及已删除的索引条目至少占有现有索引条目总数的20% 这2种情形下需要重建索引.近来Oracle也提出了一些与之相反的观点,就是强烈建议不要定期重建索引.本文是参考了1525787.1并进行相应描述. 1. 重建索引的理由 Oracle的B树索引随着时间的推移变得不平衡(误解) 索