The process for applying a patch on top of the CRS, or now called, the Grid Infrastructure, has changed from what we used to do on 11gR1 and prior releases.
The patch I had recently applied was in order to resolve the Oracle bug “11.2.0.1 ONS CORE DUMP or High Resource Usage [ID 988795.1]”.
Database name: TEST
Instance Names: TEST1, TEST2
Grid Infrastructure Home: /u02/app/11.2.0/grid/bin (non-share home)
Grid Infrastructure Home Owner: oracle
Due to the fact that the patch doesn’t require full downtime and could be applied on a rolling basis, the plan below is to be executed on each node at time.
$ export ORACLE_HOME=/u02/app/11.2.0/grid $ export PATH=$ORACLE_HOME/bin:$ORACLE_HOME/bin:$PATH $ srvctl stop instance -d TEST -i TEST1
# cd /u02/app/11.2.0/grid/bin # ./crsctl stop crs
$ chmod u+w /u02/app/11.2.0/grid/opmn/bin/ons
Here is where the change takes place, in 11gR1 and prior releases, in order to apply a one-off patch to the Clusterware after stopping the CRS stack, the next step was to use “opatch” and apply the patch. In 11gR2, in order to patch the Grid Infrastructure, you must first unlock the Grid Infrastructure home, patch it and then relock it again. If you are applying a different patch, you must take care to read its specific README file, because you may encounter times where you will have to relink the Oracle binaries as well.
The process to unlock the Grid Home is pretty simple. As root, execute the following perl script:
# cd /u02/app/11.2.0/grid/crs/install # perl rootcrs.pl -unlock -crshome /u02/app/11.2.0/grid
$ cd /oracle/distribs/9181300 $ export ORACLE_HOME=/u02/app/11.2.0/grid $ export PATH=$ORACLE_HOME/bin:$ORACLE_HOME/OPatch:$PATH $ opatch apply -local -oh /u02/app/11.2.0/grid
$ chmod u+x /u02/app/11.2.0/grid/opmn/bin/ons
# cd /u02/app/11.2.0/grid/crs/install # perl rootcrs.pl -patch
$ opatch lsinventory
$ srvctl status database -d TEST $ srvctl start instance -d TEST -i TEST1
Ready to optimize your Oracle Database for the future?