Patching Oracle Grid Infrastructure is a critical maintenance task, but every experienced DBA knows one golden rule: always have a rollback plan. Even well-tested patches can introduce unexpected issues such as application incompatibilities, performance regressions, or service startup failures.
In this guide, we walk through a real-world rollback of Oracle Grid Infrastructure 19.30 using OPatchAuto, based on an actual production-style rollback session. This article explains when rollback is required, how OPatchAuto safely reverts GI patches, and how to validate the environment after rollback.
How to Patch Oracle 19c Grid Infrastructure Restart Home to 19.30 (GI RU 38629535)
When Should You Roll Back a GI Patch?
Rolling back an Oracle GI patch is typically required when:
- CRS resources fail to start correctly after patching
- ASM or listener services behave unexpectedly
- Application or database connectivity issues appear
- Vendor or application certification issues are discovered
- Oracle Support recommends rollback during troubleshooting
Oracle strongly recommends using OPatchAuto for both patching and rollback, as it safely manages CRS shutdown and startup without manual intervention.
Environment Overview
- Oracle Version: Oracle Grid Infrastructure 19c
- Patch Version: 19.30 (GI RU bundle 38629535)
- Grid Home:
/u01/app/19c/grid - Patch Location:
/home/oracle/patch/38629535 - Patch Method: OPatchAuto
- Environment Type: Oracle Restart (Single Node GI)
- OS: Linux x86-64
Important Rollback Prerequisites
Before starting the rollback:
- Ensure no patching sessions are currently running
- Verify OPatchAuto version is compatible
- Confirm sufficient disk space for rollback operations
- Run rollback as root user
- Do not manually stop CRS—OPatchAuto handles this safely
Step 1: Execute OPatchAuto Rollback Command
The rollback was initiated using the following command:
/u01/app/19c/grid/OPatch/opatchauto rollback /home/oracle/patch/38629535 -oh /u01/app/19c/grid
This command instructs OPatchAuto to rollback all patches applied from the bundle directory against the specified Grid Home.
Step 2: OPatchAuto Session Initialization
Once started, OPatchAuto initializes the rollback session:
OPatchauto session is initiated at Wed Jan 21 06:00:49 2026
Key logs generated during this phase:
- System initialization log
- OPatchAuto session log
- Unique session ID for traceability
This ensures every rollback action is fully auditable.
Step 3: Patch Applicability and Validation Checks
Before touching the Oracle Home, OPatchAuto performs safety checks:
Executing OPatch prereq operations to verify patch applicability
Patch applicability verified successfully
Then validation checks confirm:
Patch validation checks successfully completed
✅ This step prevents partial or unsupported rollback operations.
Step 4: CRS Shutdown (Handled Automatically)
One of the biggest advantages of OPatchAuto is automatic CRS management.
Performing prepatch operations on CRS - bringing down CRS service
CRS service brought down successfully
OPatchAuto safely stops all Grid Infrastructure services, ensuring:
- No corruption
- No orphan processes
- Clean rollback execution
This is significantly safer than manual CRS shutdown.
Step 5: Rolling Back GI Binary Patches
Once CRS is stopped, OPatchAuto begins the rollback of GI binaries:
Start rolling back binary patch on home /u01/app/19c/grid
Binary patch rolled back successfully
At this stage, all Grid Infrastructure binaries patched by the 19.39 RU are reverted to their previous state.
Step 6: Root Script Execution
After binary rollback, OPatchAuto executes required root scripts:
Running rootadd_rdbms.sh on home /u01/app/19c/grid
Successfully executed rootadd_rdbms.sh
This step ensures:
- Correct permissions
- Proper relinking
- System-level consistency
Skipping this step manually can leave the GI home in an inconsistent state—OPatchAuto prevents that risk.
Step 7: CRS Startup After Rollback
Once rollback tasks are complete, CRS services are restarted automatically:
Performing postpatch operations on CRS - starting CRS service
CRS service started successfully
This confirms that the cluster stack comes up cleanly after rollback.
Step 8: Rollback Summary Analysis
At the end of the session, OPatchAuto provides a detailed summary:
Skipped Patch
Patch 36758186 skipped
Reason: Not applied as part of bundle patch 38629535
This is expected behavior and not an error.
Successfully Rolled Back Patches
The following patches were rolled back successfully:
- 38661284 – OCW Release Update
- 38653268 – ACFS Release Update
- 38729293 – Tomcat Release Update
- 38632161 – Database Release Update 19.39
Each patch rollback is logged individually for troubleshooting and audit purposes.
Rollback Completion Status
OPatchauto session completed successfully
Time taken: 10 minutes, 50 seconds
🎯 This confirms a clean and complete rollback of the GI 19.39 patch bundle.
Post-Rollback Validation (Highly Recommended)
After rollback, DBAs should always verify system health:
crsctl check has
crsctl stat res -t
opatch lspatches
These checks confirm:
- CRS is running
- ASM and Listener are stable
- No partial patches remain
- Inventory reflects rolled-back state
Best Practices for GI Patch Rollback
- Always rollback using OPatchAuto, not OPatch
- Never interrupt a rollback session
- Review OPatchAuto logs carefully
- Validate CRS and inventory post-rollback
- Document rollback timelines and reasons
Final Thoughts
Rolling back Oracle Grid Infrastructure 19.30 (Patch 38629535) using OPatchAuto is a safe, structured, and Oracle-supported process. As demonstrated, OPatchAuto handles CRS shutdown, binary rollback, root script execution, and service restart automatically—greatly reducing DBA risk.
Every patching strategy should include a tested rollback procedure. With OPatchAuto, Oracle provides DBAs a reliable safety net when patching does not go as planned.
