Welcome Guest ( Log In | Register )


 
 
 
 
 
 

 
 
Oracle 

Performance Tuning Reference poster
 
Oracle training in Linux 

commands
 
Oracle training Weblogic Book
 
Easy Oracle Jumpstart
 
Oracle training & performance tuning books
 
Burleson Consulting Remote DB Administration
 
 
> CPU patch procedure with physical and logical standby database in place
cbaron
post Dec 12 2008, 03:46 PM
Post #1


Newbie
*

Group: Members
Posts: 2
Joined: 22-June 05
Member No.: 2,352



Hello all,

I've placed a similar post in Oracle's forums, but figured I might be better off posting here. Here goes:

I'm trying to compile a decent set of steps for applying the CPUOCT2008 patch to our production RAC cluster which has both a logical and physical standby in place. I've read a tonne of documentation, including the CPU readme, DOCID 437276.1 and 278641.1. I''ve also read through the Upgrading Databases in a Data Guard Configuration chapter of Dataguard Concepts and Administration. The last doc mentioned is really for upgrading a full version of Oracle rather than applying a CPU (at least I think that's the case). DocID 437276.1 is rather sparse on details.

I guess what I'm trying to understand is the proper method for applying the patch with the logical standby in place. The physical standby looks pretty straightforward. After running opatch on it as well, it will basically have all of the changes applied to the primary shipped over and applied as per the normal primary/standby relationship. Will the same be true for the logical (having applied the patch, and then re-enabling SQL apply)? Should I aim to have it work that way? By that I mean start it up and re-enable sql apply and then upgrade the primary. Or, am I to apply the catcpu.sql script to it as well before re-enabling the sql apply? Am I wrong in regards to the physical standby as well i.e. should the catcpu also be applied directly to it?

BTW, I do have a copy of the Rampant Press Dataguard book sitting in front of me, and unfortunately nowhere inside does it cover this. I did look at least ;-)

Thanks very much in advance.

Cheers,
Chris
Go to the top of the page
 
+Quote Post
 
Start new topic
Replies
HAL9000
post Dec 12 2008, 07:06 PM
Post #2


Advanced Member
***

Group: Members
Posts: 880
Joined: 25-September 07
Member No.: 12,336



Chris see this, titled "Applying Patch Sets / Interim Patches with Physical Standby Database in Place "

http://ayyudba.blogspot.com/2007/12/applyi...im-patches.html

QUOTE
Procedure to Apply a Patch Set with physical Standby Database in Place
========================================================================

1. Log in to the oracle account on both the primary and standby hosts and make
sure the environment is set to the correct ORACLE_HOME and ORACLE_SID.

2. On both the primary and standby host uncompress and untar the downloaded
patch set / interim patch file into a new directory.

3. Shut down the existing Oracle Server instance on the primary host with normal
or immediate priority. Stop all listeners, agents and other processes running
against the ORACLE_HOME. If using Real Application Clusters perform this step
on all nodes.

SQL> shutdown immediate
% agentctl stop
% lsnrctl stop

4. Cancel managed recovery on the standby database.

SQL> recover managed standby database cancel;

5. Shutdown the standby instance on the standby host. Stop all listeners,
agents and other processes running against the ORACLE_HOME. If using Real
Application Clusters perform this step on all nodes.

SQL> shutdown immediate
% agentctl stop
% lsnrctl stop

6. Run the Installer and install the patchset on both primary and standby host.

% ./runInstaller

If this is an interim patch, run opatch per the patch README.

If using Real Application Clusters, be sure the install has propagated to
the other nodes if using private ORACLE_HOMEs. Please see the Patch
Set readme for specific instructions.

7. Once the patchset/patch has been installed on on all hosts / nodes startup
the standby listener standby host.

% lsnrctl start

8. Startup nomount the standby database.

% sqlplus "/ as sysdba"
SQL> startup nomount

9. Mount the standby database.

SQL> alter database mount standby database;

10. Place the standby database in managed recovery mode.

SQL> recover managed standby database nodelay disconnect;

11. Startup the primary instance on the primary host.

% sqlplus "/ as sysdba"
SQL> startup migrate

12. Ensure that remote archiving to the standby database is functioning correctly
by switching logfiles on the primary and verifying that v$archive_dest.status
is valid. If you are not performing remote archiving make note of the
current archive log sequence.

SQL> alter system archive log current;
SQL> select dest_id, status from v$archive_dest;

13. On the primary instance run the following script:

SQL> @?/rdbms/admin/catpatch.sql

For the interim patch, run any scripts as outlined in the README.

14. Once the catpatch.sql script / patch SQL scripts completes make note of the
current log sequence and issue the following command:

SQL> alter system archive log current;

15. Verify the standby database has been recovered to the log sequence from
step 12.

SQL> select max(sequence#) from v$log_history;

16. On the primary instance run the following command:

SQL> alter system disable restricted session;

17. Complete the remainder of the "Post Install Actions" from the Patch Set
readme on the primary host. Please note that it is not necessary to shudown
the standby in conjuction with the primary during the "Post Install Actions".

18. Once all "Post Install Actions" have been completed verify the standby
database has been recovered to the last archive log produced by the primary.

On the primary:

SQL> select max(sequence#) from v$archived_log;

On the standby:

SQL> select max(sequence#) from v$log_history;
Go to the top of the page
 
+Quote Post



Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 

Lo-Fi Version Time is now: 20th October 2014 - 03:02 AM