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 |
9 Comments. Leave new
Fahd –
In step 7, does the database need to be started in upgrade mode for datapatch to be executed?
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
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.
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.
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?
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 ?
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
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
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.