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_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Christian Antognini Sent: Monday, May 09, 2005 12:30 PM
To: zhuchao_at_gmail.com
Cc: oracle-l_at_freelists.org
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