SYMPTOMS
After patching manually on the 12.2 Grid Infrastructure home, the rootcrs.sh -postpatch fails with:
2017-11-19 16:29:27: Oracle CRS stack has been shut down
2017-11-19 16:29:27: The stack was already down before stopping it
2017-11-19 16:29:27: Starting CRS without resources...
2017-11-19 16:29:27: OHASD needs to be up for disabling CRS resource
2017-11-19 16:29:27: Executing cmd: /u01/app/12.2.0.1/grid/bin/crsctl start crs -noautostart
2017-11-19 16:29:27: Command output:
> CRS-6706: Oracle Clusterware Release patch level ('748994161') does not match Software patch level ('0'). Oracle Clusterware cannot be started.
> CRS-4000: Command Start failed, or completed with errors.
2017-11-19 16:29:27: The stack was already down before stopping it
2017-11-19 16:29:27: Starting CRS without resources...
2017-11-19 16:29:27: OHASD needs to be up for disabling CRS resource
2017-11-19 16:29:27: Executing cmd: /u01/app/12.2.0.1/grid/bin/crsctl start crs -noautostart
2017-11-19 16:29:27: Command output:
> CRS-6706: Oracle Clusterware Release patch level ('748994161') does not match Software patch level ('0'). Oracle Clusterware cannot be started.
> CRS-4000: Command Start failed, or completed with errors.
CHANGES
In earlier Grid Infrastructure releases, the following options were available for manual patching:
A. In 12.1.0.x, these two commands are used with opatchauto (opatchauto will run these commands) or with manual patching with opatch or opatchauto to unlock and lock the home for patching. The -prepatch requires that the CRS be
running on both nodes. The -postpatch requires that the -prepatch was run successfully.
rootcrs.sh -prepatch
rootcrs.sh -postpatch
running on both nodes. The -postpatch requires that the -prepatch was run successfully.
rootcrs.sh -prepatch
rootcrs.sh -postpatch
B. These two commands are from previous releases of GI <12.1, although they could still be used in 12.1. The -unlock command does not require CRS be running. The -patch command does not require that unlock
was run successfully. So these two commands could work around issues with patching. This is no longer the same case in 12.2 as the -patch option no longer exists.
rootcrs.sh -unlock
rootcrs.sh -patch
was run successfully. So these two commands could work around issues with patching. This is no longer the same case in 12.2 as the -patch option no longer exists.
rootcrs.sh -unlock
rootcrs.sh -patch
In 12.2, users must use rootcrs.sh -prepatch and rootcrs.sh -postpatch for manual patching.
CAUSE
This issue was caused by rootcrs.sh -prepatch not run successfully before patching. The user ran rootcrs.sh -unlock because rootcrs.sh -prepatch failed, and then applied the patch manually.
SOLUTION
Please use the following steps to complete the patching:
1. Run the following command as the root user to complete the patching set up behind the scenes:
#GI_HOME/bin:> ./clscfg -localpatch
#GI_HOME/bin:> ./clscfg -localpatch
2. Run the following command as the root user to lock the GI home:
#GI_HOME/crs/install:> ./rootcrs.sh -lock
#GI_HOME/crs/install:> ./rootcrs.sh -lock
3. Run the following command as the root user to start the GI:
#GI_HOME/bin:> ./crsctl start crs
#GI_HOME/bin:> ./crsctl start crs
No comments:
Post a Comment