Yesterday we did the upgrade from 10.2.0.3 to 11.2.0.3 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 11.2.0.3 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 10.2.0.3….
ok no problem i’ll change it back to 10.2.0.3 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 10.2.0.3 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
instance1.thread
instance2.thread=…
….
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 ….
