Tony,
I'm not sure what clusterware's behavior is without the database being
registered as a resource. This actually might be your problem. The whole
reason for clusterware is to manage the interconnected pieces so you don't
have issues like this. Is there a reason you are not registering your
databases as resources?
Seth
On Thu, Apr 27, 2017 at 10:25 AM, De DBA <dedba@xxxxxxxxxx> wrote:
Hi Seth,
I look at the v$controlfile (when it's actually running of course). The
database itself is not RAC, just the infrastructure. In fact it is not even
registered with crs as a resource. With this configuration, does it still
use the gpnp profile to start it?
Cheers,
Tony
On 28/04/17 01:51, Seth Miller wrote:
Tony,
What source are you getting the control file name from?
Remember that clusterware uses the the gpnp profile to determine what
parameter file to use to start an instance so the source you are looking at
might not be the same as clusterware's source.
Seth
On Thu, Apr 27, 2017 at 8:45 AM, De DBA <dedba@xxxxxxxxxx> wrote:
Well.. no. That is the other thing that surprises me.. the control file
has a normal ASM name like +DATA/.. The ASM devices are /dev/dm-* and owned
by grid:asmadmin, as you would expect.
Yet in the log file the multipath device appears. I would have thought
that the underlying devices would perhaps be known to +ASM, but why should
client instances know anything about the underlying devices?
Cheers,
Tony
On 28/04/17 01:12, Mladen Gogala wrote:
Hmmmm, the name of the control file apparently doesn't conform to ASM
standards:
ORA-15025: could not open disk "/dev/mapper/HDD_E0_S00_372178872p1"
Can you try with naming the control file like
'+DGROUP/dbname/CONTROLFILE/control1.ctl'? Your control file has a name
of a real multi-path device, which cannot be owned by grid:asmadmin. You
should use asmadm to check the disk group and database for the control file
name.
Regards
On 04/27/2017 10:06 AM, De DBA wrote:
Hi,
I'm applying a PSU to a clustered home for the 1st time in my life and of
course hit a snag.. This is 11.2.0.4 database on a 2-node ASM (12.1.0.2 )
cluster on an ODA and I am applying the 11.2.0.4 October 2016 PSU. All
databases are single-node, just ASM is clustered. I am patching only the
database homes, not ASM.
I ran opatch on node 1 and it propagated automatically to node 2. Before
the patch, both nodes had databases running without errors.
Opatch reported no errors on either node.
After the patch, I can restart the databases on node 1 without problems
and run the post-install actions, but on node 2 start attempts end in
ORA-205 "Error identifying control file". In the alert log are masses of
errors like this:
…
Thu Apr 27 23:42:51 2017
ALTER DATABASE MOUNT
NOTE: Loaded library: System
ORA-15025: could not open disk "/dev/mapper/HDD_E0_S00_372178872p1"
ORA-27041: unable to open file
Linux-x86_64 Error: 13: Permission denied
Additional information: 9
…
I checked the permissions/ownership of the oracle executable, but that is
the same on both nodes. The file permissions on the disk devices are also
the same and ASM has never gone down during or after patching. I'm
stumped...
Cheers,
Tony
--
Mladen Gogala
Oracle DBA
Tel: (347) 321-1217
