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

I can see it making sense from an application vendor perspective. I'd be extremely reluctant to certify against RU1, RU2, RU3, RU4, RU5, etc - especially as I suspect a number of customers would actually end up with RU2 + One-Off 123. . Instead, I'd certify and then support the major version.
In that world as a customer of the application vendor the original approach makes sense as follows:

1. Validate that my application vendor has done due diligence and it really works in my environment via a full regression test, This verifies that I've configured the app properly as well.
2. Patch in line with security recommendations and do minimal functional testing.

Not many people live in a world like that, especially as line 2 probably then needs repeating every 3-6 months.

On Fri, Jan 8, 2021 at 3:36 PM Frits Hoogland <frits.hoogland_at_gmail.com> wrote:

> the only way the visit to the unpatched version makes sense, is when the
> intention is to never leave that version. which doesn’t make sense in
> today’s world.
> there is no sensible, logical other way in which using the unpatched
> version otherwise makes sense with the given information.
>
> Frits Hoogland
>
> http://fritshoogland.wordpress.com
> frits.hoogland_at_gmail.com
> Mobile: +31 6 14180860
>
> On 8 Jan 2021, at 16:27, 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.
>>
>
>

-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info

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