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

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 

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 <mailto: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 <mailto: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 <mailto: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