Opatchauto Resume Command

0 views

Skip to first unread message

Sear Sommerfeldt

unread,

Aug 3, 2024, 3:28:53 PM8/3/24

to winthrifengpho

If this option is selected, the environment will be analyzed for suitability of the patch on each home without affecting the home. The patch will not be applied or rolled back and targets will not be shut down.

If opatchauto apply is run and encounters an individual patch within a patch set that cannot be installed, that patch will be skipped and OPatchAuto will continue with the installation of the next patch in the sequence.

If opatchauto apply is run and encounters an individual patch that is identical (same patch ID and Unique Patch Identifier (UPI)) to a patch already installed in the product home, OPatchAuto perform the following based on specific patch conditions:

This analyze option simulates an OPatchAuto apply session by running all prerequisite checks, when possible, without making changes to the system (either bits or configurations). Because the analyze command does not modify the system, it will perform the following checks:

In this Document
PurposeDetails Concepts Preparation for 'opatchauto apply' Central Inventory Oracle Home Inventory (Local Inventory) Other Aspects Preparation for 'opatchauto resume' OPatchauto Session GI/RDBMS Status Top Issues Issue #1 Fixed Central Inventory's oui-patch.xml problem and first opatchauto resume fails with 'corrupted. PatchObject constructor: Input file "... config/actions" or "... config/inventory" does not exist' regarding Grid Home Issue #2 opatchauto apply fails with java.io.FileNotFoundException: /ContentsXML/oui-patch.xml (Permission denied)
Issue #3 opatchauto apply fails with //custom/scripts/prepatch.sh: Permission denied and file on has permission: rw-r--r--
Issue #4 After successfully applied the GI RU on all nodes, cluster upgrade state is [ROLLING PATCH], not [NORMAL] when GI stack up and running on all nodes Issue #5 OPATCHAUTO-72050 and 'Topology creation failed' when opatchauto apply Issue #6 opatchauto apply fails with 'CRS-1159: The cluster cannot be set to rolling patch mode because Oracle Clusterware is not active on at least one remote node.' and CLSRSC-430 Issue #7 OPATCHAUTO-72030: Cannot execute in rolling mode, as CRS home is shared Issue #8 Copy Action: Destination File "/perl/bin/perl" is not writeable Questions & Answers Why "This command doesn't support System Patch" is reported when attempting to run opatch [ command ] ? How can I monitor the files copying progress during apply ? To workaround a failure, can I copy oneoffs/ folder from another node's Local Inventory?References My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.

This is a classic case where the patching failed as there were few executables/files from the HOME still active. Same you can verify in the standard logging directory cfgtoollogs for opatchauto for the patch failed.

opatchauto is a really powerful tool which even let you resume your patch even when the patching crashed in between by any reasons like server crash, reboot cases or even manual CTRL+C etc. The other two regular options are rollback and version.

The 19.12 patch cycle was out last week for both Database and Grid Infrastructure. Since then, I've seen some customers complaining about an issue in the tomcat patch when trying to patch their environment with the latest opatch version:

You must use the OPatch utility version 12.2.0.1.25 or later to apply this patch. Oracle recommends that you use the latest released OPatch version for 12.2 which is available for download from My Oracle Support patch 6880880 by selecting ARU link for the 12.2.0.1.0 OPatch release. It is recommended that you download the OPatch utility and the patch in a shared location to be able to access them from any node in the cluster for the patch application on each node.

PS: Note that I always recommend OOP (Out-of-Place) patching, as you reduce downtime and also the risk of issues. However, here I will use in-place to show what to do when you get stuck in the middle with one of your nodes down.

So as you can see I haven't had any issues. After researching a bit more, I found out this was an issue with "opatchauto resume", not with "opatchauto apply". And more specific to the opatch version ".25", the one required by this GI.

So let's forcibly introduce an error and try again the "opatchauto resume" in a new environment to simulate this issue. Here what I did was removing the execution flag from the java binary that will be shipped to the GRID_HOME. So this way java will fail to execute after the node is patched:

However, applying a patch manually in GI is not that simple. You may need to stop your CRS / unlock grid home / do it in multiple nodes / etc. There is even a MOS note for it. In step 5 of note below, you have all the details:

And it succeeds. That is it. Here are my 50 cents with a third option to solve the stuck GI patch apply. Just keep in mind that If DB is involved, then also start the database using "srvctl start database".