Re: opatch auto

From: Purav Chovatia <puravc_at_gmail.com>
Date: Thu, 14 Feb 2013 12:16:14 +0530
Message-ID: <CADrzpjGmiuCciWkC6xFWWVFx4CqwK7WMD+0zhc1O1_dWQorKrw_at_mail.gmail.com>

Thanks Hans.
I completely agree and hence I do always follow it the way Oracle says. My point was, I thought (and have read) that Oracle says that GI at a higher version and DB at a lower version is supported but not the other way round (pls correct me if I am wrong here). Going by that, if opatch auto applies the PSU to DB home first, then it takes the DB to a higher version with the underlying GI at a lower version and that contradicted with Oracle's guidance, and hence my question.

btw, as usual, the GI PSU in my context, does contain the DB PSU too. And I have observed the mentioned behaviour 100% of the times.

Thanks

On Thu, Feb 14, 2013 at 12:02 PM, Hans Forbrich <fuzzy.graybeard_at_gmail.com>wrote:

> On 13/02/2013 8:42 AM, Purav Chovatia wrote:
> > Hi,
> > Anybody observed, that "opatch auto" first patches the DB home and then
> the
> > GI Home. Shouldn't it be the other way round?
> >
> > Thanks
> As usual with Oracle: "It Depends".
>
> Patches MAY
> - impact current software;
> - impact current data dictionary;
> - impact dependents
>
> Just because a GI patch is released, does not mean that it directly
> impacts DBs that are involved with that GI.
>
>
> If a GI patch does impact DB, you probably want to patch the DB first,
> because you can add code to understand the new functionality as well as
> the code to keep compatibility. If you upgraded the GI first, it might
> introduce new functionality that the old DB code does not understand.
> Which would mean the DB must be down from before the GI is patched to
> after the DB is patched.
>
> Whereas patching DB first can (in theory, depending on the extent of the
> GI patch impact, and whether we use RAC or only protected single node)
> could mean the DB is down only for the DB patch, and perhaps a quick
> reboot after the GI patch.
>
>
> In fact, (bold statement here:) unless it impacts the interconnect
> (specifically the way the DB rides over the interconnect) or the disk
> (specifically the way the DB reads/writes ASM disks), I see limited
> concern about the order in which things are patched. Does that mean we
> can pick and choose the order when we do things manually? No - because
> if we happen to choose wrong in production, it is on our neck, not
> Oracle's.
>
> However, if Oracle does the patch testing correctly, they can decide
> which combination of impacts are affected.
>
> Also, since Oracle has KSplice technology, and since that technology can
> do in-place updates, I see no reason why Oracle could not do the equiv
> to KSplice to GI and DB, at least on certain platforms, thereby patching
> without ANY downtime at all. Which introduces a whole new set of
> possibilities (and a whole new set of problems).
>
>
> In conclusion: Do it the way Oracle says. If it doesn't work, we can
> complain to Support. (LOL)
>
> /Hans
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

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

Received on Thu Feb 14 2013 - 07:46:14 CET