Step-by-Step Guide to Upgrading Oracle 19c Grid Infrastructure with the GIRU Patch

GIRU Upgrade Overview

The Oracle 19c release replaces 12c and will be the standard for upcoming database integrations; this guide documents the practical steps and issues encountered when applying the latest GIRU patch (19.7.0.0.200414) in a production environment.

1. Update OPatch Version

The GIRU patch requires OPatch 12.2.0.1.19 or newer. The guide uses the 19c‑bundled OPatch and demonstrates how to replace the OPatch binaries for both GI HOME and DB HOME.

su - grid

cd /oracle/app/19.3.0/grid/

cp /oraclelog/pa/opatch_20200622/p6880880_190000_Linux-x86-64.zip ./

mv OPatch OPatch_20200622

unzip p6880880_190000_Linux-x86-64.zip

chown -R grid:oinstall OPatch

chmod -R 775 OPatch

/oracle/app/19.3.0/grid/OPatch/opatch version

Similarly for the DB HOME:

su - oracle

cd /oracle/app/oracle/product/19.3.0/db

cp /oraclelog/pa/opatch_20200622/p6880880_190000_Linux-x86-64.zip ./

mv OPatch OPatch_20200622

unzip p6880880_190000_Linux-x86-64.zip

/u01/app/oracle/product/12.2.0.1/dbhome_1/OPatch/opatch version

2. Backup Directories

Before applying the patch, back up the app and oraInventory directories to provide a rollback point if the upgrade fails.

ps -ef|grep LOCAL=NO|awk '{print $2}'|xargs kill -9

srvctl stop instance -d racdb -n racdb1

su - root

/oracle/app/19.3.0/grid/bin/crsctl stop crs

/oracle/app/19.3.0/grid/bin/crsctl stat res -t

tar -cvf /oraclelog/pa/opatch_20200622/gi_home_`hostname`_20200622.tar /oracle/app

tar -cvf /oraclelog/pa/opatch_20200622/oraInventory_`hostname`_20200622.tar /oracle/app/oraInventory

The backup requires stopping the database and CRS to avoid corrupted files, a lesson learned from a previous 11g GI PSU upgrade.

3. Start CRS for Conflict Analysis

After the backup, start CRS (without starting the database) to run the OPatch conflict‑check utilities.

/oracle/app/19.3.0/grid/bin/crsctl start crs

/oracle/app/19.3.0/grid/bin/crsctl stat res -t

tail -100f /oracle/app/grid/diag/crs/*/crs/trace/alert*.log

Run the detailed conflict checks as both grid and oracle users:

su - grid

opatch prereq CheckConflictAgainstOHWithDetail –phBaseDir /oraclelog/pa/opatch_20200622/30899722/30869156

... (similar commands for other directories) ...

Starting CRS without the database gives administrators control over session kills and checkpoints, preventing automatic shutdowns that could prolong the upgrade.

4. Apply the Patch

With conflicts resolved, apply the GIRU patch:

su - root

cd /oraclelog/shsnc/opatch_20200622/30899722

/oracle/app/19.3.0/grid/OPatch/opatchauto apply /oraclelog/shsnc/opatch_20200622/30899722

5. Data Dictionary Update and Verification

After patching all nodes, restart the instances and run datapatch to update the data dictionary, then verify the installation.

su - oracle

cd $ORACLE_HOME/OPatch

./datapatch -verbose

./opatch lsinventory

sqlplus / as sysdba

set line 300 pages 100

col ACTION_TIME for a30

col DESCRIPTION for a60

select PATCH_ID, FLAGS, ACTION, STATUS, INSTALL_ID, ACTION_TIME, DESCRIPTION from DBA_REGISTRY_SQLPATCH order by ACTION_TIME;

Problem Summary

Issue 1: Patch failed in GI HOME with “oui‑patch.xml permission denied”. The file lacked write permission for the grid group. Granting 664 permissions to the newly created oui‑patch.xml allowed the patch to succeed.

Issue 2: After a successful patch, CRS on node 1 reported missing Jackson‑related JAR files. The files are part of optional future features; the error can be ignored after confirming cluster health.

Conclusion

Patch upgrades in production GI environments inevitably surface undocumented bugs; systematic backups, controlled CRS starts, and prompt permission fixes are essential to complete the upgrade safely. The described workflow provides a reproducible method for Oracle 19c GI GIRU patching.