RE: 9i DataGuard, RAC primary - secondary offline for networkmaintenance
- From: Carel-Jan Engel <cjpengel.dbalert@xxxxxxxxx>
- To: ric.van.dyke@xxxxxxxxxx
- Date: Wed, 06 Dec 2006 08:35:54 +0100
Ric,
I agree that the redo stream is likely not to cause any problems.
Generally spoken applying redo of a previous version
(restoring/recovering just after an upgrade) is not a problem at all.
However, what if you run a database Read/Write (as primary) and the
code-stack (ORACLE_HOME) is patchlevel x, but the database is patchlevel
x-1? The Oracle code resides for a great deal in the dictionary. Just
patching Oracle home is not enough. The database will not start up
correctly with all combinations of x and x-1, as you will experience
when you:
1. install Oracle software with installer and including 'creation'
of a predefined database
2. install the patches to move to the latest version
3. startup the instance using this just 'created' database
The database is not created, but restored from a clone that comes with
the installation CD.
I forgot the exact error, and have no time to find out right now, but
the database needs a startup migrate and running catpatch before it is
usable. Was the 9.2.0.6 -> 9.2.0.7 upgrade an ORCALE_HOME upgrade only,
i.e. an empty or no catpatch.sql at all? I've no 9.2.0.7 at hand, and
need to drive off now.
Bottomline:
Unless the combination of codestack x and database x-1 has been tested
very carefully (and I THINK this cannot be tested completely) I wouldn't
jeopardize my VITAL database with such a setup.
Best regards,
Carel-Jan Engel
===
If you think education is expensive, try ignorance. (Derek Bok)
===
On Tue, 2006-12-05 at 19:15 -0600, Ric Van Dyke wrote:
> Carel-Jan,
>
>
>
> You are very correct that as stated in the documentation the version
> of Oracle are supposed to be the same (as in identical) on the primary
> and the standby. However I worked with the folks who developed the
> standby database code and this is more of a CYA requirement then a
> real one. There was some long discussions about this requirement and
> I believe that “paranoia” won out, the idea being it’s better to be
> over restrictive then not. The issue is more about the format of the
> redo log stream then anything else. It’s very likely that this setup
> will work just fine. And given that Tony (apparently) has been running
> with this setup for some period of time, it’s again likely that this
> will continue to work just fine.
>
>
>
> The escape clause for Oracle should Tony run into bazaar problems will
> likely be that the versions of Oracle are different in his
> configuration. However I figure it’s very unlikely that this will
> cause an issue. Currently I agree that if your production system
> needs a certain patch level then having a standby at a different patch
> level is at least odd.
>
>
>
>
> Ric Van Dyke
>
> Hotsos Enterprises
>
> -----------------------
>
> Hotsos Symposium March 4-8, 2007. Be there.
>
>
>
> ______________________________________________________________________
>
> From:oracle-l-bounce@xxxxxxxxxxxxx
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Carel-Jan Engel
> Sent: Tuesday, December 05, 2006 5:46 PM
> To: tony@xxxxxxxxxxxxxxx
> Cc: oracle-l
> Subject: Re: 9i DataGuard, RAC primary - secondary offline for
> networkmaintenance
>
>
>
>
>
> Hi Tony,
>
> See inline
> On Tue, 2006-12-05 at 22:09 +0000, Tony Sequeira wrote:
>
>
>
> Hi all,
>
> I have a 2 node 9i RAC primary (Win 2003), 9.2.0.6 mandated by the
> application.
>
> Have a physical standby 9.2.0.7.
>
> All appears to be going well, teething problems over (touch wood).
>
>
> Cross your fingers. Oracle DOESN'T support DG environments with
> different versions. It appears you haven't checked the prerequisites
> carefully enough.
>
> Your standby database is not 9.2.0.7, mind that you never did a
> startup migrate and ran catpatch.sql for 9.2.0.7 on the primary. Since
> your standby is a physical copy of the primary, this database is
> 9.2.0.6 as well. I don't know why you keep the standby (probably for
> High Availability reasons), but switching/failing over to it might pop
> up some surprises. 'Results are unpredictable' is the right phrase
> here. I cannot emphasize enough that an HA configuration needs
> SYMMETRY. You're violating this rule#1 here.
>
>
>
>
> The primary is running in maximum performance mode.
>
> The secondary server is due to go down for about 24 hours for absolutely
> vital electrical maintenance work.
>
> I believe that this will be OK, and that the secondary will catch up
> when brought online again.
>
>
> Yes, no problem. Not that you can use it, effectively it is
> unavailable as long as you have this mixed version setup running. I
> have never investigated the combination of a failover/switchover with
> startup migrate/run catpatch. It might work. Please test it and share
> your experiences.
> There is one big assumption involved in your theory: You have to keep
> the archived redo log files long enough for the standby to fetch them
> after it switched on again, As Ric Van Dyke posted while I am writing
> this.
>
>
>
>
>
>
>
> Any think or know different? I'm trying to plan for any glitches now,
> the primary database is a vital 24/7 system.
>
>
> If so, either upgrade your primary to 9.2.0.7 or install 9.2.0.6 at
> the standby. You don't want surprises at the eve of failover with a
> vital 24x7 system.
>
>
>
>
> I am aware of Note:259804.1 - particularly the section 'Real
> Application Clusters and Data Guard Redo Apply During a Network Outage'.
>
>
>
> Get aware of
> http://download-uk.oracle.com/docs/cd/B10501_01/server.920/a96653/considerations.htm#52221
> , 3rd bullet, too.
>
>
>
> Best regards,
>
> Carel-Jan Engel
>
> ===
> If you think education is expensive, try ignorance. (Derek Bok)
> ===
>
>
>
>
>
Other related posts:
