Re: Upgrade Issue - ORA-00205: error in identifying control file

Well, no - I did not:

ORCL1_at_685921-db5:/u01/app/oracle/product/12.2.0/dbhome_1/bin $ ls -al oracle -rwsr-s--x 1 oracle oinstall 408114239 Jan 1 15:20 oracle

Helmut Hutzler has a blog post at
https://www.hhutzler.de/blog/ora-27303-during-startup-of-a-rac-database which refers to a similar issue. When I look at the 12.2 config.c in $ORACLE_HOME/rdbms/lib it shows:

#define SS_DBA_GRP "dba"
#define SS_OPER_GRP "oinstall"
#define SS_ASM_GRP ""
#define SS_BKP_GRP "backupdba"
#define SS_DGD_GRP "dgdba"
#define SS_KMT_GRP "kmdba"
#define SS_RAC_GRP "dba"

In the 12.1 software the same file shows:

#define SS_DBA_GRP "dba"
#define SS_OPER_GRP "oper"
#define SS_ASM_GRP ""
#define SS_BKP_GRP "backupdba"
#define SS_DGD_GRP "dgdba"
#define SS_KMT_GRP "kmdba"

Looking at the setasmgid executable in /etc/oracle using strings, the error I'm getting does not appear to be part of this operation. Note that I initially did not install the 11.2 database nor upgrade that to 12.1 so I'm still fighting a rearguard action with respect to users, groups and various ORACLE_HOME(s). Generally from what I'm reading, the error that may be caused by an incorrect group seems to manifest itself in not being able to read the spfile as opposed to not finding the controlfile because the disks are missing. It also appears to have been more of an issue in a pre-patched 11.2 instance than 12.x - although this DB did start life as an 11.2 database.

I'm going to try changing the ASM Compatibility first and see how far that takes me. I'll keep this in my back pocket.

Appreciate the insight.

On Wed, Jan 2, 2019 at 10:05 AM Michael J Pecoraro <mikejp_at_buffalo.edu> wrote:

> David,
>
> What is the value of the OS group for the DB "oracle" binary?
>
> $ ls -l $DB_ORACLE_HOME/bin/oracle
>
> Did you run setasmgidwrap ($GRID_HOME/bin/setasmgidwrap
> o=$DB_ORACLE_HOME/bin/oracle) as 'oracle' to set the DB HOME oracle
> binary's group to the OSASM group after the 12.2 installation? I suspect
> the DB oracle binary has a group value of 'oinstall' instead of
> 'asmadmin'. Assuming the primary group for your 'oracle' user is
> 'oinstall' and your OSASM group value set at installation is 'asmadmin'.
> I've seen this issue after installations or patching in the past when the
> DB oracle binary group is not set to the OSASM group.
>
> Mike
>
> ---
> Michael J Pecoraro
> University at Buffalo
> mikejp_at_buffalo.edu
>
>
> On 1/2/19 8:32 AM, David Barbour wrote:
>
> Thanks for the suggestions. In response to Hermant's query, yes - the GI
> and RDBMS homes ARE using two different accounts. GI is 'grid' and Oracle
> is 'oracle'. This is consistent with our on-site dev/test/qa RAC which is
> supposed to mimic the production RAC and which was upgraded without
> encountering this issue. However I will check permissions on the two
> systems to see what might be different. The production RAC is off-site and
> under the nominal administration of our third-party cloud provider and they
> have a history of changing permissions/mount options/ownership of certain
> critical filesystems, etc. particularly when they apply a Linux patch.
>
> In response to Stefan's question, I think we may have a winner? Here is
> the output from the diskgroup query and the database:
>
> Database:
> SQL> show parameter compatible
>
> NAME TYPE VALUE
> ------------------------------------ -----------
> ------------------------------
> compatible string 12.1.0
>
> ASM:
> SQL> select name, state, compatibility, database_compatibility
> 2 from gv$asm_diskgroup;
> NAME STATE COMPATIBILITY
> DATABASE_COMPATIBILITY
> ------------------------------ ----------- ---------------
> -------------------------
> ACTIVE CONNECTED 11.2.0.2.0 10.1.0.0.0
> ARCH CONNECTED 11.2.0.2.0 10.1.0.0.0
> DATA CONNECTED 11.2.0.2.0 10.1.0.0.0
> FRA CONNECTED 11.2.0.2.0 10.1.0.0.0
> OCRVTG MOUNTED 12.1.0.0.0 10.1.0.0.0
> ACTIVE CONNECTED 11.2.0.2.0 10.1.0.0.0
> ARCH CONNECTED 11.2.0.2.0 10.1.0.0.0
> DATA CONNECTED 11.2.0.2.0 10.1.0.0.0
> FRA CONNECTED 11.2.0.2.0 10.1.0.0.0
> OCRVTG MOUNTED 12.1.0.0.0 10.1.0.0.0
>
>
> On Tue, Jan 1, 2019 at 11:26 PM Hemant K Chitale <hemantkchitale_at_gmail.com>
> wrote:
>
>>
>> Are GI and RDBMS Oracle_Homes running with two different OS accounts ?
>> Probably the RDBMS OS Account does not have access.
>>
>> Hemant K Chitale
>>
>>
>>
>>
>> On Wed, Jan 2, 2019 at 8:47 AM David Barbour <david.barbour1_at_gmail.com>
>> wrote:
>>
>>> The diskgroups are definitely mounted:
>>>
>>> SQL> select name, state from v$asm_diskgroup;
>>>
>>> NAME STATE
>>> ------------------------------ -----------
>>> ACTIVE MOUNTED
>>> ARCH MOUNTED
>>> DATA MOUNTED
>>> FRA MOUNTED
>>> OCRVTG MOUNTED
>>>
>>> and in ASMCMD I can see the correct controlfiles:
>>> ASMCMD> pwd
>>> +data/orcl/CONTROLFILE
>>> ASMCMD> ls
>>> current.334.821879157
>>> ASMCMD> pwd
>>> +arch/orcl/CONTROLFILE
>>> ASMCMD> ls
>>> current.272.820415093
>>>
>>>
>>> On Tue, Jan 1, 2019 at 6:28 PM David Barbour <david.barbour1_at_gmail.com>
>>> wrote:
>>>
>>>> Of Course. Happy New Year All.
>>>>
>>>> Anyone run into this? Upgrading 12.1.0.2 to 12.2.01 on RAC w/ASM
>>>>
>>>> ASM has been upgraded to 12.2.0 several weeks ago.
>>>>
>>>> Installed new 12.2 software in new home. Altered spfile to
>>>> cluster=FALSE, moved password files, etc, shut down the instances, tried to
>>>> start from the new home and get this:
>>>>
>>>> SQL> startup upgrade
>>>> ORACLE instance started.
>>>>
>>>> Total System Global Area 2.7488E+11 bytes
>>>> Fixed Size 29874920 bytes
>>>> Variable Size 3.2212E+10 bytes
>>>> Database Buffers 2.4213E+11 bytes
>>>> Redo Buffers 506994688 bytes
>>>> ORA-00205: error in identifying control file, check alert log for more
>>>> info
>>>>
>>>> Alert log shows:
>>>>
>>>> Errors in file
>>>> /u01/app/oracle/diag/rdbms/orcl/ORCL1/trace/ORCL1_m000_11372.trc:
>>>> ORA-00202: control file: '+DATA/orcl/controlfile/current.334.821879157'
>>>> ORA-17503: ksfdopn:2 Failed to open file
>>>> +DATA/orcl/controlfile/current.334.821879157
>>>> ORA-15001: diskgroup "DATA" does not exist or is not mounted
>>>> ORA-15040: diskgroup is incomplete
>>>> ORA-00210: cannot open the specified control file
>>>> ORA-00202: control file: '+ARCH/orcl/controlfile/current.272.820415093'
>>>> ORA-17503: ksfdopn:2 Failed to open file
>>>> +ARCH/orcl/controlfile/current.272.820415093
>>>> ORA-15001: diskgroup "ARCH" does not exist or is not mounted
>>>> ORA-15040: diskgroup is incomplete
>>>>
>>>> But the diskgroups are mounted:
>>>> ora.ARCH.dg
>>>> ONLINE ONLINE 685921-db5 STABLE
>>>> ONLINE ONLINE 685925-db6 STABLE
>>>> ora.DATA.dg
>>>> ONLINE ONLINE 685921-db5 STABLE
>>>> ONLINE ONLINE 685925-db6 STABLE
>>>>
>>>> Ideas? Can't seem to find a similar issue with an exception that a TDE
>>>> Wallet is not configured properly. This database had a tablespace using
>>>> TDE over a year ago, but that has been eliminated and there is no wallet
>>>> any longer.
>>>>
>>>>
>>>>
>>>>

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