ora-15055与ora-27303同时出现，根本原因是$oracle_home/bin/oracle文件属组非asmadmin或缺失setgid位，导致进程无法以正确egid访问asm；需检查并修复属组、权限、asm设备权限、asm_diskstring及has/crs状态。
ora-15055 和 ora-27303 同时出现，基本可以断定不是数据库配置问题，而是 oracle 二进制文件的属组权限错了——它必须是 asmadmin，不能是 oinstall 或 dba。
检查 $ORACLE_HOME/bin/oracle 的属组是否为 asmadmin
Oracle 12c 单实例或 RAC 环境中，DBCA 创建数据库时若报 ORA-15055: unable to connect ASM instance + ORA-27303: startup egid=... current egid=...，核心线索就在后半段的 egid 差异。这说明进程实际运行时的组 ID（egid）和期望值不一致。
根本原因：安装完成后，$ORACLE_HOME/bin/oracle 文件被意外修改过属组，比如从 asmadmin 变成了 oinstall 或 dba。ASM 实例启动依赖该文件的 setgid 位和正确属组来切换到 asmadmin 上下文，否则无法访问 ASM 设备。
- 执行
ls -l $ORACLE_HOME/bin/oracle，确认输出中属组字段是asmadmin，且权限含s（即-rwsr-x--x或类似） - 如果不是，立即修复：
chown oracle:asmadmin $ORACLE_HOME/bin/oracle && chmod 6751 $ORACLE_HOME/bin/oracle - 注意：必须是
asmadmin，不是asmdba或dba；RAC 环境下所有节点都要同步改 - 改完后重启监听和数据库实例（或整个 CRS，单实例可只重启
has）
验证 grid 用户对 ASM 设备是否有读写权限
即使 oracle 文件权限正确，grid 用户仍需能直接打开设备节点。DBCA 底层会通过 grid 身份调用 ASM 接口，若设备不可访问，同样触发连接失败。
- 先确认 ASM 设备路径：
asmcmd lsdsk或ls -l /dev/asm*（或/dev/mapper/*、/dev/oracleasm/disks/*，取决于配置） - 检查每个设备属主和权限：
ls -l /dev/asm-data01必须显示brw-rw---- 1 grid asmadmin（12c 默认）或grid:asmadmin+0660 - 若属主错误，用
chown grid:asmadmin /dev/asm-data01；权限不对则补chmod 0660 /dev/asm-data01 - 注意：裸设备路径（如
/dev/sdb）在重启后权限会丢失，必须靠 udev 规则固化
排查 asm_diskstring 是否匹配真实设备路径
ORA-15055 有时是假象——ASM 实例其实在运行，但 DBCA 找不到磁盘组，因为 ASM 根本没扫描到任何磁盘。最常见原因是 asm_diskstring 配置和实际设备路径对不上。
- 切到
grid用户执行：sqlplus / as sysasm→show parameter asm_diskstring - 对比真实设备路径：
ls /dev/asm*（或ls /dev/mapper/asm*），看前缀是否一致 - 若不一致（比如参数是
'AFD:*'但设备在/dev/asm-data01），立刻改：alter system set asm_diskstring='/dev/asm*' scope=both; - 再运行
asmcmd lsdsk，应有输出；若仍为空，说明设备层未就绪，回到上一步查权限和 udev
别忽略 HAS 或 CRS 进程状态（单实例尤其关键）
单实例环境下，ORA-15055 经常被误判为 ASM 权限问题，其实只是 has 进程压根没起来——没有它，ASM 实例就不会自动拉起，DBCA 自然连不上。
- 执行
ps -ef | grep has或crsctl check has，确认 High Availability Services 正在运行 - 若未运行，用 root 执行：
/u01/app/12.1.0/grid/crs/install/roothas.pl（路径按实际$GRID_HOME调整） - 成功后，
su - grid→sqlplus / as sysasm→SELECT state FROM v$asm_instance;应返回STARTED或MOUNTED - RAC 环境同理，但要用
crsctl check crs，且所有节点都得通
真正卡住人的地方，往往不是某一个权限设错，而是多个环节层层依赖：udev 没生效 → 设备权限回退 → asmcmd lsdsk 无输出 → asm_diskstring 白配 → oracle 属组再错 → DBCA 连接失败。必须从设备层开始顺推，跳过 SQL 就去查日志，大概率绕远路。
