Re: After applying PSU to clustered 11g home DB on node 2 cannot start.

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_at_tpg.com.au> 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_at_tpg.com.au> 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
>>
>>
>>
>
>

--
http://www.freelists.org/webpage/oracle-l