Well, no - I did not:
ORCL1@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@xxxxxxxxxxx>
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@xxxxxxxxxxx
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@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.
