OPatchAuto
OPatchAuto is used for end-to-end configuration patching.
Configuration patching uses a site's configuration information for the patch process. This simplifies most steps in the patching process.
OPatchAuto peforms the required steps for possibly a sequence of patches to all on all nodes in an organization in one invoction, thus greatly eliminating the possibility of human errors.
OPatchAuto uses
srvctl
to
- stop home
- start home
- get home status
- relocate instance
- etc.
High level phases
Patching is performed in a sequence of phases. When all phases have been executed on a target node, the patching is completed.
Init | Bookeeping operation to initialize internal state needed for correction patching. |
Shutdown | Life-cycle operation that brings down run-time entities to permit patching. |
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. |
Start-up | Life-cycle operation that brings the shutdown entities back up again. |
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. |
Finalize | Book-keeping operation to record that patch operation is complete. |
Oracle's only supported method of installing interim patches is OPatch.
Supported targets
OPatchAuto can apply patches to the following targets
- GI Home Shared
- GI Home Not Shared
- RAC Home Shared
- RAC Home Not Shared
- SIHA and SIDB
Grid / RAC environment
Prerequisites
Node managers must be configured for start and stop operations.
Check if SSH is installed on each server
rpm –qa | grep ssh.
Steps
Acquire patches required for your installation | |
Review the README.txt file for the patch. | |
Check for patch prerequisites. | opatchauto -analyze |
Apply patch | |
Verify if patch was successfully applied to Oracle home | opatch -lsinventory |
Verify if software runs ok | GI: crsctl check status crs , RAC: srvctl status database –d <database> |
Troubleshoot application in case of a problem | Review log file found under $ORACLE_HOME/cfgtoollogs/opatchauto / use srvctl |
Rollback patch if problem not solvable | opatchauto rollback |
Patch file content
File type | Description | Installation |
SQL or PL/SQL scripts | These scripts are simply executed. They do stuff like adding indexes to base tables etc. | datapatch (located under ORACLE_HOME/OPatch ). Needs to be executed when the database is running. |
«Other» files | These files are copied somewhere under the Oracle home directory. They're typically binary in nature, such as executables or timezone files). | opatch (located under ORACLE_HOME/OPatch ). Needs to be executed when the instance is shut down. |
_ Readme.txt (or) Readme.html
bundle.xml
automation
|_____ apply_automation.xml
|_____ rollback_automation.xml
Sub-patch1
|_____ etc/config/inventory.xml
|_____ etc/config/actions.xml
|_____ files/Subpatch1 'payload'
Sub-patch2
|_____ etc/config/inventory.xml
|_____ etc/config/actions.xml
|_____ files/Subpatch1 'payload'
Some commands
Determining already installed patches
$ opatch lsinventory
Ensure that patch application prerequisites are met:
$ opatch apply -report
Applying a patch (with id 12345678
):
$ opatch apply /u01/download/patch/12345678
Applying multiple patches whose locations are stored in a file
$ opatch napply - -phBaseFile ~/patch-locations
~/patch-locations
contains (line by line) the paths where a patch is found.
Rolling back a patch
$ opatch rollback -id 12345678