Following is a comprehensive step-by-step action plan for a single instance database stored on ASM in version 12.1.0.2 on Linux (OEL 6 64-bit). This guide outlines the essential phases from utility updates to final database verification.
Before executing the patch, the environment must be synchronized with the latest Oracle utilities and the inventory must be verified for consistency.
Ensure that both the Database and Grid homes are using the most recent version of OPatch.
$ unzip p6880880_121010_LINUX.zip -d /u01/app/oracle/product/12.1.0/db_1$ /u01/app/oracle/product/12.1.0/db_1/OPatch/opatch version
$ unzip p6880880_121010_LINUX.zip -d /u01/app/oracle/12.1.0.2/grid
$ /u01/app/oracle/12.1.0.2/grid/OPatch/opatch versionThe Oracle Configuration Manager response file is required for silent or automated patch applications.
Note: Press Enter/Return key and don't provide any input; select Yes when prompted.
$ export ORACLE_HOME=/u01/app/oracle/12.1.0.2/grid
$ $ORACLE_HOME/OPatch/ocm/bin/emocmrsp -no_banner -output /stage/ocm.rsp
Check the consistency of inventory information for the GI home and each database home. Run the following commands to ensure the components are listed correctly.
$ /u01/app/oracle/product/12.1.0/db_1/OPatch/opatch lsinventory -detail -oh /u01/app/oracle/product/12.1.0/db_1$ /u01/app/oracle/12.1.0.2/grid/OPatch/opatch lsinventory -detail -oh /u01/app/oracle/12.1.0.2/grid
This phase involves preparing the physical patch files and running a dry-run analysis to identify potential conflicts with existing one-off patches.
Unzip the patch files into a clean staging directory using the grid home owner account.
$ mkdir /stage/PSUpatch
$ cp /stage/p22191349_121020_Linux-x86-64.zip /stage/PSUpatch
$ cd /stage/PSUpatch
$ unzip p22191349_121020_<platform>.zip
Use the -analyze flag with opatchauto to identify identical or conflicting patches.
/u01/app/oracle/12.1.0.2/grid/OPatch/opatchauto apply /stage/PSUpatch/22191349 -analyze -ocmrf /stage/ocm.rspopatch rollback -id 21948354 -local -oh /u01/app/oracle/12.1.0.2/grid/u01/app/oracle/12.1.0.2/grid/bin/crsctl stop has -f$ORA_GI_HOME/crs/install/roothas.pl –postpatch to restart services if necessary before re-running the analysis.Once the analysis is clean, you can proceed to the physical application of the patch and the subsequent SQL updates within the database.
While opatchauto is designed to patch both GI and RDBMS homes, it is essential to verify the RDBMS Home manually afterward.
# /u01/app/oracle/12.1.0.2/grid/OPatch/opatchauto apply /stage/PSUpatch/22191349 -ocmrf /stage/ocm.rspopatchauto specifically for that home or use opatch apply for the individual components after shutting down the database.After the software is patched, the database must be updated to include the modified SQL files using the datapatch utility.
% sqlplus /nolog SQL> Connect / as sysdba SQL> startup SQL> quit % cd $ORACLE_HOME/OPatch % ./datapatch -verbose
Confirm the list of patches applied to the database by querying the registry.
SQL> select action_time, patch_id, patch_uid, version, status, bundle_series, description from dba_registry_sqlpatch;
| Step | Description | ETA |
| 1 | Update the OPATCH utility | 15 min |
| 2 | Create ocm.rsp file | 5 min |
| 3 | Validation of Oracle Inventory | 5 min |
| 4 | Stage the Patch | 5 min |
| 5 | One-off Patch Conflict Detection | 10 min |
| 6 | Apply the Patch | 60 min |
| 7 | Loading Modified SQL Files | 60 min |
| 8 | Final Patch Verification | 5 min |
Ready to optimize your Oracle Database for the future?