Fwd: Multi-node patching woes

The change is documented in this note, seems also affects latest 11.2 opatch version too:
OPatch: Behavior Changes starting in OPatch 12.2.0.1.9 and 11.2.0.3.16 releases (Doc ID 2232156.1)

• Forwarded message ---------- From: Patrick Jolliffe <jolliffe_at_gmail.com> Date: 25 May 2017 at 16:24 Subject: Re: Multi-node patching woes To: oracle-l <oracle-l_at_freelists.org>

Seems changes in this area in OPatch 12.2.0.1.9. The homes are still linked, (opatch -all_nodes still applies changes to both), but this information is no longer listed in lsinventory for some reason.
I've also discovered some other changes in this area, that means my original testcase no longer reproduces.
It seems by default opatch behavior has changed to patch only local node, -all_nodes needs to be given to get original behavior. One more change is that if -all_nodes is specified, confirmation about patching remote nodes is performed before local node is patched. More details here, http://wp.me/p7tYjp-uB, if anyone is interested. P

On 25 May 2017 at 12:05, Patrick Jolliffe <jolliffe_at_gmail.com> wrote:

> Still waiting on Oracle Support for this, however I have just attempted to
> reproduce using latest version of opatch, 12.2.0.1.9 and cannot.
> This is because with 12.2.0.1.9 opatch appears to have 'lost' the
> connection between the two homes.
>
> When I execute the following (note OPatch.backup directory is the
> 12.2.0.1.8 opatch version):
> /u01/app/oracle/product/12.1.0.2/dbhome_2/OPatch.backup/opatch lsinventory
> I get the following at the end of the output:
> Rac system comprising of multiple nodes
> Local node = hkexdb01
> Remote node = hkexdb02
> When I execute the following (12.2.0.1.9 opatch version):
> /u01/app/oracle/product/12.1.0.2/dbhome_2/OPatch/opatch lsinventory
> That information is missing.
>
> Is anyone else able to check with latest and previous versions OPatch and
> see whether they also see this change in behavior?
> TIA
> Patrick
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Patrick Jolliffe <jolliffe_at_gmail.com>
> Date: 13 April 2017 at 18:01
> Subject: Multi-node patching woes
> To: oracle-l <oracle-l_at_freelists.org>
>
>
> We have two Exadata compute nodes, node1 and node2, the Oracle home on
> both nodes is RAC configured, however we are not using RAC, and actually
> expect the homes on node1 and node2 to be running different patch levels
> (and yes we now realize that this is a problem, and we are going to resolve
> this using runInstaller -updateNodeList)
>
> I have the following reproducible test case:
> 1. Initially node1 has 22652097 <2265%202097> (the (in)famous adaptive
> patch) on top of October DBBP.
> 2. Initially node2 has July DBBP only.
> 3. I apply October DBBP to node2, and choose Y when prompted, to also
> patch node1.
> 4. opatch lsinventory reveals the adaptive patch has disappeared from
> node1.
> 5. I apply the adaptive patch on node2, but chose N when prompted, to not
> patch node1.
> 6. opatch lsinventory reveals the adaptive patch still not on node1.
> 7. I apply October OJVM patch to node2, and choose Y when prompted, to
> also patch node1.
> 8. opatch lsinventory reveals the adaptive patch has re-appeared on node1
> 9. Testing reveals that the patch isn't really installed on node1 (no
> ADAPTIVE_PLANS/ADAPTIVE_STATS parameters)
>
> I kind of understand what is happening (opatch is making assumptions that
> the homes are in-sync, whereas in reality they are not).
> My question is, whether this is expected or acceptable behavior given our
> configuration?
> Ie is this worth raising as a bug, or is it our mistake in having the
> wrong setup.
> Regards
> Patrick
>
>
>
>
>
>

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