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@xxxxxxxxx> 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@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 >> >> >> >