How to apply a patch if rootupgrade.sh / root.sh been executed partially to a GI home
(Doc ID 1980634.1)
Last updated on APRIL 12, 2024
Applies to:
Oracle Database - Enterprise Edition - Version 12.1.0.1 and laterOracle Database Cloud Schema Service - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Oracle Database Exadata Cloud Machine - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Generic Linux
Generic UNIX
Goal
During an installation or upgrade of a Grid Infrastructure (GI) home, while executing the root.sh or rootupgrade.sh from the first node, an error could be reported due to a bug and a patch is required.
If the issue is known before executing the root.sh / rootupgrade.sh, can simply apply the patch with 'opatch apply' command to lay down the patch. However, if root.sh or rootupgrade.sh has been partially run and failed, the following steps is required to overcome the issue, especially if the failure already pass the phase that init entries update is done.
Following is an example of upgrading from 11.2.0.4 to 12.1.0.2 GI home, three nodes cluster, namely lc1n1, lc1ntwo and lc1nthree.
This will encounter <Bug 19453778> due to hostname length difference, and need to apply 12.1.0.2.2 GI PSU (Jan 2015), patch number 20132450
BUG 20132450 - COMBO OF OJVM COMPONENT 12.1.0.2.2 DB PSU + GI PSU 12.1.0.2.2 (JAN2015)
This is the error reported during rootupgrade.sh on node1 (lc1n1)
Performing root user operation.
. . . . .
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Using configuration parameter file: <GI_HOME>/crs/install/crsconfig_params
2015/02/12 15:51:22 CLSRSC-4015: Performing install or upgrade action for Oracle Trace File Analyzer (TFA) Collector.
2015/02/12 15:52:32 CLSRSC-4003: Successfully patched Oracle Trace File Analyzer (TFA) Collector.
2015/02/12 15:52:43 CLSRSC-464: Starting retrieval of the cluster configuration data
2015/02/12 15:53:08 CLSRSC-465: Retrieval of the cluster configuration data has successfully completed.
2015/02/12 15:53:09 CLSRSC-363: User ignored prerequisites during installation
2015/02/12 15:53:35 CLSRSC-515: Starting OCR manual backup.
2015/02/12 15:53:40 CLSRSC-516: OCR manual backup successful.
2015/02/12 15:53:50 CLSRSC-468: Setting Oracle Clusterware and ASM to rolling migration mode
2015/02/12 15:53:50 CLSRSC-482: Running command: '<GI_HOME/bin/asmca -silent -upgradeNodeASM -nonRolling false -oldCRSHome <GI_HOME> -oldCRSVersion 11.2.0.4.0 -nodeNumber 1 -firstNode true -startRolling true'
ASM configuration upgraded in local node successfully.
2015/02/12 15:54:03 CLSRSC-469: Successfully set Oracle Clusterware and ASM to rolling migration mode
2015/02/12 15:54:03 CLSRSC-466: Starting shutdown of the current Oracle Grid Infrastructure stack
2015/02/12 15:54:54 CLSRSC-467: Shutdown of the current Oracle Grid Infrastructure stack has successfully completed.
OLR initialization - successful
2015/02/12 16:00:30 CLSRSC-329: Replacing Clusterware entries in file '/etc/inittab'
CRS-4133: Oracle High Availability Services has been stopped.
CRS-4123: Oracle High Availability Services has been started.
2015/02/12 16:05:59 CLSRSC-115: Start of resource 'ora.ctssd' failed
2015/02/12 16:05:59 CLSRSC-117: Failed to start Oracle Clusterware stack
2015/02/12 16:05:59 CLSRSC-245: Failed to start Cluster Time Synchronization Service (CTSS)
Died at <GI_HOME>/crs/install/crsupgrade.pm line 804.
The command '<GI_HOME>/perl/bin/perl -I<GI_HOME>/perl/lib -I<GI_HOME>/crs/install <GI_HOME>/crs/install/rootcrs.pl -upgrade' execution failed
Solution
To view full details, sign in with your My Oracle Support account. |
|
Don't have a My Oracle Support account? Click to get started! |
In this Document
| Goal |
| Solution |
| References |