In the quiet hum of the data center, Senior DBA Alex stared at a flickering terminal. A critical security patch was overdue, and the automated orchestration tool, opatchauto , had just thrown a roadblock. OPATCHAUTO-72030: Execute in non-rolling mode ," the screen flashed in unforgiving text.

Alex knew the drill. Usually, patching was a "rolling" affair—a graceful relay race where one node in the cluster goes down for maintenance while the others carry the workload. But this patch was different. It touched the very heart of the shared Grid Infrastructure (GI) Home

. Because the cluster software lived in a shared location, it was impossible to have one node running the old version while another tried to apply the new. The cluster couldn't be "half-patched".

The "exclusive" nature of this error meant there was no middle ground. To move forward, the cluster's heartbeat had to stop entirely.

"We’re going dark," Alex announced to the monitoring team. Following the standard protocol , Alex began the transition to non-rolling mode The Shutdown

: One by one, the remote nodes were silenced. For a non-rolling session to even begin, every other node in the cluster had to be completely stopped. The Command : Alex typed the manual override: opatchauto apply -nonrolling The Exclusive Phase : With the -nonrolling opatchauto

took exclusive control. It stopped the local stack, applied the binary changes to the shared home, and prepared the system for a synchronized rebirth.

The terminal scrolled with progress bars. The shared home was updated in one swift, parallel stroke across the environment. When the final "Success" message appeared, Alex initiated the startup. The entire cluster rose at once, unified under the new patch level.

The 72030 error wasn't a failure; it was a safeguard, ensuring that in the world of high-stakes databases, the cluster never tried to walk before it was whole again. -nonrolling troubleshooting checklist for this specific error? Non-Rolling upgrade in RAC using opatchauto - Oracle Forums

The error OPATCHAUTO-72030 typically occurs when you attempt to patch a Shared Grid Infrastructure (GI) Home in "rolling" mode. Because a shared home resides on a shared file system (like ACFS or OCFS2), binaries cannot be updated node-by-node while other nodes are still running from that same home.

The "nonrolling mode exclusive" execution is the standard requirement for these environments to ensure the shared binaries are modified while the entire stack is down. 1. Error Breakdown: Why OPATCHAUTO-72030 Happens

Trigger: You likely ran opatchauto apply without specifying a mode. By default, opatchauto tries to use rolling mode.

The Conflict: Rolling mode requires shutting down one node, patching it, and bringing it back up while other nodes stay live. In a shared home, you cannot "patch" only one node's binaries because all nodes share the same physical files.

The Message: "Cannot execute in rolling mode, as CRS home is shared. Execute in non-rolling mode." 2. Execution Requirements for Non-Rolling Mode

To resolve this and execute correctly, follow these "exclusive" operational rules: Node Availability:

Local Node: The GI stack must be UP on the node where you initiate the command.

Remote Nodes: The GI stack must be DOWN on all other nodes in the cluster. Privileges: You must execute the command as the root user.

Command Syntax: You must explicitly include the -nonrolling flag:

# /OPatch/opatchauto apply -nonrolling Use code with caution. Copied to clipboard (Reference:) 3. Strategic Steps for a Solid Execution Preparation:

Update OPatch to the latest version in both Grid and Database homes.

Check for conflicts using the -analyze flag first: opatchauto apply -analyze -nonrolling. Sequence: Stop the GI stack on all remote nodes: crsctl stop crs. Run the opatchauto command on the local node.

The utility will handle stopping the local stack, applying the binary patch to the shared home, and restarting the services. Completion:

Once the first node is finished, you must still run the command on the remaining nodes to update the local configuration and inventory, though the actual binary patching of the shared home is already done. 4. Key Limitations

Out-of-Place Patching: Note that the -nonrolling option is generally not supported for "out-of-place" patching (using -outofplace), where a new home is cloned.

Downtime: Non-rolling mode implies a complete outage for the duration of the patching on the first node.

Next Steps:If you're ready to proceed, I can help you verify your inventory status or provide the exact pre-check commands for your specific Oracle version. Are you currently on 12c, 19c, or 21c?

Prerequisites Checklist

Before executing, ensure the following:

✅ Patch downloaded and unzipped
✅ ORACLE_HOME and PATH set correctly
✅ GI and database services can be stopped (planned downtime)
✅ Backups of Oracle home and database
✅ Patch README reviewed for special instructions
✅ Clusterware running (for RAC) – opatchauto checks cluster state
✅ No other opatch processes running

Step-by-step: Executing OPatchAUTO in nonrolling exclusive mode (general guidance)

Note: These are generic steps; always follow the specific patch README.

  1. Prepare environment:

    • Set Oracle environment variables for the target Oracle Home (ORACLE_HOME, GRID_HOME).
    • Stop services that must be offline per patch README (e.g., application services, listeners) if required.

  2. Ensure cluster nodes are prepared:

    • For Grid Infrastructure patches, use crsctl stop cluster -all or stop CRS on all nodes if required (but follow README; sometimes you stop Oracle Clusterware on all nodes).
    • For RAC database homes, stop database instances on all nodes as required: srvctl stop database -d <db_unique_name> or SQL*Plus shutdown immediate on each instance.

  3. Acquire exclusive lock (handled by OPatchAUTO):

    • OPatchAUTO will attempt to acquire exclusive locks on the target Oracle Home(s)/resources. Ensure no other OPatch session or maintenance operations are running.

  4. Run OPatchAUTO in nonrolling mode:

    • Invoke OPatchAUTO with proper flags. Example (adjust paths/options per README): 
      $GRID_HOME/OPatch/opatchauto apply -oh $ORACLE_HOME -nonrolling -exclusive -local
      or with OPatch (non-auto): 
      $ORACLE_HOME/OPatch/opatch apply -oh $ORACLE_HOME -nonrolling
    • Use sudo or oracle user as appropriate.

  5. Monitor the apply:

    • Watch OPatch/OPatchAUTO logs (within OPatch log directory) for progress and any prompts. Address any missing prerequisites or conflicts shown.

  6. Post-apply steps:

    • Start services/CRS/databases in the correct order: start Grid Infrastructure, then database instances (srvctl start database -d <db_unique_name>).
    • Verify cluster and database health: crsctl stat res -t, srvctl status database -d , sqlplus connection checks.
    • Run opatch lsinventory to confirm patch applied.

  7. Cleanup and validation:

    • Check application-level connectivity and run smoke tests.
    • Retain logs and note timings for change records.

Why OPatchAUTO72030 appears

Common causes:

OPatchAUTO may display a message or log entry referencing OPatchAUTO72030 to indicate it will execute in nonrolling exclusive mode or that the operation must be performed exclusively.

1. opatchauto

The opatchauto utility is the next-generation patching tool for Oracle Grid Infrastructure and RAC databases. Unlike the legacy opatch (which patches a single Oracle home), opatchauto understands cluster topologies. It can patch both the Grid home (CRS/ASM) and all database homes across all nodes in a cluster.

Best Practices