Here is a brief explanation on how to apply CPU(Critical Patch Update) in a dataguard environment
In this demo, I am applying PSU 11.2.0.4.2 on the Primary and standby databases.
Standby Database Name :ORCL_STBY
Primary Database Name : ORCL
Primary Server:
[oracle@PRIM ~]$ sqlplus sys
/
oracle@srprim as sysdba
SQL
*
Plus: Release
11.2
.
0.2
.
0
Production on Tue Sep
18
10
:
43
:
50
2012
Copyright (c)
1982
,
2010
, Oracle.
All
rights reserved.
Connected to:
Oracle Database
11g
Enterprise Edition Release
11.2
.
0.2
.
0
-
64bit
Production
With the Partitioning, Automatic Storage Management, OLAP, DataMining
and
Real
Application Testing options
SQL> select status,instance_name,database_role
from
v$database,v$instance;
STATUS INSTANCE_NAME DATABASE_ROLE
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
OPEN
ORCL
PRIMARY
Standby Server:
[oracle@STBY~]$ sqlplus /"
as sysdba"
SQL
*
Plus: Release
11.2
.
0.2
.
0
Production on Tue Sep
18
10
:
46
:
35
2012
Copyright (c)
1982
,
2010
, Oracle.
All
rights reserved.
Connected to:
Oracle Database
11g
Enterprise Edition Release
11.2
.
0.2
.
0
-
64bit
Production
With the Partitioning, Automatic Storage Management, OLAP, DataMining
and
Real
Application Testing options
SQL> select status,instance_name,database_role
from
v$database,v$instance;
STATUS INSTANCE_NAME DATABASE_ROLE
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
MOUNTED ORCL_STBY PHYSICAL STANDBY
Step 1:
As a first step we need to disable the log shipping from primary database to the standby
database by setting the log_archive_dest_state_2 to “defer” on the primary database.
SQL> alter system set log_archive_dest_state_2 = defer; System altered. |
Step 2:
Now Cancel the Managed Recovery Process on your standby database .
SQL> alter database recover managed standby database cancel; Database altered. |
Step 3:
CPU (Critical Patch Update)/ Patch Set patches always needs to be applied first on
the standby database and then on the primary database. In order to apply it on the
standby database, shutdown the standby database and also the listener running on
the standby server.
SQL> shutdown immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
[oracle@STBY ~]$ lsnrctl stop
[oracle@STBY ~]$ ps -ef | grep tns
oracle 6958 5107 0 10:52 pts/1 00:00:00 grep tns
[oracle@STBY ~]$
[oracle@STBY ~]$ ps -ef | grep pmon
oracle 6960 5107 0 10:52 pts/1 00:00:00 grep pmon
Step 4:
Now apply the CPU on the standby database.
[oracle@STBY ~]$ export PATH=$PATH:$ORACLE_HOME/OPatch
[oracle@STBY ~]$ opatch version
OPatch Version: 11.2.0.3.0
OPatch succeeded.
Step 5:
Unzip the downloaded patch file.
unzip p18031668_112040_<platform>.zip
cd 18031668
Verify pre-reqs:
opatch prereq CheckConflictAgainstOHWithDetail -ph ./
Now Apply Patch:
opatch apply
Step 6:
Once the patch has been applied on the standby database,
start the listener and the standby database.
[oracle@uat ~]$ lsnrctl start
[oracle@uat ~]$ sqlplus /"As sysdba"
SQL> startup mount
Step 7:
On Primary Database server, Start the archiving.
SQL> alter system set log_archive_dest_state_2 =enable ; |
System altered.
Note: Do not run any patching scripts on the standby database
(Example: catbundle.sql).
We are done with the patching on the standby database.
No comments:
Post a Comment