Re: higher version Standby database?
Date: Thu, 26 Jun 2014 12:28:34 -0700
Message-ID: <CALgGkeDg46xhtCo-rvPH-MFyKc6VBrtJZg54Oi7JiV4MJCkoQw_at_mail.gmail.com>
To be clear, I think you mean primary at 10.2.0.4; standby currently at 10.2.0.5, correct?
I think the only (supported) way is 10.2.0.4 -> 10.2.0.4, switch over, apply patch set. (Have to rebuild standby to 10.2.0.4)
You could try SR, but I don't think you'll get very far if above is correct.
GL,
Rich
On Jun 26, 2014 12:22 PM, "Chen Zhou" <oracle.unknowns_at_gmail.com> wrote:
> 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_at_rsiz.com> 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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
>> On Behalf Of Hans Forbrich
>> Sent: Thursday, June 26, 2014 1:52 PM
>> To: oracle-l_at_freelists.org
>> 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
>>
>> --
>> http://www.freelists.org/webpage/oracle-l
>>
>>
>> --
>> http://www.freelists.org/webpage/oracle-l
>>
>>
>>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Thu Jun 26 2014 - 21:28:34 CEST