Re: Unsupported Recovery Technique......?
From: Frank van Bortel <frank.van.bortel_at_gmail.com>
Date: Thu, 20 Mar 2008 19:47:50 +0100
Message-ID: <8e8e3$47e2b156$524b5c40$14313@cache3.tilbu1.nb.home.nl>
>> 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
Fail to see what that has to do with the problem at hand?
Date: Thu, 20 Mar 2008 19:47:50 +0100
Message-ID: <8e8e3$47e2b156$524b5c40$14313@cache3.tilbu1.nb.home.nl>
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?
> > 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!
-- Regards, Frank van Bortel Top-posting in UseNet newsgroups is one way to shut me upReceived on Thu Mar 20 2008 - 13:47:50 CDT