This is the command that triggers the outage and patching.
# As root user
/opatchauto apply /path/to/72030 -nonrolling -oh /u01/app/grid_home
(Note: If -oh is omitted, opatchauto attempts to patch all detected homes. Specifying -nonrolling is the critical flag here.)
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
Ensure no opatch or opatchauto sessions are running anywhere.
ps -ef | grep opatch
Executing opatchauto 72030 -nonrolling -exclusive is a powerful but high-stakes operation. It guarantees that the Oracle home is untouched during patching and applies updates to all nodes simultaneously—ideal for planned outages or single-instance systems. However, it demands thorough preparation, valid backups, and strict adherence to patch documentation.
When used correctly, non-rolling exclusive mode simplifies patching and reduces total maintenance time. When misused, it can lead to extended downtime. Always respect the patch README and Oracle’s rolling/non-rolling guidelines.
Last updated: March 2025. Always refer to Oracle Support for patch-specific notes.
The phrase "opatchauto72030 execute in nonrolling mode exclusive" appears to be a specific command or log fragment related to Oracle Grid Infrastructure (GI) or Oracle Database patching using opatchauto (the automatic patching utility for Oracle Clusterware and RAC environments).
Here’s a breakdown of what each part likely means:
The error OPATCHAUTO-72030 typically occurs during Oracle Grid Infrastructure (GI) patching when opatchauto is executed in rolling mode but encounters a configuration that requires a non-rolling approach. This commonly happens when the Grid Infrastructure home is shared across nodes or when applying a patch that is inherently non-rollable. Direct Answer
To resolve this, you must explicitly use the -nonrolling option in your command. For non-rolling mode, all nodes in the cluster must be shut down before applying the patch. Correct Command Syntax:
# As root user: opatchauto apply Use code with caution. Copied to clipboard Root Cause Analysis
The failure message indicates that the orchestration engine cannot proceed in the default "rolling" mode (patching one node at a time while others stay up).
Shared Homes: If your CRS home is shared, the binaries cannot be patched node-by-node because they all point to the same physical disk location.
Non-Rollable Patches: Some patches contain changes that are incompatible with running mixed versions across a cluster simultaneously. Execution Workflow (Non-Rolling Mode)
When running in non-rolling mode, follow these steps to ensure a successful application:
Shutdown Stacks: Manually bring down all databases and the Oracle Grid Infrastructure stack on all nodes.
Verify Status: Use crsctl check status crs to ensure the stack is offline.
Apply Patch: Execute the opatchauto command with the -nonrolling flag as shown above.
Sequential Patching: Start by patching a single node, then patch the remaining nodes in parallel, and finish with the final node to complete the session.
Restart & Post-Patch: Bring up the stacks and databases. Run datapatch on the final node to apply SQL changes if required. Troubleshooting Tips Doc ID 2957442.1 OPATCHAUTO-72030 During Opatchauto
Running OPatchAuto in non-rolling mode is an efficient and reliable way to handle complex Oracle Grid Infrastructure (GI) or RAC environments, especially when dealing with shared homes or non-rollable patches. This mode ensures full consistency across the stack by updating multiple components in parallel while they are offline, which significantly reduces the total maintenance window compared to sequential rolling updates.
Here are the key benefits and features that make this approach effective:
Minimized Total Outage Time: While it requires a complete service outage, the parallel nature of non-rolling patching completes the overall update faster than the one-node-at-a-time rolling method.
Resolution for Error OPATCHAUTO-72030: This mode is the direct solution for the OPATCHAUTO-72030: Cannot execute in rolling mode, as CRS home is shared error, allowing for successful patch application in shared ORACLE_HOME environments.
Simplified Orchestration: It eliminates the "mental effort" of host-to-host command sequences. By using the -nonrolling flag, the tool automatically sequences the shutdown, patching, and startup phases across the cluster.
Strict Consistency: It is the safest choice for non-rollable patches, ensuring that node-specific metadata and binaries remain perfectly synchronized across the entire cluster.
For a smooth execution, ensure the GI stack is stopped on all remote nodes before starting the session from the local node.
3 Concepts of Multi-Node Patch Orchestration Using OPatchAuto
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: opatchauto72030 execute in nonrolling mode exclusive
# 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 . 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?
Troubleshooting OPATCHAUTO-72030: Shared CRS Homes and Non-rolling Patching
If you've encountered the error OPATCHAUTO-72030: Execution mode invalid, you aren't alone. This typically occurs during Oracle Grid Infrastructure (GI) patching when the utility detects a configuration that is incompatible with the default "rolling" mode. What is Error OPATCHAUTO-72030?
By default, the OPatchAuto utility attempts to apply patches in rolling mode. This allows the cluster to stay online by patching one node at a time. However, certain configurations—most notably shared Oracle Homes (where the CRS home is shared across nodes)—cannot be updated this way.
When OPatchAuto detects a shared home, it throws the following message:
OPATCHAUTO-72030: Cannot execute in rolling mode, as CRS home is shared. Execute in non-rolling mode. Why Non-rolling Mode?
In a shared home environment, the binaries being patched are the exact same files used by every node. You cannot "roll" through the cluster because updating the file for one node updates it for all of them simultaneously. Therefore, the entire stack must be down to ensure no processes are locking the files during the update. Step-by-Step Resolution
To resolve this, you must explicitly tell OPatchAuto to use the -nonrolling flag. Follow these steps to ensure a clean patching session:
Stop Remote Nodes: Before starting, all remote nodes in the cluster must be stopped. The patching operation will take place from the local node.
Verify the Local Stack: For Oracle 12c and later, the GI stack must actually be up on the local node when you invoke the command.
Execute the Command: Run the patch application using the -nonrolling option as the root user: # opatchauto apply Use code with caution. Copied to clipboard
Phased Execution: In a non-rolling session, OPatchAuto typically follows three phases: Phase 1: Patch the local node (Node 1). Phase 2: Patch remote nodes (Nodes 2 through ) in parallel. Phase 3: Patch the final node ( ) to complete the session. Key Takeaways
Shared Homes = Non-rolling: If your /u01/app/19.0.0/grid (or similar) is on a shared file system, you must use the -nonrolling flag.
Total Downtime: Expect a complete application outage, as all database instances and GI stacks will be offline during the binary update.
Check Permissions: Ensure you are running the command from a directory other than /root or /, and verify that the home owner has write permissions to the current directory.
For more detailed syntax, refer to the OPatchAuto Syntax and Commands guide. Rocky Linux release 8.8 19c rac ru安装 - 墨天轮
OPatchauto72030 Execute in Non-Rolling Mode Exclusive: A Comprehensive Guide
In the realm of Oracle database administration, maintaining the integrity and security of the database is of utmost importance. One crucial aspect of this is ensuring that the database is up-to-date with the latest patches and updates. Oracle provides a utility called OPatchauto to automate the patching process. One of the modes in which OPatchauto can operate is the non-rolling mode, specifically with the "exclusive" option. This article aims to provide an in-depth understanding of executing OPatchauto72030 in non-rolling mode exclusive.
Understanding OPatchauto
OPatchauto is a command-line utility provided by Oracle to apply patches to Oracle databases. It simplifies the patching process by automating the application of patches, thereby reducing the risk of human error and minimizing downtime. OPatchauto is a part of the Oracle Database software and is used for applying patches to Oracle Database, Oracle Grid Engine, and other Oracle products.
Non-Rolling Mode Exclusive
When executing OPatchauto, there are several modes in which it can operate. The non-rolling mode is one such mode where the patch is applied without requiring a database restart. In non-rolling mode, the patch is applied to a single instance of the database, and the database remains available throughout the patching process.
The "exclusive" option in non-rolling mode ensures that the patch is applied exclusively to the specified instance, without affecting other instances in a multi-instance environment. This option is particularly useful in RAC (Real Application Clusters) environments where multiple instances of the database are running.
Benefits of Non-Rolling Mode Exclusive
Executing OPatchauto72030 in non-rolling mode exclusive offers several benefits:
Prerequisites for Executing OPatchauto72030 in Non-Rolling Mode Exclusive
Before executing OPatchauto72030 in non-rolling mode exclusive, ensure that the following prerequisites are met:
Executing OPatchauto72030 in Non-Rolling Mode Exclusive
To execute OPatchauto72030 in non-rolling mode exclusive, follow these steps:
opatchauto.sh apply <patch_id> -nonrolling -exclusive
Replace <patch_id> with the actual patch ID.
Example Command
opatchauto.sh apply 12345678 -nonrolling -exclusive
Post-Patching Activities
After executing OPatchauto72030 in non-rolling mode exclusive:
Conclusion
Executing OPatchauto72030 in non-rolling mode exclusive provides a flexible and controlled way to apply patches to Oracle databases. By understanding the benefits, prerequisites, and steps involved in executing OPatchauto72030 in non-rolling mode exclusive, DBAs can ensure a smooth and efficient patching process, minimizing downtime and ensuring continuous business operations.
The error OPatchAuto72030 typically occurs during Oracle Grid Infrastructure or Database patching when the utility detects a configuration conflict or a failed previous attempt. Specifically, it indicates that a command intended for non-rolling mode is being executed in an environment or sequence that the tool deems "exclusive" or restricted.
Understanding OPatchAuto72030: Execute in Non-Rolling Mode Exclusive
When applying Release Updates (RU) or Bundle Patches (BP) to an Oracle RAC environment, administrators often choose between rolling (node-by-node) and non-rolling (all nodes down) methods. The 72030 error code acts as a safety gate. It prevents the patch utility from proceeding when it cannot guarantee the integrity of the cluster state. Common Root Causes
The most frequent reasons for encountering this specific execution error include:
* Mismatched patch parameters where '-rolling' and '-nonrolling' logic conflict.* Leftover files from a previous failed patch session in the inventory.* The Oracle High Availability Services (OHAS) stack being in an unexpected state.* Attempting a non-rolling patch on a single-node GI installation that expects standard execution. Step-by-Step Troubleshooting and Resolution
Follow these steps to clear the error and successfully apply your patch. Validate the Command Syntax
Ensure you are using the correct flags for your specific patch version. For most modern 19c or 21c environments, a non-rolling patch is initiated from the Grid Home as the root user. opatchauto apply /path/to/patch -nonrolling
If you are manually passing a property file, ensure the "rolling=false" attribute is correctly defined and not contradicted by other command-line arguments. Clean Up Failed Patch States
OPatchAuto tracks progress in the storage management and inventory. If a previous run crashed, it might still think it is in the middle of a "rolling" window. Check the inventory status using: opatch lsinventory.
If a session is active, you may need to use the -resume or -rollback command to clear the state before trying the non-rolling execution again. Verify Clusterware State
A "non-rolling mode exclusive" execution often requires the cluster stack to be down on all nodes or specifically managed. Check status: crsctl check crs.
If the patch requires a completely stopped stack, ensure you have run: crsctl stop crs -f on the target nodes. Check Log Files for Specific Conflicts
The 72030 error is often a "wrapper" for a deeper OS or permission issue. Navigate to your OPatch storage directory to find the detailed logs. Path: $ORACLE_HOME/cfgtoollogs/opatchauto/
Look for the specific log ID generated during the failure. Search for "SEVERE" or "Caused by" to see if there is an underlying locking issue or a missing library that is triggering the exclusive mode block. Best Practices for Non-Rolling Patches To avoid this error in future maintenance windows:
Always update the OPatch utility to the latest version before patching.
Run the opatchauto apply -analyze command first to identify conflicts without changing the system.
Ensure the 'root' user has full passwordless SSH connectivity between all nodes, even for non-rolling modes, as the tool still checks the inventory across the cluster.
By ensuring the environment is "clean" and the command flags are explicit, you can bypass the OPatchAuto72030 error and complete your database maintenance.
Title: The Calculated Risk: Executing Opatchauto 72030 in Non-Rolling Exclusive Mode
In the intricate ecosystem of Oracle Database administration, the application of patches is a necessary yet formidable maintenance task. Among the toolkit available to administrators, opatchauto stands out as a robust utility designed to automate the complex orchestration of patching both the Oracle Grid Infrastructure (GI) and the Oracle Database homes. While rolling patches—where nodes are updated sequentially to maintain uptime—are the gold standard for high availability, specific scenarios demand a different approach. The execution of a specific patch, such as patch 72030, in non-rolling mode using the -exclusive flag represents a distinct operational paradigm. It prioritizes system integrity and configuration stability over continuous availability, requiring a comprehensive understanding of the trade-offs involved.
The decision to execute opatchauto in non-rolling mode is rarely taken lightly. In a standard Rolling mode, the administrator patches one node at a time, allowing the cluster to remain operational while services migrate between nodes. However, this process is time-consuming and relies heavily on the clusterware’s ability to relocate services seamlessly. Conversely, the non-rolling mode dictates that all services across the entire cluster must be brought down before the patching process begins. When the -exclusive flag is introduced, it enforces a strict lockdown on the Oracle homes, ensuring that no other operations interfere with the patching process. This is often required for patches that modify fundamental binaries or shared resources that cannot be modified while the system is active.
Executing patch 72030 in this manner offers distinct advantages regarding system stability and patch integrity. By halting all database instances and clusterware resources, the administrator eliminates the risk of "split-brain" scenarios or resource contention that can occasionally plague rolling updates. For a patch like 72030, which may involve critical changes to core kernel extensions or shared library paths, the non-rolling approach ensures that the modification is applied cleanly across all nodes simultaneously. The -exclusive flag amplifies this by guaranteeing that the Oracle homes are fully locked, preventing rogue processes or scheduled jobs from attempting to access the binaries during the critical update window. This results in a more deterministic outcome, reducing the variables that can lead to post-patching instability.
However, this method carries the significant weight of a complete system outage. The term "non-rolling" is synonymous with downtime. For mission-critical enterprises operating under strict Service Level Agreements (SLAs), scheduling a maintenance window large enough to accommodate the shutdown, patch application, and restart of the entire stack is a logistical challenge. The execution of opatchauto in this mode requires meticulous pre-checks. The administrator must verify that all nodes are healthy prior to shutdown, as a failed node can complicate the startup sequence. Furthermore, the startup process after a non-rolling patch is a critical moment; all nodes must successfully rejoin the cluster, and the database instances must open without error. The pressure on the database administrator is heightened because the system is entirely unavailable during this window, leaving no margin for error.
The syntax itself, typically resembling opatchauto apply <PATCH_PATH> -oh <ORACLE_HOME> -nonrolling -exclusive, belies the complexity of the underlying operations. The utility must navigate the cessation of Cluster Ready Services (CRS), the modification of the Oracle Inventory, the patching of the Grid Infrastructure home, and finally the restart of the stack. It automates what would otherwise be a manual, error-prone sequence of dozens of commands. Yet, automation does not absolve the administrator of responsibility. Validating the patch success involves checking logs, verifying the inventory, and ensuring that the specific fixes contained within patch 72030 are active.
In conclusion, the execution of opatchauto for patch 72030 in non-rolling exclusive mode is a strategic decision that balances the necessity of technical stability against the cost of downtime. While it lacks the seamless continuity of a rolling update, it provides a clean, controlled environment essential for certain types of critical system updates. For the Database Administrator, it represents a exercise in risk management: accepting the outage to ensure the absolute integrity of the database infrastructure. Mastery of this process involves not just running the command, but preparing the environment for the inevitable pause and ensuring a rapid, successful return to service.
The error OPATCHAUTO-72030 typically occurs during Oracle Grid Infrastructure (GI) patching when the system is unable to proceed in "rolling" mode (where nodes are patched one by one without total cluster downtime). This message indicates that a non-rolling mode execution is required, often due to a shared home configuration or specific patch requirements. Understanding Error OPATCHAUTO-72030
Root Cause: This error most frequently appears when the OPatchAuto utility detects a shared Grid Infrastructure (CRS) home or a patch that cannot be applied while other nodes are active.
Mechanism: In rolling mode, at least one remote node must be active; however, for shared homes, the utility cannot isolate the local node's binaries for patching without affecting the entire cluster. How to Execute in Non-Rolling Mode
To resolve this, you must stop all services across all nodes and use the -nonrolling flag with OPatchAuto.
Stop All Cluster Resources: Ensure the GI stack and all databases are stopped on all nodes in the cluster.
Execute the Patch Command: Run the command as the root user from the patch directory: # opatchauto apply Use code with caution. Copied to clipboard
Specific Home Option: If you only want to patch a specific home (like the GI home), include the -oh flag:
# opatchauto apply Use code with caution. Copied to clipboard Key Considerations for "Exclusive" Mode
The term "exclusive" in this context usually refers to an exclusive lock or state required for patching shared binaries. Rocky Linux release 8.8 19c rac ru安装 - 墨天轮 This is the command that triggers the outage and patching
Solving OPATCHAUTO-72030: Switching to Non-Rolling Mode for Shared Homes
When patching an Oracle Grid Infrastructure (GI) environment, encountering OPATCHAUTO-72030
is a common sign that your environment requires a different patching strategy than the default. This error typically triggers when you attempt a rolling patch on a shared GI home Oracle documentation notes must be updated across all nodes simultaneously. What is OPATCHAUTO-72030? The error message explicitly states:
OPATCHAUTO-72030: Execution mode invalid. Cannot execute in rolling mode, as CRS home is shared. Execute in non-rolling mode.
In a shared home configuration, all nodes run from the same set of binaries. Because a "rolling" patch updates one node while others stay active, it is impossible to apply to a shared disk without affecting the active nodes. Step-by-Step Resolution 1. Preparation: Stop Services on All Nodes Unlike rolling patches, non-rolling mode requires the entire cluster stack to be down. Log in as the
Stop the Oracle high-availability services on all nodes using the Oracle Cluster Control # Run on all nodes $GRID_HOME/bin/crsctl stop crs Use code with caution. Copied to clipboard Verify that no processes are holding the binaries. 2. Execute with the -nonrolling Flag The fix is to explicitly tell opatchauto
to use non-rolling mode. Navigate to your patch directory and run the following as # Example syntax for 12c or 19c
/u01/app/grid/OPatch/opatchauto apply /path/to/patch -oh /u01/app/grid -nonrolling Use code with caution. Copied to clipboard Always ensure you are using the latest OPatch utility (Patch 6880880) before starting. 3. Common Troubleshooting Tweaks
In some environments (specifically RHEL8 or OEL7), you may need to set specific environment variables to bypass remote copy issues that occasionally accompany this error:
export CV_ASSUME_DISTID=OEL7.8 export ORACLE_SRVM_REMOTECOPY=/usr/bin/scp Use code with caution. Copied to clipboard 4. Restart and Verify Once the patch completes successfully: Restart the stack on all nodes: $GRID_HOME/bin/crsctl start crs Verify the patch level using the OPatch inventory $ORACLE_HOME/OPatch/opatch lsinventory ``` Use code with caution. Copied to clipboard Summary Table Rocky Linux release 8.8 19c rac ru安装 - 墨天轮 7 Sept 2023 —
Introduction
In the realm of database administration, Oracle's OPatch utility plays a crucial role in applying patches to Oracle databases. One of the key features of OPatch is its ability to execute in non-rolling mode, which allows for the application of patches without requiring a database restart. In this essay, we will explore the concept of executing OPatch in non-rolling mode exclusively, specifically with the command opatchauto72030 execute in nonrolling mode exclusive.
What is OPatch?
OPatch is a utility developed by Oracle Corporation to manage and apply patches to Oracle databases. It is a Java-based tool that automates the process of patching Oracle databases, making it easier to maintain and update database software. OPatch allows database administrators to apply patches, verify patch levels, and roll back patches if necessary.
Non-Rolling Mode
Non-rolling mode is a feature of OPatch that allows patches to be applied without requiring a database restart. In traditional rolling mode, a patch application requires a database restart, which can lead to downtime and impact business operations. Non-rolling mode, on the other hand, enables patches to be applied while the database remains online, minimizing downtime and ensuring continuous availability.
Exclusive Mode
When executing OPatch in non-rolling mode, there are two sub-modes: shared and exclusive. In shared mode, multiple OPatch sessions can run concurrently, allowing multiple patches to be applied simultaneously. However, this can lead to conflicts and errors if multiple patches are applied to the same database object. Exclusive mode, on the other hand, ensures that only one OPatch session can run at a time, providing a higher level of control and minimizing the risk of conflicts.
Command: opatchauto72030 execute in nonrolling mode exclusive
The command opatchauto72030 execute in nonrolling mode exclusive is used to execute OPatch in non-rolling mode exclusively. This command applies patches to the database without requiring a restart, and only one OPatch session can run at a time. The opatchauto72030 part of the command refers to the specific patch being applied, which in this case is patch 72030.
Benefits of Executing OPatch in Non-Rolling Mode Exclusively
Executing OPatch in non-rolling mode exclusively provides several benefits, including:
Conclusion
In conclusion, executing OPatch in non-rolling mode exclusively using the command opatchauto72030 execute in nonrolling mode exclusive provides a efficient and controlled way to apply patches to Oracle databases. By minimizing downtime, improving control, and reducing the risk of errors, this approach ensures a more stable and reliable database environment. As database administrators continue to play a critical role in maintaining and updating database software, understanding the features and benefits of OPatch is essential for ensuring optimal database performance and availability.
OPATCHAUTO-72030 is a specific validation failure in Oracle’s OPatchAuto
utility. It occurs when the tool detects that a patch cannot be applied in the default "Rolling" mode, typically because the environment uses a shared Cluster Ready Services (CRS) home or the patch itself is flagged as non-rollable in its metadata. Oracle Help Center Performance Review: OPatchAuto-72030 Handling
When this error triggers, it effectively acts as a safety mechanism to prevent system corruption that would occur if you tried to patch a shared home while other nodes were still using it. Detection Accuracy:
The utility is highly effective at identifying configuration conflicts early (often during the
phase), saving administrators from failed midway patching sessions. Actionability:
The error message explicitly directs the user to "Execute in non-rolling mode," providing a clear path forward. Operational Impact: Switching to non-rolling mode requires , as services on all remote nodes must be stopped. Oracle Forums Execution in Non-Rolling Mode
In modern Oracle environments (12c and later), "non-rolling" doesn't mean everything is offline; rather, it follows a specific three-phase orchestration: Oracle Help Center Phase 1 (Local Node):
Patch the first node while the Grid Infrastructure (GI) stack is up. Phase 2 (Remote Nodes 2 to n-1): Patch these nodes in parallel. Phase 3 (Final Node): Complete the session on the last node. Oracle Help Center Best Practices for Error 72030 Verify Cluster State:
Before proceeding in non-rolling mode, ensure all remote nodes are down. Check Patch Metadata: Review the Patch README to confirm if the patch is inherently non-rollable. Run as Root:
Ensure you are executing the command with root privileges from a directory where the home owner has write permissions. Analyze First: Always use the
flag first to catch OPATCHAUTO-72030 before any actual changes are applied to the binaries. exact command syntax to restart your session in non-rolling mode? Doc ID 2957442.1 OPATCHAUTO-72030 During Opatchauto
Navigate to the Grid home (or whichever home owns the CRS stack). Typically, opatchauto is run from the Grid home to patch the cluster.
cd $ORACLE_HOME (Grid home)
$ORACLE_HOME/OPatch/opatchauto apply /stage/72030 -nonrolling -exclusive
Wait a moment – notice I changed execute to apply. Why? In modern Oracle versions (12.2+), the execute command is often deprecated or merged into apply. The apply command with nonrolling exclusive will run the scripts automatically. However, if the patch documentation explicitly says opatchauto execute, then use it exactly as documented.
What you will see during execution:
OPatchauto session is acquiring exclusive mode...
Successfully acquired exclusive lock on home.
Validation in progress...
Shutting down Oracle Clusterware stack on all nodes...
Node1: CRS stopped.
Node2: CRS stopped.
Executing postpatch SQL scripts in exclusive mode...
Patch 72030 executed successfully.