ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列2

【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列2

原创 Linux操作系统 作者:bisal 时间:2013-09-07 20:58:00 0 删除 编辑

下面来谈一谈系列1中讲到的Literal SQL和Shared SQL的比较。


首先是Literal SQL:

在有完整的统计信息并且SQL语句在predicate(限定条件)中使用具体值时,基于成本的优化器 (CBO)能工作的最好。比较下面

的语句:

SELECT distinct cust_ref FROM orders WHERE total_cost < 10000.0;

SELECT distinct cust_ref FROM orders WHERE total_cost < :bindA;

对于第一个语句,CBO可以使用已经收集的histogram来判断是否使用全表扫描比使用TOTAL_COST列上索引扫描快(假设有索

引的话)。第二个语句CBO并不知道绑定变量":bindA"对应行数的比例,因为该绑定变量没有一个具体的值以确定执行计划

例:":bindA" 可以是 0.0或者99999999999999999.9。

Orders表上两个不同的执行路径的响应时间可能会不同,所以当你需要CBO为你选出最好的执行计划的时候,选用使用literal语句

会更好。在一个典型的Decision Support Systems(决策支持系统)中,重复执行'标准'语句的时候非常少,所以共享一个语句的

几率很小,而且花在Parse上的CPU时间只占每个语句执行时间的非常小一部分,所以更重要的是给optimizer尽可能详细的信

息,而不是缩短解析时间。 

这里补充一下,这要说的其实是绑定变量窥探对执行计划的影响,绑定变量窥探只在第一次SQL执行硬解析时才会建立,即使后

面数据量有了明显的改变,但仍旧使用原来的执行计划,这就可能产生查询效率的问题,所以绑定变量不是任何时候都会起到好

的作用,需要具体问题具体分析。


Shared SQL:

如果应用使用了literal (无共享) SQL,则会严重限制可扩展性和生产能力。在对CPU的需求、library cache和shared pool latch的

获取和释放次数方面,新SQL语句的parse成本很高。(补充:因为之前说过,这里会有latch持有的等待。)

比如:仅仅parse一个简单的语句就可能需要获取和释放library cache latch 20或者30次。

除非它是一个临时的或者不常用的SQL,并且需要让CBO得到尽可能多的信息来生成一个好的执行计划,否则最好让所有的SQL

是共享的。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/7192724/viewspace-772345/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
Oracle ACE,10g/11g OCP,11g OCM,国内首批Oracle YEP成员(Oracle Young Expert Program,Oracle用户组年轻专家项目),EXIN DevOps Master,Oracle爱好者,微信公众号:bisal的个人杂货铺

注册时间:2013-07-26

  • 博文量
    340
  • 访问量
    2622678