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_
|
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
|
No comments:
Post a Comment