ORA-01017或ASMPWD远程登录失败大概率因ASM口令文件节点间不一致，必须用asmcmd pwcopy同步而非scp；各节点$ORACLE_HOME/dbs/orapw+ASM需存在、非零、属主grid:asmadmin且md5一致，并确保remote_login_passwordfile=EXCLUSIVE已设。
ORA-01017 或节点间无法远程登录 ASMPWD 时，大概率是 ASM 口令文件在各节点不一致或未同步 —— 这不是密码输错，而是文件内容本身不统一，必须手动校验并覆盖。
确认各节点ASM口令文件是否真的存在且路径一致
oracle rac 中每个节点的 asm 实例都依赖本地 $oracle_home/dbs/orapw+asm（注意：不是 orapw<sid></sid>，而是固定名为 orapw+asm），该文件必须由 pwcopy 同步，不能靠 scp 复制或手工编辑。
- 在每个节点上执行：
ls -l $ORACLE_HOME/dbs/orapw+ASM，确认文件存在、大小非零、属主为grid:asmadmin - 检查内容一致性：
md5sum $ORACLE_HOME/dbs/orapw+ASM，所有节点输出必须完全相同 - 若某节点缺失或 md5 不匹配，说明该节点口令文件已失效，后续任何
sqlplus / as sysasm都会报ORA-01017
用 pwcopy 覆盖而非 scp 同步
ASM 口令文件不是普通二进制文件，它含内部校验和与实例绑定信息；直接 scp 会导致 ORA-15283 或登录后无法执行 ALTER DISKGROUP 等操作。
- 从一个已知正常的节点（如 node1）导出：
asmcmd pwget --asm +DATA/orapw+ASM（假设口令文件存于+DATA） - 再用
pwcopy推送到其他节点对应位置：asmcmd pwcopy +DATA/orapw+ASM +DATA/orapw+ASM_node2，然后在 node2 上执行：asmcmd pwcopy +DATA/orapw+ASM_node2 $ORACLE_HOME/dbs/orapw+ASM - 切记：不能跳过 ASM 层直接写入磁盘组路径；
pwcopy会自动更新内部签名，scp不会
验证口令文件是否被 ASM 实例真正加载
即使文件存在且 md5 一致，ASM 实例也可能因启动顺序或参数未生效而未加载最新口令文件 —— 此时 sqlplus / as sysasm 成功但权限受限（例如无法 DROP DISK）。
- 重启 ASM 实例（非整个 CRS）：
crsctl stop res ora.asm -n <node_name></node_name>，再crsctl start res ora.asm -n <node_name></node_name> - 连接后检查：
SELECT username, sysasm FROM v$pwfile_users;，确保SYS行的SYSASM列为TRUE - 若仍为
FALSE，说明口令文件未被识别，需重新执行pwcopy并确认remote_login_passwordfile=EXCLUSIVE在 ASM 的 spfile 中已设置（可通过strings $ORACLE_HOME/dbs/spfile+ASM.ora | grep remote_login快速验证）
避免误删或覆盖 ASM 口令文件的典型陷阱
RAC 环境下最常踩的坑是把 ASM 口令文件和数据库实例口令文件混为一谈，或在打补丁/升级后忽略其独立性。
-
orapw+ASM和orapw<db_sid></db_sid>完全无关，修改数据库口令文件不影响 ASM 登录 - 执行
opatch apply后，$ORACLE_HOME/dbs/orapw+ASM可能被重置为空文件（尤其 Grid Infrastructure 补丁），务必在 patch 后立即校验 md5 - 不要在
asmcmd中用ls +DATA直接找orapw+ASM—— 它可能以别名形式存在（如orapwASM或大小写不一致），正确方式是pwget --asm +DATA/orapw+ASM，该命令会自动解析别名
ORA-15000（权限不足）或静默拒绝命令，必须逐节点用 pwcopy + 重启 ASM 实例来闭环验证。
