I thought I won’t blog about this again:
But then a colleague of mine raised this simple question:
- “I have a customer that would like to change from patching using PSU to patching using Bundle Patch. I am
wondering what happens if my home has had several PSUs installed. Before applying a BP, would I need to rollback one by one all the PSUs that have been installed in reverse order (tedious) OR only the latest PSU (good)?”
Unfortunately the “simple” solution is hidden deep down in the documentation and not mentioned (as far as I could see) in any MOS Note.
The secret is the opatch option “all_subpatches“.
And this is the solution
- All PSU sub-patches have to be rolled back
- Use the -all_subpatches option – it will roll them all back in the correct sequence.
- Note: all overlay patches need rolled back at first
- Note: all overlay patches need rolled back at first
- Example:
% opatch rollback –id -all_subpatches - Documentation says:
“This option is valid ONLY for composite patches. It allows the user to rollback all sub-patches of a composite series in one shot.”
Hope this helps here and there …
–Mike
After migrate from several GI PSU to BP, datapath continue to rollback the latest GI PSU even if the previous is a BP.
For example : Patch apply history
– Apply GI PSU (July 2016)
– Migrate to BP (July 2016)
– Apply BP (Oct 2016)
– Apply BP (Jan 2017)
GI PSU (July 2016) is rollback during datapath for BP (Oct 2016) and BP (Jan 2017).
The GI PSU is not full removed from database !
–dso
Please please please … log an SR with Oracle Support.
I can’t solve all the opatch and datapatch issues getting raised here – I’m always happy to learn about them but the only thing I can do is to file a bug if something comes into my radar.
Thanks
Mike
We want to update Oracle GI from 12.1.0.2.160419 PSU (22502555) to 12.1.0.2.170117 DBBP Jan2017 on 7-node cluster node by node without whole cluster downtime, is this a possible task?
While trying the 1st node GI update by rolling PSU and applying BP, we have a problem with CRSD startup process because of OLR and OCR patchlevels are not the same anymore: CRS-6706: Oracle Clusterware Release patch level (‘4247078663’) does not match Software patch level (‘2039526626’). Oracle Clusterware cannot be started.
Problem in short looks like: on some step the node patch level record could not be updated in OCR, which results in CRSD startup errors
SR 3-14488060121 : “Clusterware fails to start on the 1st node of the cluster” got stuck without any significant results for now, despite trying both rolling and non-rolling update methods
Is there the reliable way/instruction/howto to apply Oracle GI BP instead of PSU on a multinode cluster without whole cluster downtime (i.e. node by node)?
Thanks, Igor