绑定变量在OLTP环境下,被广泛的使用;这源于OLTP的特点和sql语句的执行过程,OLTP典型的事务短,类似的sql语句执行率高,并发大;oracle在执行sql语句前会对sql语句进行hash运算,将得到的hash值和share pool中的library cache中对比,如果未命中,则这条sql语句需要执行硬解析,如果命中,则只需要进行软解析;硬解析的执行过程是先进行语义,语法分析,然后生成执行计划,最后执行sql语句,在OLTP系统中使用绑定变量可以很好的解决这个问题!

一:oltp环境下,使用绑定变量和不使用绑定变量对比
1:创建测试数据

  1. [oracle@dg53 ~]$ sqlplus hr/hr
  2. SQL*Plus: Release 10.2.0.1.0 - Production on Thu Jun 14 16:54:46 2012
  3. Copyright (c) 1982, 2005, Oracle.  All rights reserved.
  4. Connected to:
  5. Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
  6. With the Partitioning, OLAP and Data Mining options
  7. SQL> create table t1 as select object_id,object_name from dba_objects;
  8. Table created.
  9. SQL> create index i_t1 on t1(object_id);
  10. Index created.
  11. SQL> exec dbms_stats.gather_table_stats('HR','T1',CASCADE=>TRUE);
  12. PL/SQL procedure successfully completed.

2:不使用绑定变量情况下,进行sql trace分析,执行1万次,需要硬解析10003次,其中包含递归解析,解析时间为19.37s,cpu消耗为17.62

  1. SQL> alter session set tracefile_identifier='HR01';
  2. Session altered.
  3. SQL> alter session set sql_trace=TRUE;
  4. Session altered.
  5. SQL> begin
  6. 2  for i in 1..10000
  7. 3  loop
  8. 4  execute immediate 'select * from t1 where object_id='||i;
  9. 5  end loop;
  10. 6* end;
  11. PL/SQL procedure successfully completed.
  12. SQL> alter session set sql_trace=FALSE;
  13. Session altered.
  14. OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
  15. call     count       cpu    elapsed       disk      query    current        rows
  16. ------- ------  -------- ---------- ---------- ---------- ----------  ----------
  17. Parse    10003     17.62      19.37          0          0          0           0
  18. Execute  10003      0.48       0.54          0          0          0           0
  19. Fetch        7      0.00       0.01          1         13          0           4
  20. ------- ------  -------- ---------- ---------- ---------- ----------  ----------
  21. total    20013     18.10      19.92          1         13          0           4
  22. Misses in library cache during parse: 10000
  23. 10003  user  SQL statements in session.
  24. 3  internal SQL statements in session.
  25. 10006  SQL statements in session.
  26. 0  statements EXPLAINed in this session.
  27. ********************************************************************************
  28. Trace file: dg53_ora_24818_HR01.trc
  29. Trace file compatibility: 10.01.00
  30. Sort options: default
  31. 0  session in tracefile.
  32. 10003  user  SQL statements in trace file.
  33. 3  internal SQL statements in trace file.
  34. 10006  SQL statements in trace file.
  35. 10006  unique SQL statements in trace file.
  36. 80071  lines in trace file.
  37. 78  elapsed seconds in trace file.

3:使用绑定变量情况下,进行sql trace分析,执行1万次,只需要硬解析5次,其中包含递归解析,解析时间和cpu时间基本忽略不计

  1. SQL> alter session set tracefile_identifier='HR02';
  2. Session altered.
  3. SQL> alter session set sql_trace=TRUE;
  4. Session altered.
  5. SQL> begin
  6. 2  for i in 1..10000
  7. 3  loop
  8. 4  execute immediate 'select * from t1 where object_id=:i' using i;
  9. 5  end loop;
  10. 6  end;
  11. PL/SQL procedure successfully completed.
  12. SQL> alter session set sql_trace=FALSE;
  13. Session altered.
  14. OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
  15. call     count       cpu    elapsed       disk      query    current        rows
  16. ------- ------  -------- ---------- ---------- ---------- ----------  ----------
  17. Parse        5      0.00       0.00          0          0          0           0
  18. Execute  10004      0.10       0.09          0          0          0           0
  19. Fetch       10      0.00       0.01          0         29          0           7
  20. ------- ------  -------- ---------- ---------- ---------- ----------  ----------
  21. total    10019      0.10       0.10          0         29          0           7
  22. Misses in library cache during parse: 2
  23. Misses in library cache during execute: 1
  24. 4  user  SQL statements in session.
  25. 4  internal SQL statements in session.
  26. 8  SQL statements in session.
  27. 0  statements EXPLAINed in this session.
  28. ********************************************************************************
  29. Trace file: dg53_ora_24818_HR02.trc
  30. Trace file compatibility: 10.01.00
  31. Sort options: default
  32. 0  session in tracefile.
  33. 4  user  SQL statements in trace file.
  34. 4  internal SQL statements in trace file.
  35. 8  SQL statements in trace file.
  36. 8  unique SQL statements in trace file.
  37. 10078  lines in trace file.
  38. 91  elapsed seconds in trace file.

二:使用绑定变量有如此好的效果,那么这是不是百利无一害的技术手段呢?下面在OLAP环境下测试
1:创建测试数据,olap环境下分区的技术非常普遍,且数据量非常大

  1. [root@dg53 ~]# su - oracle
  2. [oracle@dg53 ~]$ sqlplus /nolog
  3. SQL*Plus: Release 10.2.0.1.0 - Production on Fri Jun 15 09:05:35 2012
  4. Copyright (c) 1982, 2005, Oracle.  All rights reserved.
  5. SQL> conn /as sysdba
  6. Connected.
  7. SQL> create tablespace data01;
  8. Tablespace created.
  9. SQL> create tablespace data02;
  10. Tablespace created.
  11. SQL> create tablespace data03;
  12. Tablespace created.
  13. SQL> create tablespace data04;
  14. Tablespace created.
  15. SQL> conn hr/hr
  16. Connected.
  17. SQL> create table t2 (object_id number,object_name varchar2(200))
  18. 2  partition by range(object_id)
  19. 3  (partition p1 values less than(5000) tablespace data01,
  20. 4   partition p2 values less than(10000) tablespace data02,
  21. 5   partition p3 values less than(15000) tablespace data03,
  22. 6*  partition pm values less than(maxvalue) tablespace data04)
  23. Table created.
  24. SQL> begin
  25. 2  for i in 1..300
  26. 3  loop
  27. 4  insert into t2 select object_id,object_name from dba_objects;
  28. 5  end loop;
  29. 6  end;
  30. PL/SQL procedure successfully completed.
  31. SQL> commit;
  32. Commit complete.
  33. SQL> create index i_t_id on t2(object_id) local
  34. 2  (partition p1 tablespace data01,
  35. 3   partition p2 tablespace data02,
  36. 4   partition p3 tablespace data03,
  37. 5   partition pm tablespace data04);
  38. Index created.
  39. SQL> exec dbms_stats.gather_table_stats('HR','T2',CASCADE=>TRUE);
  40. PL/SQL procedure successfully completed.
  41. SQL> select count(*) from t2 partition(p1);
  42. COUNT(*)
  43. ----------
  44. 1474800
  45. SQL> select count(*) from t2 partition(p2);
  46. COUNT(*)
  47. ----------
  48. 1398900
  49. SQL> select count(*) from t2 partition(p3);
  50. COUNT(*)
  51. ----------
  52. 1491900
  53. SQL> select count(*) from t2 partition(pm);
  54. COUNT(*)
  55. ----------
  56. 10752600

2:查询object_id落在1-5999之间的数据,查看执行计划,这里选择了全表扫描为最优的执行计划

  1. SQL> set autot traceonly
  2. SQL> select  object_id,count(*) from t2 where object_id between  1  and 5999 group by object_id;
  3. 5807 rows selected.
  4. Execution Plan
  5. ----------------------------------------------------------
  6. Plan hash value: 1765100474
  7. -------------------------------------------------------------------------------------------------
  8. | Id  | Operation                | Name | Rows  | Bytes | Cost (%CPU)| Time| Pstart| Pstop |
  9. -------------------------------------------------------------------------------------------------
  10. |   0 | SELECT STATEMENT         |      |  5484 | 27420 |  2650  (12)| 00:00:32|       |       |
  11. |   1 |  PARTITION RANGE ITERATOR|      |  5484 | 27420 |  2650  (12)| 00:00:32|     1 |     2 |
  12. |   2 |   HASH GROUP BY          |      |  5484 | 27420 |  2650  (12)| 00:00:32|       |       |
  13. |*  3 |    TABLE ACCESS FULL     | T2   |  1639K|  8005K|  2432   (4)| 00:00:30|     1 |     2 |
  14. -------------------------------------------------------------------------------------------------
  15. Predicate Information (identified by operation id):
  16. ---------------------------------------------------
  17. 3 - filter("OBJECT_ID"<=5999 AND "OBJECT_ID">=1)
  18. Statistics
  19. ----------------------------------------------------------
  20. 1  recursive calls
  21. 0  db block gets
  22. 10772  consistent gets
  23. 10643  physical reads
  24. 0  redo size
  25. 101752  bytes sent via SQL*Net to client
  26. 4642  bytes received via SQL*Net from client
  27. 389  SQL*Net roundtrips to/from client
  28. 0  sorts (memory)
  29. 0  sorts (disk)
  30. 5807  rows processed

3:查询object_id落在1000-15000之间的数据,查看执行计划,这里选择了索引访问扫描为最优的执行计划

  1. SQL> select object_id,count(*) from t2 where object_id between 1000 and 15000 group by object_id;
  2. 13600 rows selected.
  3. Execution Plan
  4. ----------------------------------------------------------
  5. Plan hash value: 3236792548
  6. ------------------------------------------------------------------------------------------------
  7. | Id  | Operation             | Name   | Rows  | Bytes | Cost (%CPU)| Time     |Pstart| Pstop |
  8. ------------------------------------------------------------------------------------------------
  9. |   0 | SELECT STATEMENT      |        | 12869 | 64345 |  8731   (2)| 00:01:45 ||       |
  10. |   1 |  PARTITION RANGE ALL  |        | 12869 | 64345 |  8731   (2)| 00:01:45 |1 |     4 |
  11. |   2 |   SORT GROUP BY NOSORT|        | 12869 | 64345 |  8731   (2)| 00:01:45 ||       |
  12. |*  3 |    INDEX RANGE SCAN   | I_T_ID |  3847K|    18M|  8731   (2)| 00:01:45 |1 |     4 |
  13. ------------------------------------------------------------------------------------------------
  14. Predicate Information (identified by operation id):
  15. ---------------------------------------------------
  16. 3 - access("OBJECT_ID">=1000 AND "OBJECT_ID"<=15000)
  17. filter("OBJECT_ID"<=15000 AND "OBJECT_ID">=1000)
  18. Statistics
  19. ----------------------------------------------------------
  20. 1  recursive calls
  21. 0  db block gets
  22. 9655  consistent gets
  23. 8115  physical reads
  24. 0  redo size
  25. 242794  bytes sent via SQL*Net to client
  26. 10351  bytes received via SQL*Net from client
  27. 908  SQL*Net roundtrips to/from client
  28. 0  sorts (memory)
  29. 0  sorts (disk)
  30. 13600  rows processed

结论:由此可见,使用绑定变量应该尽量保证使用绑定变量的sql语句执行计划应当相同,否则将造成问题,因而绑定变量不适用于OLAP环境中!

三:在前面的测试中,1-5999之间的查询,为什么不选择分区范围扫描?1000-5000之间的查询,为什么不选择全表扫描,使用索引,不会产生无谓的2次I/O吗?要了解这些,就要开启数据库的10053时间,分析cbo如何选择执行计划?

1:分析1-5999之间查询的10053事件

  1. SQL> alter session set tracefile_identifier='HR03';
  2. Session altered.
  3. SQL> alter session set events '10053 trace name context forever,level 1';
  4. Session altered.
  5. SQL> select  object_id,count(*) from t2 where object_id between  1  and 5999 group by object_id;
  6. 5807 rows selected.
  7. SQL> alter session set events '10053 trace name context off';
  8. Session altered.

trace文件关键内容:

***************************************
Column Usage Monitoring is ON: tracking level = 1
***************************************
****************
QUERY BLOCK TEXT
****************
select  object_id,count(*) from t2 where object_id between  1  and 5999 group by object_id
*********************
QUERY BLOCK SIGNATURE
*********************
qb name was generated
signature (optimizer): qb_name=SEL$1 nbfros=1 flg=0
  fro(0): flg=0 objn=54910 hint_alias="T2"@"SEL$1"
*****************************
SYSTEM STATISTICS INFORMATION
*****************************
  Using NOWORKLOAD Stats
  CPUSPEED: 587 millions instruction/sec
  IOTFRSPEED: 4096 bytes per millisecond (default is 4096)
  IOSEEKTIM: 10 milliseconds (default is 10)
***************************************
BASE STATISTICAL INFORMATION
***********************
Table Stats::
  Table: T2  Alias: T2  (Using composite stats)
  (making adjustments for partition skews)
  ORIGINAL VALUES::    #Rows: 15078669  #Blks:  71051  AvgRowLen:  28.00
  PARTITIONS::
  PRUNED: 2
  ANALYZED: 2  UNANALYZED: 0
    #Rows: 15078669  #Blks:  10756  AvgRowLen:  28.00
Index Stats::
  Index: I_T_ID  Col#: 1
    USING COMPOSITE STATS
    LVLS: 2  #LB: 33742  #DK: 50440  LB/K: 1.00  DB/K: 303.00  CLUF: 15299802.00
  Column (#1): OBJECT_ID(NUMBER)
    AvgLen: 5.00 NDV: 50440 Nulls: 0 Density: 1.9826e-05 Min: 33 Max: 54914
***************************************
SINGLE TABLE ACCESS PATH
  Table: T2  Alias: T2
    Card: Original: 15078669  Rounded: 1639470  Computed: 1639469.86  Non Adjusted: 1639469.86
  Access Path: TableScan
    Cost:  2432.43  Resp: 2432.43  Degree: 0
      Cost_io: 2355.00  Cost_cpu: 545542277
      Resp_io: 2355.00  Resp_cpu: 545542277
  Access Path: index (index (FFS))
    Index: I_T_ID
    resc_io: 7383.00  resc_cpu: 2924443977
    ix_sel: 0.0000e+00  ix_sel_with_filters: 1
  Access Path: index (FFS)
    Cost:  7798.09  Resp: 7798.09  Degree: 1
      Cost_io: 7383.00  Cost_cpu: 2924443977
      Resp_io: 7383.00  Resp_cpu: 2924443977
  Access Path: index (IndexOnly)
    Index: I_T_ID
    resc_io: 3671.00  resc_cpu: 358846806
    ix_sel: 0.10873  ix_sel_with_filters: 0.10873
    Cost: 3721.93  Resp: 3721.93  Degree: 1
  Best:: AccessPath: TableScan
         Cost: 2432.43  Degree: 1  Resp: 2432.43  Card: 1639469.86  Bytes: 0
Grouping column cardinality [ OBJECT_ID]    5484 

2:分析1000-5000之间查询的10053事件

  1. SQL> alter session set tracefile_identifier='HR04';
  2. Session altered.
  3. SQL> alter session set events '10053 trace name context forever,level 1';
  4. Session altered.
  5. SQL> select object_id,count(*) from t2 where object_id between 1000 and 15000 group by object_id;
  6. 13600 rows selected.
  7. SQL> alter session set events '10053 trace name context off';
  8. Session altered.

trace文件关键内容:

 ***************************************
Column Usage Monitoring is ON: tracking level = 1
***************************************
****************
QUERY BLOCK TEXT
****************
select object_id,count(*) from t2 where object_id between 1000 and 15000 group by object_id
*********************
QUERY BLOCK SIGNATURE
*********************
qb name was generated
signature (optimizer): qb_name=SEL$1 nbfros=1 flg=0
  fro(0): flg=0 objn=54910 hint_alias="T2"@"SEL$1"
*****************************
SYSTEM STATISTICS INFORMATION
*****************************
  Using NOWORKLOAD Stats
  CPUSPEED: 587 millions instruction/sec
  IOTFRSPEED: 4096 bytes per millisecond (default is 4096)
  IOSEEKTIM: 10 milliseconds (default is 10)
***************************************
BASE STATISTICAL INFORMATION
***********************
Table Stats::
  Table: T2  Alias: T2  (Using composite stats)
    #Rows: 15078669  #Blks:  71051  AvgRowLen:  28.00
Index Stats::
  Index: I_T_ID  Col#: 1
    USING COMPOSITE STATS
    LVLS: 2  #LB: 33742  #DK: 50440  LB/K: 1.00  DB/K: 303.00  CLUF: 15299802.00
  Column (#1): OBJECT_ID(NUMBER)
    AvgLen: 5.00 NDV: 50440 Nulls: 0 Density: 1.9826e-05 Min: 33 Max: 54914
***************************************
SINGLE TABLE ACCESS PATH
  Table: T2  Alias: T2
    Card: Original: 15078669  Rounded: 3847127  Computed: 3847127.03  Non Adjusted: 3847127.03
  Access Path: TableScan
    Cost:  16073.05  Resp: 16073.05  Degree: 0
      Cost_io: 15544.00  Cost_cpu: 3727344901
      Resp_io: 15544.00  Resp_cpu: 3727344901
  Access Path: index (index (FFS))
    Index: I_T_ID
    resc_io: 7383.00  resc_cpu: 3049910030
    ix_sel: 0.0000e+00  ix_sel_with_filters: 1
  Access Path: index (FFS)
    Cost:  7815.89  Resp: 7815.89  Degree: 1
      Cost_io: 7383.00  Cost_cpu: 3049910030
      Resp_io: 7383.00  Resp_cpu: 3049910030
  Access Path: index (IndexOnly)
    Index: I_T_ID
    resc_io: 8611.00  resc_cpu: 842035120
    ix_sel: 0.25514  ix_sel_with_filters: 0.25514
    Cost: 8730.52  Resp: 8730.52  Degree: 1
  Best:: AccessPath: IndexFFS  Index: I_T_ID
         Cost: 7815.89  Degree: 1  Resp: 7815.89  Card: 3847127.03  Bytes: 0
Grouping column cardinality [ OBJECT_ID]    12869
***************************************

本文以《让oracle跑的更快》为指导,如有雷同,不胜荣幸!

本文转自斩月博客51CTO博客,原文链接http://blog.51cto.com/ylw6006/899353如需转载请自行联系原作者

ylw6006

浅谈Oracle绑定变量相关推荐

  1. 浅谈oracle树状结构层级查询

    oracle树状结构查询即层次递归查询,是sql语句经常用到的,在实际开发中组织结构实现及其层次化实现功能也是经常遇到的,虽然我是一个java程序开发者,我一直觉得只要精通数据库那么对于java开发你 ...

  2. oracle hash join outer,CSS_浅谈Oracle中的三种Join方法,基本概念 Nested loop join: Outer - phpStudy...

    浅谈Oracle中的三种Join方法 基本概念 Nested loop join: Outer table中的每一行与inner table中的相应记录join,类似一个嵌套的循环. Sort mer ...

  3. Oracle 绑定变量 详解 .

    之前整理过一篇有关绑定变量的文章,不太详细,重新补充一下. Oracle 绑定变量 http://blog.csdn.net/tianlesoftware/archive/2009/10/17/467 ...

  4. Linux先发送条件变量,浅谈Linux条件变量的使用

    Linux线程同步之间存在多种机制,条件变量是一种类似操作系统里提到的生产者-消费者算法的同步机制,允许线程以无竞争的方式等待特定条件的发生. 示例伪代码: void* Thread1(void){ ...

  5. java绑定变量怎么加_在JAVA 源程序中编写SQL语句时使用ORACLE 绑定变量

    在JAVA中的SQL 语句的编写方面,没有使用ORACLE 绑定变量,很大程度上降低了数据库的性能,表现在两个方面: 1.SQL语句硬分析(Hard Parse)太多,严重消耗CPU资源,延长了SQL ...

  6. Linux先发送条件变量,linux 条件变量 浅谈Linux条件变量的使用

    想了解浅谈Linux条件变量的使用的相关内容吗,在本文为您仔细讲解linux 条件变量的相关知识和一些Code实例,欢迎阅读和指正,我们先划重点:linux,条件变量,下面大家一起来学习吧. Linu ...

  7. Oracle绑定变量分级(Bind Graduation)

    Oracle绑定变量分级(Bind Graduation) 绑定变量分级(Bind Graduation)是指Oracle在PL/SQL代码中会根据文本型绑定变量的定义长度而将这些文本型绑定变量分为四 ...

  8. 浅谈Oracle RAC --集群管理软件GI

    浅谈Oracle RAC --集群管理软件GI基本架构 今天周五,想想可以过周末,心情大好.一周中最喜欢过的就是周五晚上,最不喜欢过的是周日晚上和周一,看来我不是个热爱劳动的人啊.趁着现在心情愉悦,赶 ...

  9. 浅谈oracle树状结构层级查询测试数据

    浅谈oracle树状结构层级查询 oracle树状结构查询即层次递归查询,是sql语句经常用到的,在实际开发中组织结构实现及其层次化实现功能也是经常遇到的,虽然我是一个java程序开发者,我一直觉得只 ...

最新文章

  1. (0054)iOS开发之制作静态库详解
  2. 6、图书类别修改删除功能
  3. ListView下拉刷新、上拉载入更多之封装改进
  4. pyqt控件显示重叠_Python编程:一个不错的基于PyQt的Led控件显示库,建议收藏学习...
  5. 112. 路径总和 golang
  6. sdp ddp内存怎么分_旗舰手机跑分66万+,缩短与PC差距,手机成生产力工具也许不是梦...
  7. Python之Pandas库
  8. python读取大文件太慢_强悍的Python读取大文件的解决方案
  9. 使用Python进行多项式Lo​​gistic回归
  10. JS前端加密JAVA后端解密详解
  11. 一次 HashSet 所引起的并发问题 1
  12. 华为P6-C00电信版,刷机总是失败? FAIL
  13. c语言信息管理系统 分析,C语言图书信息管理系统教程分析.doc
  14. 软件测试的六大测试质量标准
  15. Nacos 服务治理(服务注册中心)
  16. 山东理工oj答案java_山东理工大学ACM程序设计竞赛-山东理工ACM主页.DOC
  17. 8大成功的网络营销案例 互联网营销案例分析
  18. sql server 2008 不显示 已注册的服务器任务窗格,Visio使用方法.doc
  19. M システム - 笔记(4) -- 客户合作胜过合同谈判
  20. 人脸识别: 人脸数据集大全

热门文章

  1. Android Studio eclipse 调试技巧
  2. mysql字段冲突报错
  3. oracle dba create view 失败 解决办法
  4. Js 对象添加属性
  5. 使用SqlDependency监测数据库
  6. 几个不错的开源的.net界面控件[转贴]
  7. 5.Springcloud的Ribbon组件的集成及实现轮询负载均衡方式
  8. JUnit5 Maven 依赖项
  9. MySQL基础2——表的约束
  10. windows oracle 宕机,windows上的oracle一次宕机恢复