Re: 12.1 Optimizer feature stability

On an upgrade, I always reset the parameters to all defaults unless you know you need to address a specific requirement such as Peoplesoft or EBS.

Doing it this way gives you a chance to get back to default characteristics and eliminate technical debt that people likely can’t prove the need to be there anyway.

Also, don’t let the App team dictate how to set it up unless they can prove the need. The worst reason ever is “that’s the way it’s always been”.

Shane Borden
sborden76_at_yahoo.com
Sent from my iPhone

> On Jan 11, 2021, at 4:57 AM, Pap <oracle.developer35_at_gmail.com> wrote:
>
> 
> Hello All, We are moving from version 11.2.0.4 to version12.1.0.2.0 of Oracle. We can't go to the latest versions(like 19C/18C) because of certain application dependencies which are running on this database. Team is suggesting to keep the optimizer_feature_enable as it was for existing version i.e. 11.2.0.4, as because there are issues/bugs for version 12.1.0.2.0.
>
> So I wanted to check with experts here , if it's really so and have such a bad experience with OFE- 12.1.0.2.0 and we must keep the optimizer feature at 11.2.0.4 even if the database version would be 12.1.0.2?
>
> For information, We do use a lot of Global temporary tables in our application code, but then we are thinking these will get the benefit of the private session level stats on OFE- 12.1 and it won't happen such if we keep the OFE at 11.2. Even if we don't change the code to gather stats on the GTT immediately during migration , then that will still keep on using dynamic sampling(in absence of session level stats) as it used to happen on version 11.2. And gradually we will change our code to gather session level stats in application code where estimation is going bad impacting execution path.
>
> Regards
> Pap
>

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