Opatchauto Oracle 19c
Faith Lienhard
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:
OPatchAuto is Oracle's strategic tool for binary and configuration patching. For the supported environments (Fusion Middlware and Grid Infrastructure), OPatchAuto sequences and executes all required steps, on all nodes, for comprehensive patch application. Because OPatchAuto can patch full systems in one invocation, it removes the burdens of:
Your product's patching documentation (Database, Fusion Middleware, Enterprise Manager Cloud Control) explains how to use OPatchAuto to patch your specific product. This book augments those guides, by providing deeper conceptual and reference material for OPatchAuto, in a product independent manner.
They see advantage to interleaving their own commands into the patching sequence in order to take advantage of their production system's downtime window. In this case, understanding phases is required.
The conceptual related steps of patching operation is called a phase. Executing all phases leads to a completed patching operation on the target; skipping a phase means the patch is not correctly applied. For example, the phase/sub-phase of applying the bits to an Oracle Home is called offline:binary-patching in OPatchAuto.
Offline: Configuration change operation to apply the patch content with the system down. Bits application happens here, for instance. So the opatch patch will be recorded to the homes OUI inventory in this phase.
Online: Configuration change operation apply patch content that requires that the systems be up. If these configuration changes have a system inventory, they will also be recorded to that system's inventory at this point.
The specific content of the patch determines precisely what specific Oracle Home and configuration changes occur. Most Fusion Middleware patches, for example, only include offline content changes. But, of course, some include configuration changes as well.
In general, the session is an implicit parameter, set internally to the last session. It is visible to the user in the logs, communicated as a session ID, but there is no requirement for it to be supplied by the user. As a convenience for specifying the rollback parameters, you can specify the session ID. In this case, OPatchAuto knows to query that session for the patch you wish to rollback.
Patch plans describe, independent of a specific product instance's topology, the sequence of steps to execute in order to deploy the patch. Patch plans are life-cycle programs, developed by Oracle life-cycle management experts, specifically for the given product being patched.
They are optional and advanced inputs. However, internally, OPatchAuto always selects a patch plan to guide its execution. For example, internally, OPatchAuto apply and OPatchAuto rollback automatically select different patch plans implicitly.
Users will input patch plans to OPatchAuto when executing more complex life-cycle operation, such as Zero Downtime Patching. The product documentation for these life-cycle operations will list the names of valid patch plans.
OPatchAuto performs many of the pre-patch checks (see "Using OPatch") as well as the post-patch verification. The power of OPatchAuto lies in its ability to perform end-to-end configuration patching. Configuration patching is the process of patching a GI or RAC home based on its configuration. By incorporating the configuration information into the patch process, OPatchAuto streamlines patching tasks by automating most of the steps.
OPatchAuto uses your GI/RAC configuration and, from that information, automatically generates patching instructions specific to your site configuration. OPatchAuto then uses OPatch to implement these instructions and perform the actual application of the patch.
A System patch contains several sub-patches whose locations are determined by a file called bundle.xml in the top level directory of the patch. The sub-patches are intended for different sub-systems of a system that correspond with the database home organization.
OPatchAuto supports two modes of patching a GI or RAC Home - Rolling and Non-rolling. When a patching session is started off (on the first node), the stack has to be up and running on this node. This applies to both rolling and non-rolling modes of patching.
Rolling Mode (Default Mode): When performing patching in Rolling mode, the ORACLE_HOME processes on a particular node are shut down, the patch is applied, then the node is brought back up again. This process is repeated for each node in the GI or RAC environment until all nodes are patched. This is the most efficient mode of applying an interim patch to an Oracle RAC setup because this results in no downtime. Not all patches can be applied using Rolling mode. Whether or not a patch can be applied in this way is generally specified in the patch metadata. The patch README also specifies whether or not a patch can be applied in Rolling mode. The node (GI Home) from which the opatchauto command is executed is considered the LOCAL node and all other nodes are considered REMOTE nodes.
Non-rolling Mode: Prior to 12c, a non-rolling upgrade was defined as shutting down Oracle processes on all nodes. Beginning with 12c, non-rolling patching requires the GI stack to be up on local node. The patching operation on first and last node have special steps to perform hence the operation needs to be handled separately but not in parallel with other nodes. The non-rolling patching can ve described as three phases:
As shown in the following figure, given n nodes, you begin the non-rolling patch session by patching a single node, then patch nodes two through n-1 in parallel, and finally patch node n to finish the patching session.
As mentioned earlier, OPatchAuto applies patches in rolling mode by default. If the patch is applied in rolling mode but the patch content is not rollable (content does not support application in rolling mode), OPatchAuto will error out when attempting to run rootcrs.pl -prepatch.
This is an example of applying a 12.1.0.1 Grid Infrastructure PSU in GI Cluster or Standalone (Oracle Restart) environment using opatchauto in rolling mode. The example was on Linux but steps are the same for other platforms. The steps also apply to 12.1.0.2
In this Document
GoalSolution Environment Configuration Steps Log file locationReferences
My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.
They have given me a temporary workaround, but I'm looking for a more permanent way to run opatchauto without /tmp. I looked at the opatchauto apply options but did not see anything that stood out that would help.
Execution of [OPatchAutoBinaryAction] patch action failed, check log for more details. Failures:
Patch Target : -> Type[rac]
java.lang.NullPointerException
at com.oracle.glcm.patch.auto.db.integration.controller.action.OPatchAutoBinaryAction.executeSteps(OPatchAutoBinaryAction.java:237)
at com.oracle.glcm.patch.auto.db.integration.controller.action.DBCommonPatchAction.execute(DBCommonPatchAction.java:138)
at com.oracle.glcm.patch.auto.action.LocalPatchActionRunner.run(LocalPatchActionRunner.java:99)
at java.lang.Thread.run(Thread.java:750)
In this Document
SymptomsChangesCauseSolutionReferences
My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.
You could of course use oplan which is bundled in $ORACLE_HOME/OPatch/oplan/oplan to generate a lot more detailed profile for the patch application. For a first glance at the activity opatchauto -generateSteps seems quite useful.
Set up the environment. This includes the OPatch and patch file names, and the paths. Notice how OPatch has been added to the PATH environment variable. Remember to reset these if switching between users.
Keep a copy of the existing OPatch, and unzip the latest version of OPatch on all nodes of the cluster. You may have to do this as the root user for the grid home, but make sure the ownership of the resulting OPatch directory matches the original ownership once unzipped.
Check there is space to complete the patching. Create a file called "/tmp/patch_list_gihome.txt" containing the list of patches, then run the space check as the grid owner. The patch numbers will vary depending on the GI release update you are using.
Assuming the patching completes without errors, run the patch on the remaining nodes of the cluster. The remaining nodes can be patched at the same time. Only the first node must be patched on its own. From an availability perspective, it's better to patch them one at a time, so we only have one node out of action at any one time.
Under normal circumstances this step should not be necessary as it is run automatically as part of opatchauto. If you have some PDBs that are closed, or in mounted mode, you may have to apply datapatch to them separately.
c80f0f1006