I am now exploring the brand new Grid Infrastructure patching method for Exadata Cloud at Customer. With Exadata Cloud at Customer version 18.1.4.4, it is now possible to patch Grid Infrastructure with a few clicks in the GUI. Let’s see exactly which steps are performed.
First, with my preferred method (CLI 🙂 ), I run opatch against Grid Infrastructure home to check the current patch level :
28656071;OCW RELEASE UPDATE 18.4.0.0.0 (28656071)
28655963;DBWLM RELEASE UPDATE 18.4.0.0.0 (28655963)
28655916;ACFS RELEASE UPDATE 18.4.0.0.0 (28655916)
28655784;Database Release Update : 18.4.0.0.181016 (28655784)
28547619;TOMCAT RELEASE UPDATE 18.0.0.0.0 (28547619)
Since the GUI now shows when a new patch is available for Grid Infrastructure, there is a new Exadata Grid section with a precheck option in its burger menu :
After clicking, the precheck is launched :
After 7 minutes, the procedure is completed successfully :
Cool !
What is actually going on ?
In directory /var/opt/oracle/log/exadbcpatch/, there is a file named exadbcpatch.log . This file contains interesting steps performed by the whole precheck procedure. For readability reasons, I shrunk the snippets of log to the bare minimum.
- A directory is created to receive the patch itself :
2019-03-07 15:28:27.397035 - Output from cmd mkdir -p /u02/exapatch/grid; chmod -R 0775 /u02/exapatch/grid run on localhost is:
[...]
opatch lspatchesis performed against Grid Infrastructure home :
2019-03-07 15:28:28.326997 - Output from cmd /u01/app/18.1.0.0/grid/OPatch/opatch lspatches run on localhost is:
2019-03-07 15:28:30.468677 - 28656071;OCW RELEASE UPDATE 18.4.0.0.0 (28656071)
28655963;DBWLM RELEASE UPDATE 18.4.0.0.0 (28655963)
28655916;ACFS RELEASE UPDATE 18.4.0.0.0 (28655916)
28655784;Database Release Update : 18.4.0.0.181016 (28655784)
28547619;TOMCAT RELEASE UPDATE 18.0.0.0.0 (28547619)
OPatch succeeded.
[...]
INFO: existing patch version for gi_home: 18.4.0.0.0
2019-03-07 15:28:30.473903 - INFO: patching_progress here is : 0
2019-03-07 15:28:30.474064 - INFO: OH being checked for patchid : /u01/app/18.1.0.0/grid
2019-03-07 15:28:30.474191 - INFO: patchnum being checked : 28828717
On the last line, we can see that the patch being checked is 28828717, which is GI RELEASE UPDATE 18.5.0.0.0 .
- A zip file with a familiar name is retrieved from Object Storage 🙂 :
2019-03-07 15:28:34.188433 - Output from cmd mkdir -p /u02/exapatch/grid; cd /u02/exapatch/grid; curl -O --retry-delay 2 --retry 10 https://{my_domain...}/dbaas_patch/exadata_jan2019/p6880880_122010_Linux-x86-64.zip run on localhost is:
[...]
Yeay ! It looks like the update of opatch is part of the procedure !
- Of course, opatch is updated :
2019-03-07 15:28:35.313341 - Output from cmd cd /u01/app/18.1.0.0/grid; rm -rf OPatch.ORG; mv OPatch OPatch.ORG; unzip -o /u02/exapatch/grid/p6880880_122010_Linux-x86-64.zip;
[...]
- The Grid Infrastructure patch 28828717 is retrieved from Object Storage and unzipped in the directory created during the first step of the procedure :
2019-03-07 15:28:38.785442 - Output from cmd mkdir -p /u02/exapatch/grid/28828717; cd /u02/exapatch/grid/28828717; curl -O --retry-delay 2 --retry 10 https://{my_domain...}/dbaas_patch/exadata_jan2019/p28828717_180000_Linux-x86-64.zip run on localhost is:
[...]
2019-03-07 15:28:57.011384 - Output from cmd cd /u02/exapatch/grid/28828717; unzip -o p28828717_180000_Linux-x86-64.zip;
[...]
- Opatch version is now checked :
2019-03-07 15:29:35.504141 - Output from cmd /u01/app/18.1.0.0/grid/OPatch/opatch version run on localhost is:
2019-03-07 15:29:35.873857 - OPatch Version: 12.2.0.1.16
It is also checked on the other node, and because it is obsolete, opatch is copied from the first node with scp.
- Finally, opatchauto is launched with
-analyze
(Here is what opatchauto apply -help says about analyze : If this option is selected, the environment will be analysed for suitability of the patch on each home, without affecting the home. The patch will not be applied or rolled back, and targets will not be shut down.)
2019-03-07 15:29:41.991750 - Output from cmd /u01/app/18.1.0.0/grid/OPatch/opatchauto apply -inplace -analyze -ocmrf /var/opt/oracle/exapatch/ocm.rsp -oh /u01/app/18.1.0.0/grid /u02/exapatch/grid/28828717/28828717 2>&1 > /u02/exapatch/grid/28828717/28828717/conflictlog run on localhost is:
[...]
2019-03-07 15:30:36.040017 - INFO: BP num is : 28828717
[...]
2019-03-07 15:30:36.078727 - INFO: prereq check phase is completed
2019-03-07 15:30:36.078892 - INFO: ready for patch apply
2019-03-07 15:30:36.079214 - INFO: Completed prereq_check
[...]
2019-03-07 15:30:36.288720 - ##### INFO: Exadbcpatch completed successfully #####
File /u02/exapatch/grid/28828717/28828717/conflictlog contains a regular opatch output and this file is analyzed to make sure the precheck is OK.
The next step is to actually patch the Grid Infrastructure. When I’ll launch the actual patch, I’ll check if /u02/exapatch/grid is cleaned because of one of the reason that can make the precheck fail is if filesystem /u02 is full. Unfortunately, for the moment, the GUI only shows that an error occured without details.
EDIT : When patching Grid Infrastructure (please see this blog post), directory /u02/exapatch is indeed cleaned, as you can see in the log file when the patch procedure is running :
2019-03-27 16:03:52.219332 - INFO: Deleting /u02/exapatch
2019-03-27 16:03:52.219629 - Output from cmd rm -rf /u02/exapatch run on localhost is:
This procedure is really convenient and easy. It is a relief not to have to find the right patch number and the right version of opatch.
Pingback: Exadata Cloud at Customer : Grid Infrastructure patch under the hood – Floo Bar