Re: Things to consider during upgrade/migration

  • From: Lok P <loknath.73@xxxxxxxxx>
  • To: "Clay Jackson (cjackson)" <Clay.Jackson@xxxxxxxxx>, Andy Sayer <andysayer@xxxxxxxxx>, Mladen Gogala <gogala.mladen@xxxxxxxxx>
  • Date: Sun, 14 Nov 2021 22:45:49 +0530

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

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?



Other related posts: