Oracle patch prerequisite check OPatch OEM MOS
Oracle database patching is one of the most frequently executed maintenance activities that every DBA does in his life. The task is fairly simple and straight forward using the patch instructions from My Oracle Support (MOS). However in this article I’d like to highlight the importance of different Patch Prerequisite Checks that you have to perform before doing the patching itself. I think the entire success of patching exercise depends mostly on this step as seen on the below table that represents major PSU patching steps and approximate time lines. The rest of this draft document describes some best practices, tips and code examples for doing patch prerequisite checks using OEM Cloud Control, MOS and OPatch utility. Comments, adjustments, other tips and ideas are welcome and will be included in this post.
Oracle database PSU patching steps
Do patch prerequisite checks upfront
Do patch prerequisite checks upfront, long before the patching itself to have enough time to analyze the possible issues, create and test the plan on fixing them.General prerequisite checks
# Check OPatch version; best to use latest OPatch -> download from MOS patch 6880880$ORACLE_HOME/OPatch/opatch version
# Check OPatch version against the patch version (patch location specific)
$ORACLE_HOME/OPatch/opatch prereq CheckMinimumOPatchVersion -ph ./
# Check if there is enough system space available (patch location specific)
$ORACLE_HOME/OPatch/opatch prereq CheckSystemSpace -ph ./
# Run cvu and exachk where applicable
Check installed patches
$ORACLE_HOME/OPatch/opatch lsinv -all #patches installed$ORACLE_HOME/OPatch/opatch lsinv -details #patches installed – detail output
$ORACLE_HOME/OPatch/opatch lsinv -bugs_fixed | grep “PATCH SET UPDATE”
# Check if online patches exist and their status
SQL+> oradebug patch list
# Ensure the database part of installed patches was executed
SQL+11g> select * from dba_registry_history;
SQL+12c> select * from dba_registry_sqlpatch;
# RAC: Cross check patch identity across cluster nodes -> checksum should be identical on all nodes!
$ORACLE_HOME/OPatch/opatch lsinv -all_nodes
Check possible patch conflicts – 4 methods
To determine whether you have patches in the Oracle home that conflict with the one you want to install, and to get the necessary conflict resolution patches, you have to identify the patch conflicts.There are 4 major methods (that I know) to identify patch conflicts:
1) Patch validation with Oracle Enterprise Manager (OEM) Cloud Control
The fastest and easiest way to identify Patch Conflicts is using Oracle Enterprise Manager (OEM) Cloud Control.
OEM Cloud Control includes integrated patching workflow with MOS including analysis / validation of the patch conflicts using Patch Plans. Quick workflow is below:
– Go through OEM Cloud Control menu: Enterprise->Provisioning and Patching->Patches and Updates
– Choose recommended or search for a required patch and add it to a new or existing Patch Plan
– Go to Validation section (Step 4) in the left panel of the Patch Plan Window to validate the patche(s)
OEM 12c Cloud Control Patch Conflict Validation
2) Automatic method using MOS Patch Plans and Configuration Manager
The second easiest way to validate the patch is to use the Patch Recommendations and Patch Plans features on the Patches & Updates tab in MOS. These features work ONLY in conjunction with MOS Targets that are created using Oracle Configuration Manager.
So using this method and MOS functionality you crosscheck your database configuration stored in the Target on MOS (that includes information about existing installed patches on your database) against the new patch you want to install.
It works very similar to OEM Cloud Control but instead you complete all the step on MOS:
– Pick a required /recommended patch from the corresponding Target page or find one on Patches & Updates Tab
– Add the patch to a new or existing Patch Plan
– Go to Patch Plan page
– Go to Validation section (Step 3) in the left panel of the Patch Plan Window to validate the patche(s)
MOS Patch Validation using Patch Plan and database Target
If no conflicts are found, you can download the patches. If conflicts are found, the tool finds an existing resolution to download. If no resolution is found, it will automatically request a resolution, which you can monitor in the Plans and Patch Requests region of the Patches & Updates tab.
3) MOS Patch Conflict Checker tool
If you do not use MOS Configuration manager, the next possible option is using MOS Conflict Checker tool. Here again you do not need to download the patch itself to the database server. Instead you generate the Inventory file on the database server with OPatch utility and upload it into MOS Conflict Checker tool.
– How to generate OPatch Inventory file:
$ORACLE_HOME/OPatch/opatch lsinv
– Upload the corresponding following file into MOS Conflict Checker:
$ORACLE_HOME/cfgtoollogs/opatch/lsinv/lsinventory<timestamp>.txt
– Press “Analyze for Conflict” button
MOS Conflict Checker – database Patch Conflict Analysis
4) Manual Patch Conflict Check with OPatch utility
If you still want to proceed with manual conflict check you do this with OPatch utility in the directory where the patch is downloaded and unzipped using below commands:
# Check if the patch has conflicts with Already installed patches
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./$ORACLE_HOME/OPatch/opatch prereq CheckConflictAmongPatches -ph ./
So that was the most important part of Oracle database patching: some best practices, tips and code examples for doing patch prerequisite checks using OEM Cloud Control, MOS and OPatch utility.
