Version 12.1.0.2 to 12.2.0.1 [Related Doc ID 2406287.1 ]
You may get in the alert log something like:
ORA-27140: attach to post/wait facility failed ORA-27300: OS system dependent operation:invalid_egid failed with status: 1 ORA-27301: OS failure message: Operation not permitted (OR ORA-27301: OS failure message: Not owner) ORA-27302: failure occurred at: skgpwinit6 ORA-27303: additional information: startup egid = 1001 (oinstall), current egid = 1006 (asmadmin) Process J000 died, see its trace file
This happens due to srvctl command changing the ownership of the
RDBMS ORACLE_HOME oracle binary while it is being used during a new database installation or the first usage of the srvctl command for a clone created database.
BACKGROUND:
The databases created by cloning using RMAN or for some other miscellaneous reason, might have the wrong ownership for the oracle binary. By wrong, I mean it might have a different group than the one used for the asm disks ownership. Therfore, the oracle binary in the RDBMS ORACLE_HOME is updated on startup via srvctl to have the same group as the disks used for the ASM.
For example, the oracle might have the oracle:oinstall ownership as follows:
[oracle]$ ls -ltrh $ORACLE_HOME/bin/oracle -rwsr-s--x 1 oracle oinstall 311M Sep 14 2018 /u01/app/oracle/product/12.1.0.2/dbhome_1/bin/oracle
However, the ASM disk are owned by grid:asmadmin as follows:
[root]# ls -ltrh /dev/dm* brw-rw---- 1 grid asmadmin 249, 17 Mar 19 14:44 /dev/dm-1 brw-rw---- 1 grid asmadmin 249, 14 Mar 19 14:45 /dev/dm-2 brw-rw---- 1 grid asmadmin 249, 12 Mar 19 14:45 /dev/dm-3 brw-rw---- 1 grid asmadmin 249, 6 Mar 19 14:46 /dev/dm-4 .. .
This configuration can still be working for several reasons… The oracle user might be in asmadmin group, the ACFS is used on top of ASM.. etc. The thing is that, creating a database with DBCA after the fact, will start the database with srvctl effectively setting the group of the oracle binary in the RDBMS ORACLE_HOME to match the ASM disks. (MOS Doc)
This is expected. However, this will also cause the running databases from the same home to terminate, due to the group change on the binary. (MOS Doc)
SOLUTION:
1.Stop all the databases
2. Set the correct ownership for the oracle binary: As the grid user, run the following command to update the oracle binary to the correct group in the RDBMS home:
$GI_HOME/bin:> setasmgidwrap o=<RDBMS_HOME>/bin/oracle
3. Start all the databases