从RULE到COST的Oracle 10优化器：为什么？

Question

Oracle决定从10g版本中删除基于规则的优化器，将基于成本的优化器作为唯一选择。

我认为基于规则的优化器具有始终可预测的无价值的积极方面。我已经看到Oracle 10g日夜改变了执行计划，导致了类似乌龟的表演。

这可能是改变背后的理由？

Answer 1

因为您可以使用RBO完成所有操作{/ 1}}。

CBO也可以基于规则 - 不仅如此，您可以自己决定“规则”。

要创建自己的“规则”，您需要提示您的查询或执行CREATE OUTLINE，它会为您提示。因此，您的执行计划是稳定的。

大纲存储在名为CBO的系统架构中，它们是可编辑的。

至于我，我总是为在生产数据库中运行的查询提供提示。

Answer 2

RBO通常是可预测的坏的以及可预测的好的。它也不支持分区和其他一些数据库功能。 CBO要好得多，正如Quassnoi所说，计划稳定性也是CBO的一个特征。

Answer 3

RBO已经被弃用了很长时间;它实际上只是保留了与传统应用程序的向后兼容性。自从（IIRC）第8版（大约10年前出版）以来，甲骨文一直在宣布RBO的消亡。

RBO是确定性的，但不是那么聪明。 Oracle最初是在基于成本的优化器甚至可用之前设计的，更不用说成熟的技术了。 RBO已经被冻结了很长时间，并且不支持现代Oracle引擎的许多功能。

基于成本的优化更加智能。但是，如果您有针对RBO优化的查询，它们可能无法与CBO很好地协作。您可能需要适当地重新编写或提示您的查询，以便为CBO调整它们。还有一个工具可以指定查询计划并使用该计划覆盖CBO。这将为您提供具有稳定计划的确定性查询执行。

Answer 4

（我不是DBA。）

我的理解是，甲骨文长期以来一直是RBO的moving away支持CBO。对我来说，停止支持不再处于活动开发状态的功能（给定足够长的折旧期）似乎很有用，这样每个人都可以使用最有效的功能。

有趣的是，您将可预测性称为使用基于规则的优化器的“无价”效果。似乎当数据发生变化以使执行计划次优时，最好切换到新计划。只有在您提到两个执行计划之间的优化器触发器的位置时，才会为您实际查询的数据选择最佳计划时出现问题。我不确定在更正常的情况下有什么优势可预测性。

对过时的优化器的支持应该能够释放对更新优化器的支持。

Answer 5

他们转向基于成本的优化的原因是它可以更好地执行，因为它基于分析基于规则的优化器所没有的统计信息。

为了使CBO更好地运作，了解统计数据收集在执行计划中发挥的作用直接影响绩效的重要性非常重要。首先，或多或少地运行统计信息可以帮助您。这是一篇关于CBO和统计数据的好文章：

Optimizing Oracle Optimizer Statistics

Answer 6

我认为你应该做基于规则的编程。不要考虑这种情况，遵循一个不可侵犯的规则列表，无论情况如何，无论你认为什么是更好的方式，如果规则说在案例X中使用FOR LOOP然后你必须使用循环，即使你知道是否只有1，循环从1到1。

规定：

每个查询都有最好的计划。

每个查询优化器都会确定该计划的x％。

RBO无处可去，确切的百分比准确度低于CBO，但它永远不会变得更好。它像任何基于规则的系统一样受限制。