Troubleshooting Oracle Error: OPatchAuto-72030 Execute in Non-Rolling Mode
When patching a multi-node Oracle Grid Infrastructure or RAC environment, the automation provided by opatchauto is usually a lifesaver. However, encountering OPatchAuto-72030 can bring your maintenance window to a grinding halt.
This error typically indicates a validation failure where the tool detects a conflict between the requested patching mode (Non-Rolling) and the current state or configuration of the cluster. Understanding the Error
The full error message usually looks like this:OPatchAuto-72030: Execute in non-rolling mode failed.
In a Non-Rolling upgrade or patch application, all nodes in the cluster are expected to be shut down or updated simultaneously. This is the opposite of Rolling mode, where nodes are patched one by one to maintain high availability. Common Causes
Node Status Inconsistency: One or more nodes are still active or have services running that prevent a global "Non-Rolling" lock.
Incorrect Flag Usage: Using the -nonrolling flag on an environment that was initially patched (or partially patched) in rolling mode.
Inventory Issues: The Central Inventory or the local oraInventory on one of the nodes is out of sync.
Resource Busy: Internal Oracle Clusterware resources are holding locks that prevent the non-rolling transition. How to Resolve OPatchAuto-72030 1. Verify the Cluster State
Before running opatchauto in non-rolling mode, ensure that the stack is prepared. While opatchauto attempts to manage the stack for you, manual interference often causes this error. Check the status: crsctl check cluster -all
If you are performing a manual non-rolling patch, ensure the stack is down on all nodes if required by the specific patch readme. 2. Check for "Half-Finished" Sessions
If a previous patching attempt failed, opatchauto might have left a session state behind. opatchauto72030 execute in nonrolling mode
Clear the session: Try running opatchauto resume to see if it can complete the previous action.
If it’s stuck, you may need to check the input.json or state files in the OPatch/auto/core directory (though modifying these is for advanced users only). 3. Validate OPatch and OPatchAuto Versions
Outdated patching tools are a leading cause of 70000-series errors.
Ensure OPatch is at the latest version recommended by My Oracle Support (MOS) for your specific Release Update (RU).
Update OPatch on all nodes in the cluster, not just the local node. 4. Use the Log Files
The console output for OPatchAuto-72030 is often vague. To find the "smoking gun," navigate to:$ORACLE_HOME/cfgtoollogs/opatchauto/
Look for the specific execution ID folder. Inside, check the opatchauto_. Search for the "FAILED" keyword just above the 72030 error code; it will usually point to a specific node or a specific system command that failed. 5. Manual Fallback
If opatchauto continues to fail in non-rolling mode, you can fall back to the manual opatch method: Stop the stack on the node.
Run opatch apply (following the patch readme instructions for manual steps). Run the necessary post-install scripts.
The OPatchAuto-72030 error is essentially a "safety catch." It triggers when the tool isn't 100% sure it can safely take down the entire cluster or apply the patch globally without risking corruption. By updating your OPatch utility and ensuring a clean cluster state, you can usually bypass this hurdle.
The error code OPATCHAUTO-72030 typically signals a logical deadlock in an Oracle administrator's day: it occurs when you attempt to run a patch in rolling mode, but the patch itself—or a specific conflict—demands a non-rolling execution. opatchauto – The patching utility
Here is a story of a late-night maintenance window where this error took center stage. The Midnight Maintenance
The clock struck 11:00 PM on a Friday. Elias, a Senior Database Administrator, sat in the glow of three monitors. His mission was simple: apply the latest Quarterly Patch Update (QPU) to a critical four-node Real Application Clusters (RAC) environment.
To minimize downtime, Elias chose the rolling mode. In his mind, he’d update Node 1 while the others stayed live, then move through the cluster like a ghost. He typed the command:./opatchauto apply /u01/app/oracle/patches/353535 -rolling The Wall of Red
The progress bar crawled to 12%. Then, the terminal spat out a wall of red text:Execution failed: OPATCHAUTO-72030: The patching cannot proceed in rolling mode.
Elias frowned. The error was blunt. It explained that certain components in this specific patch—perhaps shared Grid Infrastructure binaries or a mandatory upgrade to the clusterware stack—required the entire cluster to be down simultaneously. By trying to keep the lights on, Elias was technically trying to perform "surgery on a marathon runner while they were still mid-race."
The error was a safeguard, preventing Elias from corrupting the cluster's consistency. He had two choices: argue with the logs or follow the machine's logic.
Downtime Approval: He sent a quick alert to the stakeholders. "Rolling mode unavailable due to patch constraints. Initiating full cluster downtime."
The Shift: Once the services were drained and the instances silenced, he adjusted his strategy.
The Command: He cleared the failed session and re-ran the tool without the rolling flag:./opatchauto apply /u01/app/oracle/patches/353535 -nonrolling Resolution
The nonrolling mode took over. Instead of the delicate dance of one node at a time, opatchauto laid waste to the entire stack at once, updating the binaries across all nodes in parallel. By 1:30 AM, the terminal finally blinked a green success message.
Elias learned that while "rolling" is the dream for availability, OPATCHAUTO-72030 is the reality check that ensures the foundation of the database remains solid—even if it means a few hours of silence in the data center. binary updates | One-off fixes
To execute opatchauto in non-rolling mode for patch 72030, you would typically use the following command:
opatchauto -nonrolling -patch 72030
However, without specific context about your environment (like the Oracle database version, operating system, or current patch level), it's challenging to provide a detailed, step-by-step guide.
Here's a general text based on common practices:
opatchauto – The patching utility.execute – In older versions, opatchauto used verbs like apply, rollback, analyze. The word "execute" implies running the patching operation after analysis.in nonrolling mode – Explicit directive to take the entire cluster offline for patching.Pro Tip: Always run
opatchauto analyze -nonrollingfirst to verify that non-rolling mode is required and supported for patch 72030.
Non-rolling mode requires complete stack shutdown on all nodes.
A. Stop all databases (on any node):
srvctl stop database -d prod_db -o immediate
srvctl status database -d prod_db
B. Stop Clusterware on all nodes (as root):
# On each node, execute:
crsctl stop cluster -all
crsctl check cluster
C. Confirm no processes remain:
ps -ef | grep -E "ora_|crsd|cssd|evmd|octssd"
opatchauto apply /u01/app/stage/34774103 -nonrolling
-nonrolling explicitly forces non‑rolling mode.opatchauto may still require non‑rolling.Let’s simulate a real-world patch session.
| Feature | Non-Rolling | Rolling (if allowed) | |---------|-------------|----------------------| | Downtime | Full cluster downtime (all nodes) | Per-node brief downtime | | Risk | Lower (simultaneous change) | Higher (potential version mismatch) | | Execution Speed | Faster (parallel apply) | Slower (sequential) | | Revert Complexity | Simple (single backup restore) | Complex (per-node) | | When to Use | Major changes, binary updates | One-off fixes, PSUs |