RE: higher version Standby database?

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