RE: Different Oracle patchlevels between primary and (physical) s tandby

Andre,  

If you are using a shared SAN, you can do this server switch very easily without even using a standby. Outside of configuring the new server (with OS, OS patches, backup, swap, os config, etc), all you will need to do is set the right zones, make sure that only one server (old or new) sees the disks at any point of time. The upgrade can then be done later once the new server stabilizes.... We have done this many a time with no issues - downtime is brief when the old server is shutdown and the new server is brought up with the old filesystems.... (This is not to take away Carel's usual and excellent advice though!)  

Cheers,
John Kanagaraj <><
DB Soft Inc
Phone: 408-970-7002 (W)  

Fear connects you to the Negative, but Faith connects you to the Positive! I Jn 4:18  

• The opinions and facts contained in this message are entirely mine and do not reflect those of my employer or customers **

  ---

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Carel-Jan Engel
Sent: Thursday, August 25, 2005 12:44 PM To: awinssen_at_xs4all.nl
Cc: oracle-l_at_freelists.org
Subject: Re: Different Oracle patchlevels between primary and (physical) standby

Andre,

Actually you are describing the way Oracle describes upgrades in a Data Guard config. See metalink note 187242.1

I don't like the method described in the note, unless you have at least two standby's.

The reason is that you might end up with two unusable databases if something goes wrong during the execution of catpatch.sql. It might be a hardware failure, or even (however very unlikely, isn't it Mladen) a bug that reveals itself during the excution of catpatch or shortly thereafter.

I create new ORACLE_HOMEs on both ends, containing the patched software. Then I shutdown the standby, and finish the upgrade on the primary (startup migrate, run catpatch and whatever needs to be done). If something goes wrong, the only thing I need to do is restarting (activating) the standby, using the 'old' ORACLE_HOME, and point the application to the standby. This delivers minimal interuption of service after a failover.

If everything goes right, the upgraded DB is brought into service. When the users are satisfied as well, the standby is either started from the 'new' ORACLE_HOME and will catch up with the primary, or, it is re-instantiated from the primary.

Best regards,

Carel-Jan Engel

===
If you think education is expensive, try ignorance. (Derek Bok) ===

On Thu, 2005-08-25 at 20:52 +0200, Andre van Winssen wrote:

Hi,  

The production db I am looking after has to move to a new server. Because downtime is not appreciated (!) my first idea was to build a physical standby of the current production db on the new server and then do a switchover. This has the benefit that most of the work can be done in the background, only at failover time will production be affected for a short period.  

As I would also like to patch the current db to a higher level (from 9.2.0.5 to 9.2.0.6 + interimpatch or 9.2.0.7 if available) I want to try following:

on the standby server I will install the patched Oracle version, and after the failover has been done I will follow the normal db upgrade procedure against the new primary db, i.e. startup migrate and running catpatch.sql  

So this means that there will be a discrepency in Oracle version between primary and standby while the redo logs are shipped and applied.  

Of course everything will be tested properly first but still am wondering if anyone tried this before  

Regards,

Andre van Winssen  

--
http://www.freelists.org/webpage/oracle-l