RE: Things to consider during upgrade/migration

  • From: "Mark W. Farnham" <mwf@xxxxxxxx>
  • To: <niall.litchfield@xxxxxxxxx>, <loknath.73@xxxxxxxxx>
  • Date: Fri, 19 Nov 2021 10:00:33 -0500



In my opinion the purpose of the comprehensive baselines collection is not to 
use them upon conversion, but rather to use them as an aid in curing any case 
by case regressions as indicated by Niall in his message below. A repository of 
the baselines is your time machine to see what the better performing plan used 
to be, which is especially important when the “old” machine and software 
combination is no longer available.


IF this is the headcount 9 actively used plan baselines case I recall, then 
trying those 9 with and without a baseline on the new environment should be 
illuminating. But even if all 9 become relatively stellar, you may indeed have 
plan regressions where the “what did it do before the conversion” will likely 
be a shortcut to solution.




PS: I took your request for minimal changes to performance to mean to avoid 
changes to the worse. In a case many years ago involving a time sharing bureau 
I was thoroughly scolded: They needed a process to be more reasonable to 
placate the customer, but the select before sorting fix I put in caused the a 
99% resource reduction in the job that had been 80% of the monthly bill. The 
customer was pleased, but the time sharing bureau was quite unhappy. I presume 
you actually want things at least as fast and don’t mind faster.


From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of niall.litchfield@xxxxxxxxx
Sent: Friday, November 19, 2021 7:29 AM
To: loknath.73@xxxxxxxxx
Cc: Clay Jackson (cjackson); Andy Sayer; Mladen Gogala; Oracle L
Subject: Re: Things to consider during upgrade/migration


Hi Lok, 


I suspect the answer to this probably lies in your corporate appetite for risk 
and the reasons for the upgrade. The original question was "How do I upgrade or 
migrate with minimal changes to performance?". Andy has covered this (I might 
have added set OFE to the source version as well). The approach of capturing 
baselines for the application workload and using them is great for predictable 
performance and is really useful as Andy says for finding SQL statements that 
might need attention. This enables you to minimize the amount of performance 
work done at upgrade time. 


However, if you are moving from 11.2 to 19c (~ten years of development), and 
especially if you are moving platform as well you may well want *not* to 
maintain performance as it was, but to take advantage of the various 
enhancements that come with later versions of the database, to do that you will 
need to allow the database to use the CBO as intended by Oracle and then fix 
regressions on a case by case basis. You'd likely end up with a better 
performing application, but with a higher risk and a greater testing 
requirement. Given the amount of change that you are intending to undertake, I 
suspect that this would actually be a better approach.   


On Sun, Nov 14, 2021 at 5:16 PM Lok P <loknath.73@xxxxxxxxx> wrote:

Thank you so much Andy, Clay and Mladen.


If I got it right, with respect to gathering system statistics in Exadata mode, 
we should not do it unless justified/tested. And table and dictionary stats 
should be treated in the same way as it is there in older version 


With regards to capturing sql plan baselines for all sqls. I have some doubts. 
We already have optimizer_use_sql_plan_baselines set as TRUE in our database. 
So, are you suggesting to alter the optimizer_capture_sql_plan_baselines to 
TRUE ,  2-3days prior upgrade which will ensure our full application workload 
runs at least 2-3 times before upgrade so that all the baseline will be 
captured without missing any sql. And then at the same time we will turn 
optimizer_use_sql_plan_baselines as False, so that those will not be used 
automatically by the queries until we manually evolve and accept it. And post 
upgrade if any sql misbehaves we will scan the captured baselines and set that 
enabled for that sql only. Is this what you are suggesting?

Btw in the above approach, I see some issues as , we currently have 
optimizer_use_sql_plan_baselines set as TRUE which is default. And we are 
already having some baselines and sql profiles for few of the critical sqls , 
so we can not turn that off for doing a bulk sql baseline capture for upgrade. 
So is there any workaround for this? In our case if we just want to capture the 
baselines but we want to keep control of evolving and applying the plan with us 
i.e manually but not by oracle automatically,  how to do that? Is it possible 
without setting the optimizer_use_sql_plan_baseline false? As I tested, it 
attaches the baseline to the SQL by default and that way we will have all our 
SQL queries have the baseline attached at the end of the capture process. We 
normally avoid SQL profile, baselines, hints and only want to go for it in real 
need. And after upgrading we just want to attach a baseline if any SQL behaves 
badly and we have to go for a quick fix and we will do that manually. Can you 
please guide me here?




On Sun, Nov 14, 2021 at 3:06 AM Clay Jackson (cjackson) 
<Clay.Jackson@xxxxxxxxx> wrote:

What Mladen and Andy said – I would pay very serious attention to their wisdom; 
born of many years 😊. ESPECIALLY the parts about

1.      How different 19 is from 11 and the Exadata is from the HP
2.      Collecting baselines for ALL SQL – the time you spend up from will save 
more than that troubleshooting on the “back end”


In my position, I talk to customers/prospects going through similar 
upgrades/migrations and those who follow(ed) Steps 2 and 3 (and understood the 
differences) had SIGNIFICANTLY better success than those who tried to 
“shortcut” the process.


Clay Jackson



From: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> On Behalf 
Of Lok P
Sent: Saturday, November 13, 2021 10:47 AM
To: Oracle L <oracle-l@xxxxxxxxxxxxx>
Subject: Things to consider during upgrade/migration


CAUTION: This email originated from outside of the organization. Do not follow 
guidance, click links, or open attachments unless you recognize the sender and 
know the content is safe.


Hello Listers, With respect to having a safe upgrade(say from 11.2 to 19C) or 
migration(From HP to Exadata) experience with minimal performance issues. Is 
there any guideline we should follow like setting up exadata system stats in 
case the target database is going to be exadata, Or verifying dictionary 
stats/table stats etc in a certain way. Want to know experts' views, if there 
are any such guidelines? 





Niall Litchfield
Oracle DBA

Other related posts: