My server rebooted itself and when it came back up, none of the databases or ASM had restarted. Everything is 11.2.0.3 or 11.2.0.1 with ASM being 11.2.0.3 - so Oracle Restart should have kicked in.
As usual, any identifying names, servers, domains, databases etc have been obfuscated to protect the innocent.
|
|
The LOCAL_LISTENER
parameter is incorrect, it should be ‘myserver.mydomain.com:1899’ with a ‘.com’ and not ‘.net’.
We have a problem in the spfile that needs to be fixed. Where is it located so that it can be converted to a pfile and corrected? The usual place to check is $ORACLE_HOME/dbs
.
|
|
It isn’t in the normal location, what does Oracle Restart know?
|
|
The spfile name may also be listed in the alert.log as part of a startup. It is for me in this case:
|
|
Now we have a “Catch 22 chicken and egg” problem. The spfile is located inside ASM and we can’t start ASM to extract and fix it, because we need the (broken) parameter file to start ASM.
There are numerous blog postings on the internet that explain how to start ASM, or extract the spfile, when the spfile it needs to start is in ASM, but due to a missing $GRID_HOME/gpnp/myserver/profiles/peer/profile.xml
file, those were not an option here. (I think the problem is that the profile.xml
is used by RAC only.)
On a normal database, you can create a pfile from the spfile even if the instance is not running. Will that work?
|
|
That was expected, but it had to be tried!
Method 1
Maybe a default pfile can be created from the alert log’s listing of the non-default startup parameters from the last time it started?
|
|
So that’s one way of extracting the non-default startup parameters into a temporary pfile, for those awkward times when you cannot get at the spfile to start ASM as the spfile is located within ASM itself. Extract the above settings from the alert.log and startup with that temporary pfile. Once started, create a new spfile, update Oracle Restart and Robert is your mother’s brother.
However, depending on how long ASM has been up, what’s to say that any of the listed parameters are still valid? After all, since startup, someone changed the LOCAL_LISTENER
parameter and it was only when the instance next started up that the foul up became apparent.
Method 2
There is another way. Thinking, as they say outside the box (Yuk! I avoid cliches like the plague!) about how tnsnames.ora allows IFILE
commands, suggests that perhaps Oracle might allow me to create a pfile which specifies the existing spfile name and lets me set the correct LOCAL_LISTENER
parameter to overwrite the broken setting in the spfile?
I confess, I also had a very vague recollection from way back when spfiles were first introduced, that I had seen/read/heard/tried something like this already, but as mentioned, it was a very vague recollection! Nevertheless, let’s create a plain vanilla pfile:
|
|
The correction goes after the spfile, so that it takes effect rather than being overridden by the broken one in the spfile - assuming this trick works!
|
|
We have a running ASM system!
Fix the broken parameter in the existing spfile:
|
|
A shutdown and restart later and the spfile is once more working correctly.