Re: Unsupported Recovery Technique......?

On Mar 20, 11:47 am, Frank van Bortel <frank.van.bor..._at_gmail.com> wrote:
> bdbafh wrote:
> > On Mar 19, 11:01 pm, mc..._at_hotmail.com wrote:
> >> 10g Release 2
>
> >> I have cloned a 10.2.0.1 database onto a 10.2.0.3 home by using a cold
> >> backup and recreating the controlfile.  During the 'alter database
> >> open resetlogs' the instance crashes because of the version mistmatch:
>
> >> ORA-00704: bootstrap process failure
> >> ORA-39700: database must be opened with UPGRADE option
> >> Thu Mar 20 02:46:27 2008
>
> >> I then run:
>
> >> startup mount
> >> alter database open upgrade
>
> >> and then upgrade the database to 10.2.0.3 with
>
> >> @$ORACLE_HOME/rdbms/admin/catupgrd.sql
>
> >> Everything appears OK.
>
> >> My question is.......  is this a supported procedure..?  Is there a
> >> danger that the database is corrupted in some way after performing
> >> this restore/upgrade step together....?
>
> >> Incidentally, I also used this technique to restore an RMAN backup
> >> from 10.2.0.1 to 10.2.0.3 and used exactly the same technique (alter
> >> database open upgrade).  This also seemed to work fine but is it a
> >> supported/stable approach..?
>
> >> Thanks
>
> > Interesting.
> > What is the value for the parameter "compatible" in the spfile/
> > init.ora when you're recovering the cloned database backup set?
>
> > (guessing)
> > Perhaps setting that to 10.2.0.1 during the "open resetlogs" phase
> > might prevent the database needing to be opened with the UPGRADE
> > option.
>
> Fail to see what that has to do with the problem at hand?

I believe Paul was postulating that the db wouldn't receive the error if the compatible was set to the older version, and so could open the db without upgrading. Then maybe if he had to move the db to the original version if the future he could. This strikes me as kind of asking the db to have inconsistencies in it due to different things happening depending on version, since I'm not convinced how really global the compatible parameter is - I have a vague recollection of Jonathan Lewis mentioning something about that in his blog, at least regarding optimizer code paths. Who knows what bugs such a mix (unupgraded db with later software) would bring? That would have to be unsupported, if even possible.

>
>
>
> > After the logs have been reset, then startup upgrade and execute the
> > upgrade script ...
>
> That's what he did, didn't he?
>
> And to OP and Sybrand: this seems like a normal, manual
> upgrade to me, somewhat oddly started with a database
> that wasn't there originally.
>
> But the procedure is standard: first you upgrade the
> software tree, then the instances. You instance did
> not need an open resetlogs, as it was a cold backup.
> It just needed startup in upgrade mode, and the
> update scripts allied.
> Of course, real DBA's do not use GUIs!

:-)
Nothing unreal exists.

jg

--
@home.com is bogus.
I want a pony.  http://www.signonsandiego.com/uniontrib/20080320/news_1b20fraud.html