Oracle 10 optimizer from RULE to COST: why?

Question

Oracle decided to dismiss the rule-based optimizer from version 10g, leaving the cost-based one as the only choice.

I think that a rule-based optimizer has the unv

Answer 1

(I am not a DBA.)

My understanding is that Oracle has been moving away from the RBO for a long time in favor of CBO. It seems useful to me to stop supporting a feature that is no longer in active development (given a long enough depreciation period) so that everyone is using the most effective features.

It's interesting that you called predictability an "unvaluable" effect of using the rule-based optimizer. It seems like when the data changes to make an execution plan sub-optimal it would be best to switch to a new one. Only in the case you alluded to where the optimizer flip-flops between two execution plan would there be a problem with picking the best plan for the the data you are actually querying. I'm not sure what advantage predictability is in more normal situation.

Ending support of the out-dated optimizer ought to free up support for the newer optimizer.

Answer 2

The RBO is often predicatably bad as well as predictably good. It also doesn't support partitioning and some other database features. The CBO is much better, and as Quassnoi says plan stability is a feature of the CBO also.

Answer 3

The reason they moved to cost-based optimization is that it can perform better since its based on analyzing statistical information that the rule-based optimizer does not have.

To make the CBO work better, its important to understand the role that statistics gathering plays in execution plan changes which directly affect performance. For one thing, running statistics more or less frequently could help you. Here is a good article about the CBO and statistics:

Optimizing Oracle Optimizer Statistics

Answer 4

Because everything you can do with RBO, can be done with CBO.

The CBO can be rule based too — more than that, you may decide the "rules" yourself.

To create your own "rules", you hint your query or do a CREATE OUTLINE which will hint it for you. As a result, you execution plan is stable.

The outlines are stored in a system schema called OUTLN, they are editable.

As for me, I always supply hints to my queries running in a production database.

Answer 5

The RBO has been deprecated for a long time; it was really just retained for backwards compatibility with legacy applications. Oracle have been announcing the demise of the RBO since (IIRC) version 8, which came out about 10 years ago.

The RBO was deterministic, but not all that clever. Oracle was originally designed before cost-based optimisers were even available, let alone a mature technology. The RBO has been frozen for a long time and does not support a lot of features of modern Oracle engines.

Cost-based optimisation is much smarter. However, if you had queries optimised for the RBO, they might not play nicely with the CBO. You will probably have to re-write or hint your queries appropriately to tune them for the CBO. There is also a facility to specify a query plan and override the CBO with that plan. This will give you deterministic query execution with stable plans.

Answer 6

I think you should do rule based programming. Don't think about the situation, follow a list of inviolate rules, no matter what the situation, no matter what you think is the better way, if the rules say use a FOR LOOP in case X then you have to use a loop, even if you know if there will only be 1, loop from 1 to 1.

Stipulate:

Every query has a best plan.

Every query optimizer will determine that plan x% of the time.

The RBO had nowhere else to go, it's percent accuracy is lower than the CBO to be sure, but it was never going to get any better. It was limited like any rule based system.