Re: higher version Standby database?
- From: Chen Zhou <oracle.unknowns@xxxxxxxxx>
- To: mwf@xxxxxxxx
- Date: Thu, 26 Jun 2014 12:20:16 -0700
Mark,
Do you mean that if we can verify that the current 10.2.0.5 standby
database can be opened with no apparent problem, then we probably are fine
and should just proceed as usual to activate the standby with no extra
steps during maintenance?
Thank you,
Chen
On Thu, Jun 26, 2014 at 12:03 PM, Mark W. Farnham <mwf@xxxxxxxx> wrote:
> +1 on Hans' generally safe process and answer.
>
> On the specific case, do I understand you correctly that there is an
> instantiated 10.2.0.5.12 plus patches standby (correctly?) swallowing
> application of shipped redo?
>
> Trying to be clear: Oracle in no way guarantees or recommends anything but
> a complete match for this situation. That is primarily because they never
> know when they might need to make some change to redo format for any given
> reason, and if you are different in release and patches you might cross
> some incompatibility boundary.
>
> That being said, it is entirely possible the current standby is valid in
> the sense that nothing is broken. Unless you are one of the extended life
> support support options, I do not believe that is a supported release, so
> that is oddly a factor in your favor, since you have no support to
> invalidate by doing a non-standard process (that may in fact leave no
> evidence if it just works.) A *long* time ago it was pretty easy to find
> out exactly which patches and version moves even potentially involved redo
> format changes.
>
> They do not happen very often. I don't know whether it is easily possible
> to get someone from Oracle to tell you you're just fine across the small
> change update numbers and patches you've made. Even with changes you might
> be okay, for example, if the changes only affected lobs and you don't have
> any lobs. (Just an example.)
>
> SO this *might* work. IF you have room on the standby server, cancel
> recovery. Shut down the recovery database (all instances). Do a cold local
> clone of the database. Make a safety copy of the controlfiles and online
> redo logs on the standby (if you have redo logs on the standby). Then you
> do a startup rename reset redologs. If the clone of your standby opens
> correctly and stands up to diagnostics, then you have a plausible case for
> taking this shortcut. Setting compatible to make your current production
> has the best chance for not trashing your application query performance
> (which if you're doing this you do not have time to verify).
>
> SO if all that works, then you shutdown (planning to throw away) the clone
> you opened. That is its own recovery thread now and is useless going
> forward for recovery (although this was the basic for having a frozen
> reporting database on the standby machine prior to the advent of Active
> Dataguard. Apart from the cross version issue, that still works as long as
> you are okay with a frozen reporting database you refresh at need.)
>
> Resume recovery, lock users out, catch up, do a switch over, do
> diagnostics until you believe it is right (there really may be no going
> back once you allow transactions on the new thing, and I doubt you have
> time to check whether a fail back would work), and then I'd probably get a
> full backup of both the current production and the "new" production before
> turning it on for production use.
>
> *This is not ideal.* *You have been warned.* *Still, it could work.*
>
> Hans official way might be less trouble. You should probably add the
> pre-emptive backups to the official way when you do the plus-minus, and of
> course the test might go splat or I could have misunderstood and you do not
> have a slight version difference standby applying logs error free.
>
> mwf
>
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
> On Behalf Of Hans Forbrich
> Sent: Thursday, June 26, 2014 1:52 PM
> To: oracle-l@xxxxxxxxxxxxx
> Subject: Re: higher version Standby database?
>
> The Data Guard book from Oracle Press
> (http://www.amazon.ca/Oracle-Data-Guard-11g-Handbook/dp/0071621113) has a
> section that covers a scenario that might suit
>
> In a nutshell: create physical standby; convert to logical standby;
> upgrade standby; sync; switch
>
> /Hans
>
> On 26/06/2014 11:07 AM, Chen Zhou wrote:
> > Hi, Everyone,
> > A colleague of mine asked me if I knew what to do in this situation.
> > We have a 10.2.0.4 RAC system that needs to be migrated to better
> > servers. Because of other issues with the primary database, one
> > hurried decision led to anther, yet another, the end result is he ends
> > up having a 10.2.0.5 standby RAC database now. The goal is to
> > activate the standby and retire the primary database/servers. However
> > with the primary at 10.2.0.4 and standby at 10.2.0.5.12 with some
> > additional patches, both of us don't know what is a safe and sure way
> > to migrate in this situation.
> > Redo the standby would be the last choice due to time-constraint and
> > the stressed-out primary database.
> > Thank you in advance for sharing your thoughts.
> > Chen
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
Other related posts:
