spfile used in RAC 10.2.0.4

From: Chen Zhou <oracle.unknowns_at_gmail.com>
Date: Thu, 5 Jun 2014 13:24:42 -0700
Message-ID: <CAJUY3dTMniUdmg3c=0PzAPo3X3cAtW2vq0w2Tzs0QkFHjp=acQ_at_mail.gmail.com>



Hi, Experts,

We have a 3-node 10.2.0.4 RAC on Solaris 10. One node crashed due to ORA-600 [kturacf1] error. The main DBA of this database was out, so I had to bring it up.

I can see in the alert log of that instance the DBA had run a command to change a parameter in the scope of spfile (alter system set db_file_name_convert='+DG1,+DG1
' scope=spfile) sometime ago.
When I tried a bring up the instance with "srvctl start instance" command, in the alert log I can see that changed parameter db_file_name_convert takes the new value and is different from what the value is in the other 2 nodes. So that discrepancy prevents the instance from being open. In alert log, it also shows spfile is set to the common spfile on ASM.

My question #1 is how did srvctl find this spfile file?. In the $ORACLE_HOME/dbs directory, there is only 1 init file. This init file does NOT point to the common spfile, which exists on ASM. So it seems to me srvctl does not go to $ORACLE_HOME/dbs to look for spfile/pfile, rather it seems to "remember" where the spfile was when the instance was up last time. Or it looks at the other 2 nodes and finds out where the command spfile is?

I ended up using sqlplus to start the instance with the local init file. Now I have one instance running with pfile, 2 other instances running with spfile. And the parameters match fine currently. So db_file_name_convert is unset. However at the next bounce, the other 2 nodes will try to take on the new value for db_file_name_convert, and the discrepancy will prevent them from starting up.
So my question #2 is if there is a rolling way changing this parameter or all non-system modifiable parameters. It doesn't seem possible to change it without shutting all 3 nodes down then bringing them up. Is it so?

Thank you,
Chen

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Jun 05 2014 - 22:24:42 CEST

Original text of this message