问题背景：
用户报障生产一套11G的RAC集群，每个节点有5个数据库实例，其中一个实例由于ORA-00600错误引发实例异常重启，在该实例重启之后，同服务器上的其他4个实例均出现无法访问的情况，应用反馈出现ORA-12537连接不上报错问题。
同时，数据库后台日志出现大量的ORA-27140、ORA-27300、ORA-27301、ORA-27302、ORA-27303报错。
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
ORA-27302: failure occurred at: skgpwinit6
ORA-27303: additional information: startup egid = 1001 (oinstall), current egid = 1006 (asmadmin)
最后，用户通过重启节点4个实例才恢复正常。
问题分析：
检查问题实例的重启时间，可以看到在18点08分35分-49秒期间实例发生了重启。
重启之后，其他实例在18点09分开始陆续出现报错，从报错的信息中可以看到，由于数据库启动使用的用户组oinstall与当前用户组asmadmin不一致，导致数据库执行操作失败，这里用户组权限指的是执行程序$ORACLE_HOME/bin/oracle的权限。
检查执行程序oracle的权限，可以看到程序文件权限为6751和oracle.asmadmin，这个权限是正确的，再看回报错内容信息ORA-27303: additional information: startup egid = 1001 (oinstall), current egid = 1006 (asmadmin)，可以推测实例在启动的时候oracle程序是使用了oinstall属组一直正常运行，直到18点09分之后oracle程序的属组变成了现在的asmadmin，引发用户数组不一致的问题。
从之前旧的trc文件属组，可以进一步确认之前实例启动的oracle程序属组为oracle。
问题分析到这里，有两个问题需要进一步确认。谁将oracle程序的属组oinstall修改成asmadmin？与问题实例的重启有没有联系？这里，我们单从问题发生的时间线以及报错发生的时间点，可以判断oracle程序的属组变化与问题实例的重启操作存在关系的概率较大。
接下来，分析问题实例的重启过程，由于实例的异常重启的，重新启库的过程是通过集群oracle_oraagent进程所拉起。检查oracle_oraagent的日志，在agent启动数据库的过程中，我们发现了一条关键的操作命令 /u01/app/grid/product /bin/setasmgidwrap oracle_binary_path
=/u01/app/oracle/product/bin/oracle，通过setasmgidwrap对oracle程序的权限进行修正，也就是问题实例异常关闭，重新启动的过程中，oracle_oraagent执行了命令setasmgidwrap对oracle程序的权限进行了修改，将oracle程序的属组oinstall修改为asmadmin，导致之前通过oinstall属组启动的其他实例属组出现不一致，数据库操作无法正常执行。
在Oracle官方文档After Dbca Database Creation, Other Database Terminated With ORA-27300/ORA-27301/ORA-27302/ORA-27303 (Doc ID 2406287.1)，描述了这一行为，在RAC集群环境，通过集群管理工具srvctl启动数据库实例，会更新oracle程序的属组为asm磁盘组的属组，确保两者属组一致。
问题复现测试：
为进一步确认分析原因的正确性，我们在测试环境进行了复现测试。
复现测试场景一：srvctl启动更新oracle程序属组。
手动修改$ORACLE_HOME/bin/oracle的执行程序为oinstall数组
通过startup方式启动数据库，数据库可以正常启动操作，oracle程序属组还是oinstall，只要oracle用户的属组里面有磁盘权限asmadmin组，就可以访问asm磁盘组，oracle程序属组为oinstall没影响。
通过集群管理工具srvctl方式启动数据库，数据库可以正常启动操作，这里可以看到oracle程序会被自动修正为asmadmin。
查看oracle_oraagent的trc日志，在srvctl启动过程中，会通过setasmgidwrap对oracle程序的权限进行修正，可以确认srvctl启动会修正oracle程序属组。
复现测试场景二：实例重启影响其他实例问题复现。
oracle执行程序设置为oinstall属组，通过startup方式启动两个实例test1和db11_1。
通过kill -9模拟实例test1异常重启。
test1异常重启之后，之前正常的实例db11_1无法正常访问，复现问题的报错ORA-27303: additional information: startup egid = 1000 (oinstall), current egid= 1001 (asmadmin)。
问题原因：
1 数据库实例在问题发生之前，oracle程序使用错误的oinstall属组启动。
2 问题实例异常重启之后，集群通过oracle_oraagent拉起实例，使用集群管理工具srvctl方式启动，启动过程会执行setasmgidwrap修正$ORACLE_HOME/bin/oracle 权限为正确的属组asmadmin。
3 调整后的权限asmadmin与现有实例启动的oinstall权限不一致，导致产生ORA-27303用户属组不一致的报错，数据库无法正常访问。
问题建议：
1 确保oracle执行程序的权限正确为6751和oracle:asmadmin。
2 CRS/HAS环境，数据库实例的启动要通过集群工具srvctl进行管理，避免采用startup等手工管理方式。
