Re: opatch auto

From: Purav Chovatia <>
Date: Thu, 14 Feb 2013 12:16:14 +0530
Message-ID: <>

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.


On Thu, Feb 14, 2013 at 12:02 PM, Hans Forbrich <>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
> --

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

Original text of this message