Step-by-step guide to January 2016 PSU patch apply on 12c drid and RDBMS homes in Linux

Posted in: Oracle, Technical Track

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:

 

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

15 min
2 Create ocm.rsp file:

 

Note: Press Enter/Return key and don’t 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

5 min
3 Validation of Oracle Inventory

 

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.

5 min
4 Stage the Patch:

 

$ 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 min
5 One-off Patch Conflict Detection and Resolution:

 

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.

 

 

 

 

10 min
6 Apply the Patch: (Note: This should apply patch in both GI and RDBMS Home but its 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 doesn’t 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

60 min
7 Loading Modified SQL Files into the Database:

 

% sqlplus /nolog

SQL> Connect / as sysdba

SQL> startup

SQL> quit

% cd $ORACLE_HOME/OPatch

% ./datapatch -verbose

60 min
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;

5 min
email

Author

Want to talk with an expert? Schedule a call with our team to get the conversation started.

About the Author

I have been in love with Oracle blogging since 2007. This blogging, coupled with extensive participation in Oracle forums, plus Oracle related speaking engagements, various Oracle certifications, teaching, and working in the trenches with Oracle technologies has enabled me to receive the Oracle ACE award. I was the first ever Pakistani to get that award. From Oracle Open World SF to Foresight 20:20 Perth. I have been expressing my love for Exadata. For the last few years, I am loving the data at Pythian, and proudly writing their log buffer carnivals.

9 Comments. Leave new

Shawn McElhinney
February 12, 2016 10:18 am

Fahd –
In step 7, does the database need to be started in upgrade mode for datapatch to be executed?

Reply
Shawn McElhinney
February 12, 2016 2:15 pm

another interesting discovery I had on my end – if your hostname is in UPPERCASE you will likely encounter bug 21454505. This surfaces as a false negative error stating opatchauto can’t get enough info on a prior failure. If you run (as root) “hostname ” this error will cease.

We’ll have fun with this until 12.2.0.1.0

Reply

Hi Shawn,
Thanks for reading the post and your comment. No, there is no need to start the database in upgrade mode for step 7. Thanks.

Reply

I got an error when running datapatch that told me that I needed to be in upgrade mode. However this is for OCT16 PSU, not Jan.

Adding patches to installation queue and performing prereq checks…
Installation queue:
The following patches will be rolled back:
23177536 (Database PSU 12.1.0.2.160719, Oracle JavaVM Component (JUL2016))
The following patches will be applied:
24315824 (Database PSU 12.1.0.2.161018, Oracle JavaVM Component (OCT2016))
24006101 (Database Patch Set Update : 12.1.0.2.161018 (24006101))

Error: prereq checks failed!
patch 23177536: The database must be in upgrade mode
patch 24315824: The database must be in upgrade mode
Prereq check failed, exiting without installing any patches.

After shutting down and starting in upgrade mode it ran successfully.

Reply
Brijesh Akula
March 1, 2016 3:31 pm

Can we still apply the patch in non-auto mode without using the response file. Oracle patch readme does not seem to have an option for it.
Will be interesting to see how to apply PSU on GI without root access?

Reply

Can you recall, when you applied the PSU and it was not applied to the database home, had there been a database created at that time, or was it a software only installation ?

Reply

Hi,

I apply DBBP12.1.0.6.160419 in Exadata database node.

But when i run ./datapatch i have this

Installing patches…
Patch installation complete. Total patches installed: 1

Validating logfiles…
Patch 22806133 apply (pdb EDW2P): WITH ERRORS
logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/22806133/19983161/22806133_apply_BIEDW_EDW2P_2016Jun18_20_35_06.log (errors)
Error at line 15013: ORA-01031: insufficient privileges
Error at line 19725: ORA-47401: Realm violation for GRANT on SYS.DBMS_RLS
Error at line 84253: ORA-01031: insufficient privileges
Error at line 84318: ORA-01031: insufficient privileges
Error at line 84368: ORA-01031: insufficient privileges
Error at line 84440: ORA-01031: insufficient privileges

Please refer to MOS Note 1609718.1 and/or the invocation log
/u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_128513_2016_06_18_20_32_35/sqlpatch_invocation.log
for information on how to resolve

When people try to connected in database this they have this error: restricted session

Could do help me please

Best Regards

Reply

Hi Fahad ,

thanks for detailed blog post appreciated , moreover i have noticed emocmrsp file is not available in the latest opatch version , is it deprecated , do we still need to create ocm file for psu patches on 12c ?

kindly advise

Regards,
Sam

Reply

Doc ID 966023.1.
The binary is in database home. you can run the command and copy that to grid home OPatch directory.

./emocmrsp -no_banner -output $ORACLE_HOME/OPatch/ocm.rsp
chmod 775 ocm.rsp

Patch document says its mandatory.

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *