STEP-BY-STEP GUIDE TO JANUARY 2016 PSU PATCH APPLY ON 12C GRID AND RDBMS HOMES IN LINUX

by Fahd Mirza
February 12, 2016
Posted in: Oracle, Technical Track
Tags: Linux
Following step by step action plan is for single instance database stored on ASM in 12.1.0.2 on Linux (OEL
6 64 bit in this case.)
Step Description ETA
1 Update the OPATCH utility: 15 min
For Database home:
$ 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

For Grid home:

$ unzip p6880880_121010_LINUX.zip -d /u01/app/oracle/12.1.0.2/grid
$ /u01/app/oracle/12.1.0.2/grid/OPatch/opatch version
2 Create ocm.rsp file: 5 min
Note: Press Enter/Return key and dont provide any input and say Yes.
$ export ORACLE_HOME=/u01/app/oracle/12.1.0.2/grid
$ $ORACLE_HOME/OPatch/ocm/bin/emocmrsp -no_banner -output /stage/ocm.rsp
3 Validation of Oracle Inventory 5 min
Before beginning patch application, check the consistency of inventory information for
GI home and each database home to be patched. Run the following command as
respective Oracle home owner to check the consistency.

For database home:

$ /u01/app/oracle/product/12.1.0/db_1/OPatch/opatch lsinventory -detail -oh
/u01/app/oracle/product/12.1.0/db_1
For Grid home:
$ /u01/app/oracle/12.1.0.2/grid/OPatch/opatch lsinventory -detail -oh
/u01/app/oracle/12.1.0.2/grid

If this command succeeds, it lists the Oracle components that are installed in the home.
Save the output so you have the status prior to the patch apply.
4 Stage the Patch: 5 min
 $ mkdir /stage/PSUpatch
$ cp /stage/p22191349_121020_Linux-x86-64.zip /stage/PSUpatch
Check that the directory is empty.
$ cd /stage/PSUpatch
$ ls
Unzip the patch as grid home owner.
$ unzip p22191349_121020_<platform>.zip
5 0One-off Patch Conflict Detection and Resolution: 10 min
Run it with root user:
/u01/app/oracle/12.1.0.2/grid/OPatch/opatchauto apply
/stage/PSUpatch/22191349 -analyze -ocmrf /stage/ocm.rsp
It will ask to rollback identical patches like this:
Analyzing patch(es) on /u01/app/oracle/12.1.0.2/grid
Patch /stage/PSUpatch/22191349/21436941 is already installed on
/u01/app/oracle/12.1.0.2/grid. Please rollback the existing identical patch first.
Patch /stage/PSUpatch/22191349/21948341 is already installed on
/u01/app/oracle/12.1.0.2/grid. Please rollback the existing identical patch first.
Patch /stage/PSUpatch/22191349/21948344 is already installed on
/u01/app/oracle/12.1.0.2/grid. Please rollback the existing identical patch first.
Patch /stage/PSUpatch/22191349/21948354 is already installed on
/u01/app/oracle/12.1.0.2/grid. Please rollback the existing identical patch first.

So first rollback above 4 patches by going to their directory and issuing with grid
owner from grid home:
opatch rollback -id 21948354 -local -oh /u01/app/oracle/12.1.0.2/grid (Repeat for all
4 patches)
Note: In some cases, weirdly, I had to shutdown the has services with root user before
patch rollback by using:
/u01/app/oracle/12.1.0.2/grid/bin/crsctl stop has -f
After this again run:
/u01/app/oracle/12.1.0.2/grid/OPatch/opatchauto apply
/stage/PSUpatch/22191349 -analyze -ocmrf /stage/ocm.rsp

If analyze command fail then use this with root user:

 $ORA_GI_HOME/crs/install/roothas.pl postpatch
It will start the has services too.
Then again run the analyze command as given above:
It will show something like:
Analyzing patch(es) on /u01/app/oracle/12.1.0.2/grid
Patch /stage/PSUpatch/22191349/21436941 successfully analyzed on
/u01/app/oracle/12.1.0.2/grid for apply.
Patch /stage/PSUpatch/22191349/21948341 successfully analyzed on
/u01/app/oracle/12.1.0.2/grid for apply.
Patch /stage/PSUpatch/22191349/21948344 successfully analyzed on
/u01/app/oracle/12.1.0.2/grid for apply.
Patch /stage/PSUpatch/22191349/21948354 successfully analyzed on
/u01/app/oracle/12.1.0.2/grid for apply.
Now you are good to apply the patch. Proceed to next step.

6 Apply the Patch: (Note: This should apply patch in both GI and RDBMS Home but its 60 min
unreliable in that sense so after this completes, we need to check opatch lsinventory to
make sure that it also applied patches in RDBMS Home)
As root user, execute the following command:
# /u01/app/oracle/12.1.0.2/grid/OPatch/opatchauto apply
/stage/PSUpatch/22191349 -ocmrf /stage/ocm.rsp

In case if it doesnt apply in RDBMS Home, then run:

/u01/app/oracle/product/12.1.0/db_1/OPatch/opatchauto apply
/stage/PSUpatch/22191349 -oh /u01/app/oracle/product/12.1.0/db_1 -ocmrf
/stage/ocm.rsp
Make sure the above applies both OCW and PSU patches. You can verify that from
opatch lsinventory. If only OCW patch is present in output and no PSU (which is likely
the case), then issue following from Oracle home with oracle database owner after
shutting down database:
/u01/app/oracle/product/12.1.0/db_1/OPatch/opatch apply -oh
/u01/app/oracle/product/12.1.0/db_1 -local /stage/PSUpatch/22191349/21948354
7 Loading Modified SQL Files into the Database: 60 min
% sqlplus /nolog
SQL> Connect / as sysdba
 SQL> startup
SQL> quit
% cd $ORACLE_HOME/OPatch
% ./datapatch -verbose
8 Check for the list of patches applied to the database.
SQL> select action_time, patch_id, patch_uid, version, status, bundle_series, description
from dba_registry_sqlpatch;