Re: Upgrading with no patches in the "base"?

From: Rajesh Aialavajjala <r.aialavajjala_at_gmail.com>
Date: Fri, 8 Jan 2021 10:36:49 -0500
Message-ID: <CAGvtKv5zsfzu4UDZrOxoqKrY05AKYiz7=xYr2z23Q1wQZUOH3g_at_mail.gmail.com>



This (in my humble opinion) excellent post by Tim Hall - https://oracle-base.com/blog/2020/10/08/upgrades-you-have-to-do-them-when-are-you-going-to-learn-tlsv1-2/ - summarizes the reasons to NOT try to use an unpatched home. I agree - I've never heard of this "unpatched $ORACLE_HOME" strategy.

Patches (RU/RUR/CPU/PSU - a rose by any other name) exist for a reason (grin) - granted they are not always perfect (grimace) and can lead to one dealing with vendor support - in this case Oracle Support.

I would add my +1 to Mark's comment and the previous replies (of course you gentlemen hardly need my endorsement) - this does not make sense...

I don't know if there is a constraint from the application side that prohibits 19c - I recently had an upgrade project to move databases to 12.1.0.2 and when the "Why not 19c?" question was raised the reply was the application that uses the DB had a hard stop regarding compatibility at 12.1 - the prior upgrade to 12c (interpreted 12.2) had to be rolled back.

Thanks,

--Rajesh

On Fri, Jan 8, 2021 at 10:28 AM Mark J. Bobak <mark_at_bobak.net> wrote:

> "They will test this for a while, and if everything is fine, THEN they
> will apply the patch."
>
> And what if everything *isn't* fine? Then they *won't* apply the patch?
>
> Doesn't make sense.
>
> -Mark
>
> On Fri, Jan 8, 2021 at 10:19 AM Noveljic Nenad <
> nenad.noveljic_at_vontobel.com> wrote:
>
>> Hi Michael,
>>
>>
>>
>> That sounds like black magic.
>>
>>
>>
>> If “for a while” implies two different maintenance windows, you end up
>> with two test cycles and two disruptions instead of just one. If you get
>> the opportunity to combat these voodoo practitioners in front of the
>> management, the most persuasive argument would be that the database will be
>> running without security and other critical patches for a while. Who’s
>> going to take that risk?
>>
>>
>>
>> Last but not least, why not 19c?
>>
>>
>>
>> Best regards,
>>
>>
>>
>> Nenad
>>
>>
>>
>>
>>
>> *From:* oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> *On
>> Behalf Of *Michael Kline
>> *Sent:* Freitag, 8. Januar 2021 15:29
>> *To:* 'ORACLE-L' <oracle-l_at_freelists.org>
>> *Subject:* Upgrading with no patches in the "base"?
>>
>>
>>
>> Hearing that an application is going to be upgraded from 12.1 to 12.2.
>>
>>
>>
>> Vendor is saying they will create a “blank, no patched” 12.2
>> $ORACLE_HOME, and then upgrade the database.
>>
>>
>>
>> They will test this for a while, and if everything is fine, THEN they
>> will apply the patch.
>>
>>
>>
>> I’ve never heard of such a thing and have been working on Oracle
>> databases since 1983, version 4.0.
>>
>>
>>
>> Is there logic in this? We try to keep all databases at N-1 on patching.
>>
>>
>>
>>
>>
>> *Michael Kline*
>>
>>
>>
>>
>>
>>
>>
>> ____________________________________________________
>>
>> Please consider the environment before printing this e-mail.
>>
>> Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.
>>
>>
>> Important Notice
>> This message is intended only for the individual named. It may contain
>> confidential or privileged information. If you are not the named addressee
>> you should in particular not disseminate, distribute, modify or copy this
>> e-mail. Please notify the sender immediately by e-mail, if you have
>> received this message by mistake and delete it from your system.
>> Without prejudice to any contractual agreements between you and us which
>> shall prevail in any case, we take it as your authorization to correspond
>> with you by e-mail if you send us messages by e-mail. However, we reserve
>> the right not to execute orders and instructions transmitted by e-mail at
>> any time and without further explanation.
>> E-mail transmission may not be secure or error-free as information could
>> be intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also
>> processing of incoming e-mails cannot be guaranteed. All liability of
>> Vontobel Holding Ltd. and any of its affiliates (hereinafter collectively
>> referred to as "Vontobel Group") for any damages resulting from e-mail use
>> is excluded. You are advised that urgent and time sensitive messages should
>> not be sent by e-mail and if verification is required please request a
>> printed version. Please note that all e-mail communications to and from the
>> Vontobel Group are subject to electronic storage and review by Vontobel
>> Group. Unless stated to the contrary and without prejudice to any
>> contractual agreements between you and Vontobel Group which shall prevail
>> in any case, e-mail-communication is for informational purposes only and is
>> not intended as an offer or solicitation for the purchase or sale of any
>> financial instrument or as an official confirmation of any transaction.
>> The legal basis for the processing of your personal data is the
>> legitimate interest to develop a commercial relationship with you, as well
>> as your consent to forward you commercial communications. You can exercise,
>> at any time and under the terms established under current regulation, your
>> rights. If you prefer not to receive any further communications, please
>> contact your client relationship manager if you are a client of Vontobel
>> Group or notify the sender. Please note for an exact reference to the
>> affected group entity the corporate e-mail signature. For further
>> information about data privacy at Vontobel Group please consult
>> www.vontobel.com.
>>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Jan 08 2021 - 16:36:49 CET

Original text of this message