Before you patch anything, you always have to upgrade the tool that we use to patch : opatch by downloading the last opatch version in the well known patch 6880880. Then you will upgrade opatch on every node of a cluster (up to 8 on Exadata) for every ORACLE_HOME you want to patch.
Hopefully, Exadata comes out with a powerful tool named dcli (you will find the dcli detailed syntax here) which can really ease your Exadata DBA ("DMA" like they call it) life.
I will be showing here how to quickly upgrade opatch with dcli. This example has been performed on a full rack -- then 8 nodes. I'll be presenting here a 12c opatch upgrade; it is the exact same procedure for a 11g opatch upgrade.
1/ Prerequisites
- SSH passwordless connectivity set (as you want to patch an Exadata, we can assume that it is already done, if not, you can check in this post how to set SSH passwordless connectivity with dcli).
- A text file containing the list of the nodes of the cluster, here it is /tmp/dbs_group
- The opatch archive containing the latest version; I put it in /patches/opatch/p6880880_122010_Linux-x86-64.zip in my example
2/ Check the current opatch version
myclusterdb01:oracle:\) dcli -g /tmp/dbs_group -l oracle /u01/app/oracle/product/12.1.0.2/dbhome_1/OPatch/opatch version myclusterdb01: OPatch Version: 12.1.0.1.8 myclusterdb01: myclusterdb01: OPatch succeeded. myclusterdb02: OPatch Version: 12.1.0.1.8 myclusterdb02: myclusterdb02: OPatch succeeded. myclusterdb03: OPatch Version: 12.1.0.1.8 myclusterdb03: myclusterdb03: OPatch succeeded. myclusterdb04: OPatch Version: 12.1.0.1.8 myclusterdb04: myclusterdb04: OPatch succeeded. myclusterdb05: OPatch Version: 12.1.0.1.8 myclusterdb05: myclusterdb05: OPatch succeeded. myclusterdb06: OPatch Version: 12.1.0.1.8 myclusterdb06: myclusterdb06: OPatch succeeded. myclusterdb07: OPatch Version: 12.1.0.1.8 myclusterdb07: myclusterdb07: OPatch succeeded. myclusterdb08: OPatch Version: 12.1.0.1.8 myclusterdb08: myclusterdb08: OPatch succeeded. myclusterdb01:oracle:\)This is not bad but let's add a "| grep Version" at the end of this command line to only have the opatch version as we are not interested in the other information returned :
myclusterdb01:oracle:\) dcli -g /tmp/dbs_group -l oracle /u01/app/oracle/product/12.1.0.2/dbhome_1/OPatch/opatch version | grep Version myclusterdb01: OPatch Version: 12.1.0.1.8 myclusterdb02: OPatch Version: 12.1.0.1.8 myclusterdb03: OPatch Version: 12.1.0.1.8 myclusterdb04: OPatch Version: 12.1.0.1.8 myclusterdb05: OPatch Version: 12.1.0.1.8 myclusterdb06: OPatch Version: 12.1.0.1.8 myclusterdb07: OPatch Version: 12.1.0.1.8 myclusterdb08: OPatch Version: 12.1.0.1.8 myclusterdb01:oracle:\)Better, isn't it ?
3/ Copy the opatch archive
myclusterdb01:oracle:\) dcli -g /tmp/dbs_group -l oracle -f /patches/opatch/p6880880_122010_Linux-x86-64.zip -d /tmp myclusterdb01:oracle:\)
4/ Upgrade opatch
myclusterdb01:oracle:\) dcli -g /tmp/dbs_group -l oracle "unzip -o /tmp/p6880880_122010_Linux-x86-64.zip -d /u01/app/oracle/product/12.1.0.2/dbhome_1; /u01/app/oracle/product/12.1.0.2/dbhome_1/OPatch/opatch version; rm /tmp/p6880880_122010_Linux-x86-64.zip" | grep Version myclusterdb01: OPatch Version: 12.2.0.1.7 myclusterdb02: OPatch Version: 12.2.0.1.7 myclusterdb03: OPatch Version: 12.2.0.1.7 myclusterdb04: OPatch Version: 12.2.0.1.7 myclusterdb05: OPatch Version: 12.2.0.1.7 myclusterdb06: OPatch Version: 12.2.0.1.7 myclusterdb07: OPatch Version: 12.2.0.1.7 myclusterdb08: OPatch Version: 12.2.0.1.7 myclusterdb01:oracle:\)Awesome, isn't it ? thanks dcli !
Just FYI. Recently faced issue because of this while trying 12.1 Oct 2020 GI, then removed the OPatch folder completely and unzipped again which fixed the issue. Ref Doc-2283767.1 - Case-3. But, as usual your blog helped me a lot during my Exadata work. Thanks a ton.
ReplyDelete