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@xxxxxxxxx>
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@xxxxxxxxx>
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@xxxxxxxxx>
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.
