I was performing a spot health check in a client environment, when I encountered this:
[[email protected] ~]$ crsctl query crs releaseversion Oracle High Availability Services release version on the local node is [12.1.0.2.0] [[email protected] ~]$ crsctl query crs activeversion -f Oracle Clusterware active version on the cluster is [12.1.0.2.0]. The cluster upgrade state is [ROLLING PATCH]. The cluster active patch level is [26717470].
By checking over the applied patches on the three nodes, I found they matched:
[email protected] > kfod op=patches List of Patches =============== 20243804 20415006 20594149 20788771 20950328 21125181 21359749 21436941 21527488 21694919 21949015 22806133 23144544 24007012 24340679 24732088 24846605 25397136 25869760 26392164 26392192 26609798 26717470 [email protected] > kfod op=patches List of Patches =============== 20243804 20415006 20594149 20788771 20950328 21125181 21359749 21436941 21527488 21694919 21949015 22806133 23144544 24007012 24340679 24732088 24846605 25397136 25869760 26392164 26392192 26609798 26717470 [email protected] > kfod op=patches List of Patches =============== 20243804 20415006 20594149 20788771 20950328 21125181 21359749 21436941 21527488 21694919 21949015 22806133 23144544 24007012 24340679 24732088 24846605 25397136 25869760 26392164 26392192 26609798 26717470
It was most likely a patch completed incorrectly, however checking on the dba_registry and dba_registry_sqlpatch, everything looked valid and successfully applied.
Based on that assessment, here is the quick fix I applied:
$GI_HOME/bin/clscfg -patch $GI_HOME/bin/crsctl stop rollingpatch
Once done, the issue was fixed!
I hope this helps you. If you have any questions, or thoughts, please leave them in the comments.
2 Comments. Leave new
Hi,
Does the solution require an ASM or CRS restart?
Thanks,
hi Lhot, no these steps as mentioned in post does not require restarts!