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

From: David Barbour <david.barbour1_at_gmail.com>
Date: Wed, 2 Jan 2019 07:32:09 -0600
Message-ID: <CAFH+iff--Q1K31VBvLzT5=KXO1XFS9z0506kiY6hxWAaKbsKTA_at_mail.gmail.com>



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
Received on Wed Jan 02 2019 - 14:32:09 CET

Original text of this message