Re: opatch auto
- From: Purav Chovatia <puravc@xxxxxxxxx>
- To: fuzzy.graybeard@xxxxxxxxx
- Date: Thu, 14 Feb 2013 12:16:14 +0530
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@xxxxxxxxx>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
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
