Re: spfile used in RAC 10.2.0.4
- From: Chen Zhou <oracle.unknowns@xxxxxxxxx>
- To: Mark Bobak <Mark.Bobak@xxxxxxxxxxxx>
- Date: Thu, 5 Jun 2014 14:38:38 -0700
Mark and Riyaj,
Thank you for your quick response.
Chen
On Thu, Jun 5, 2014 at 1:40 PM, Mark Bobak <Mark.Bobak@xxxxxxxxxxxx> wrote:
> Hi Chen,
>
> When the database entry was created using ‘srvctl add database’, the
> spfile path was (probably) provided via the ‘-p’ flag. The database
> definition in the OCR contains the location of the spfile, and that’s how
> it can be located when you start with srvctl.
>
> As to resolving the problem, you should be able to go to one of the
> remaning nodes that are up, and do either ‘alter system set’ or ‘alter
> system reset’ and specify the SID of the instance that has the incorrect
> value in the spfile, to either update or remove that parameter for that
> instance. Then, just shutdown the problem instance, and you should be able
> to restart it with ‘srvctl’ and the default spfile.
>
> Then make a note to follow up with the other DBA on the correct value of
> that parameter, and when it can be implemented consistently across all db
> instances.
>
> As you learned, it can be dangerous to set a parameter in spfile only,
> if it’s value needs to be consistent across instances. Anytime you set
> such a parameter, it needs to be immediately before a complete DB bounce of
> all instances.
>
> Hope that helps,
>
> -Mark
>
> From: Chen Zhou <oracle.unknowns@xxxxxxxxx>
> Reply-To: Chen Zhou <oracle.unknowns@xxxxxxxxx>
> Date: Thursday, June 5, 2014 at 4:24 PM
> To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
> Subject: spfile used in RAC 10.2.0.4
>
> 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
>
>
>
>
Other related posts:
