upgrade to 11203 some grains of sand

Yesterday we did the upgrade from to PSU 3 as discussed earlier on this blog using a parallel environment with a logical standby. Just before activating the logical standby after testing that everything was correctly applied i made a guaranteed restore point.

2012-10-24 02:38:23.921000 +02:00
Created guaranteed restore point BEFORE_PRIM

Everything went fine and after testing the switchovers of the database it was the last step that had to be performed increase compatible to 11.2.0. 
First on the standby databases and then on the primary.
as explained here

This went perfectly fine on the standby databases.

Then it was the primary's turn….  

alter system set compatible = '11.2.0' scope=spfile ;

ok and then restart …

oracle complained about the fact that there was a restore point created when db was running with compatible….
ok no problem i'll change it back to in spfile and  drop the restore point ….

hmmm the db compatible wasn't changed in the db but was in the spfile… 
ok no problem will create pile ….and adapt that one …

oracle says it cannot do that because the spfile is in 11.2.0 WTF…

ok no problem start in nomount  and 

create pfile from memory

create pile = '/tmp/initfile'  from memory ;

edit the file startup with compatible  and drop the restore point. 
remove all the _ parameters you didn't set and make sure that in case of RAC, node specific parameter are back... which wasn't the case ...

had manually define 


HTH if you encounter this issue 

note is was around 4 am in the morning when we encountered this ....

So bottom-line pre compatible version restore points prevent the compatible parameter to be set ....


Popular posts from this blog

evmd not starting in oracle restart

Converting a TDE encrypted NON CDB to PDB

19c Data Guard Series Part III adding a PDB to and existing Data Guard configuration