基于规则的查询，数据库根据表和索引等定义信息，按照一定的规则来产生执行计划；基于代价的查询，数据库根据搜集的表和索引的数据的统计信息（通过analyze 命令或者使用dbms_stats包来搜集）综合来决定选取一个数据库认为最优的执行计划（实际上不一定最优）。RULE是基于规则的，CHOOSE表示假如查询的表存在搜集的统计信息则基于代价来执行(在CHOOSE模式下ORACLE采用的是 FIRST_ROWS)，否则基于规则来执行。在基于代价的两种方式中，FIRST_ROWS指执行计划采用最少资源尽快的返回部分结果给客户端，对于排序分页页显示这种查询尤其适用，ALL_ROWS指以总体消耗资源最少的方式返回结果给客户端。
基于规则的模式下，数据库的执行计划通常比较稳定。但在基于代价的模式下，我们才有更大的机会选择最优的执行计划。也由于ORACLE的很多查询方面的特性必须在基于代价的模式下才能体现出来，所以我们通常不选择RULE(并且ORACLE宣称从 ORACLE 10i版本数据库开始将不再支持 RULE)。既然是基于代价的模式，也就是说执行计划的选择是根据表、索引等定义和数据的统计信息来决定的，这个统计信息是根据 analyze 命令或者dbms_stats包来定期搜集的。首先存在着一种可能，就是由于搜集信息是一个很消耗资源和时间的动作，尤其当表数据量很大的时候，因为搜集信息是对整个表数据进行重新的完全统计，所以这是我们必须慎重考虑的问题。我们只能在服务器空闲的时候定期的进行信息搜集。这说明我们在一段时期内，统计信息可能和数据库本身的数据并不吻合；另外就是ORACLE的统计数据本身也存在着不精确部分（具体参考ORACLE DOCUMENT），更重要的一个问题就是及时统计数据相对已经比较准确，但是ORACLE的优化器的选择也并不是始终是最优的方案。这也倚赖于ORACLE对不同执行计划的代价的计算规则（我们通常是无法知道具体的计算规则的）。这好比我们决定从香港还是从北京去英国，车票、机票等实际价格到底是怎么核算出来的我们并不知道，或者说我们现在了解的价格信息，在我们乘车前往的时候，真实价格跟我们的预算已经发生了变化。所有的因素，都将影响我们的整个开销。
执行计划稳定性能带给我们什么
ORACLE存在着执行计划选择失误的可能。这也是我们经常遇见的一些现象，比如总有人说我的程序在测试数据库中跑的很好，但在产品数据库上就是跑的很差，甚至后者硬件条件比前者还好，这到底是为什么？硬件资源、统计信息、参数设置都可能对执行计划产生影响。由于因素太多，我们总是对未来怀着一种莫名的惧怕，我的产品数据库上线后到底跑的好不好？于是ORACLE提供了一种稳定执行计划的能力，也就是把在测试环境中的运行良好的执行计划所产生的OUTLINES移植到产品数据库，使得执行计划不会随着其他因素的变化而变化。
那么OUTLINES是什么呢？先要介绍一个内容，ORACLE提供了在SQL中使用HINTS来引导优化器产生我们想要的执行计划的能力。这在多表连接、复杂查询中非凡有效。HINTS的类型很多，可以设置优化器目标(RULE、CHOOSE、FIRST_ROWS、ALL_ROWS)，可以指定表连接的顺序，可以指定使用哪个表的哪个索引等等，可以对SQL进行很多精细的控制。通过这种方式产生我们想要的执行计划的这些HINTS,ORACLE可以存储这些HINTS，我们称之为OUTLINES。通过STORE OUTLINES可以使得我们拥有以后产生相同执行计划的能力，也就是使我们拥有了稳定执行计划的能力。
这里想给出一个附加的说明就是，实际上，我们通过工具改写SQL，比如使用SQL EXPERT改写后的SQL，这些不仅仅是加了HINTS而且文本都已经发生了变化的SQL，也可以存储OUTLINES，并可被应用到应用中。但这不是一定生效，我们必须测试检查是否生效。但由于就算给了错误的OUTLINES,数据库在执行的时候，也只是忽略过去重新生成执行计划而不会返回错误，所以我们才敢放心的这么使用。当然在ORACLE文档中并没有指明可以这样做，文档中只是说明，假如存在OUTLINES的同时又在SQL中加了HINTS，则会使用OUTLINES而忽略HINTS。这个功能在LECCO将发布的产品中会使用这一功能，这样可以将SQL EXPERT的改写SQL的能力和稳定执行计划的能力结合起来，那么我们就对不能更改源代码的应用具有了相当强大的SQL优化能力。
评论加载中…
 |