| Feature | Rolling Mode (Default) | Non‑Rolling Mode | |---------|------------------------|------------------| | | One node at a time. | All nodes simultaneously. | | Cluster availability | Cluster remains available (though services move). | Cluster is fully down during patching. | | Downtime required | Minimal per node; overall longer patching time. | Single, longer downtime window. | | Failure risk | Lower; if one node fails, others still run. | Higher; any failure affects whole cluster. | | Use case | Most RAC patches, online patching. | Non‑RAC (standalone), or when rolling mode is not allowed by patch notes. |
$ORACLE_HOME/OPatch/opatchauto apply /path/to/72030 -analyze Look for a line that says: “Rolling mode is not possible. Only non‑rolling mode is supported.” Assuming you have met all prerequisites, here is the exact procedure to apply patch 72030 across a 2‑node or multi‑node cluster in non‑rolling mode. Step 1: Shutdown All Databases (Recommended for Safety) Although opatchauto can attempt to shutdown databases automatically in non‑rolling mode, it is safer to do it manually: opatchauto72030 execute in nonrolling mode
cd /u01/stage/72030 $ORACLE_HOME/OPatch/opatchauto apply . -nonrolling The correct flag is -nonrolling (not -nonrolling mode – the mode argument is implicit). Many DBAs mistakenly write execute in nonrolling mode , but the actual syntax is: | Feature | Rolling Mode (Default) | Non‑Rolling
# As grid user, on each node crsctl stop cluster -all Wait for crsctl status resource -t to show nothing running. Navigate to the patch directory and run: | Cluster is fully down during patching