RE: Optimizer change from 8i-9i

Also, at some release _undo_optimizer_changes was deprecated, so even though
the RBO code had stopped changing, you could no longer switch it between the
"paleolithic" behavior and the "jurassic" behavior. As to exactly what the
difference was, I'm afraid I'd have to reference dormant gray cells that
would be annoyed at getting wakened. That the change in question was
catastrophic to certain prehistoric Oracle Applications releases I am
certain of; the newer RBO across that change made some dirty trick hand
tweaked batch job queries go to hell in a hand cart for a long stay.
Needless to say, the Apps division couldn't instantly repair them all.

Far more likely is changing in tie breaker order from the timestamps, as
Christian has mentioned. And if the last time _undo_optimizer_changes worked
was pre-7.3, then this whole message is a no-op.

Regards,

mwf

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Christian Antognini
Sent: Monday, May 09, 2005 12:30 PM
To: zhuchao@xxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: RE: Optimizer change from 8i-9i



>>1. For SQLs using RBO, the plan for the existing SQL won''t change,
>>right? As oracle says no change for RBO since oracle 7.3.
>
>Wrong. You could see some differences.

Let me precise this point...=20

There are two reasons that lead to different execution plans with the =
RBO:
1) Differences in the optimizer itself.
2) The indexes of the new database are not created in the same order as =
the indexes of the old one.

--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l

Other related posts: