在Oracle RAC环境下管理密码文件时，有几个关键点必须严格把控，遗漏任何一项都可能导致隐患。简单概括就是：确认密码文件存放在ASM存储且文件类型为ASM，切勿再用orapwd在各节点单独生成，同步操作只认asmcmd pwcopy或统一软链接指向ASM文件，并且务必把remote_login_passwordfile设为SHARED。搞定这几个环节，就能从根源上解决密码文件不同步引发的登录问题。
确认密码文件是否被集群识别为共享文件
别凭感觉猜测，直接执行查询。在grid用户下运行 srvctl config database -d ，重点关注输出中的 password file 字段。如果显示的是本地路径（如 /u01/app/oracle/product/19c/db_1/dbs/orapwcdb1），说明配置有误；若该字段为空或直接报错，则集群根本未将密码文件纳入管理。接着补充检查 select * from v$passwordfile_info;——返回结果必须仅有一行，且 type 列为 asm，file_name 是形如 +data/cdb1/password/pwdcdb1.256.123456789 的ASM路径。这一步确认无误后，后续处理才能顺理成章。
避免使用 orapwd 在各节点分别生成文件
说起orapwd，这堪称19c RAC管理中极易踩雷的操作之一。在各节点分别通过orapwd生成密码文件，初衷虽好，但它创建的其实是本地独占式（EXCLUSIVE）二进制文件，内部绑定唯一的SCN及其他结构信息。即便你将文件内容完全复制过去，RAC各节点也无法跨节点共享加载。更糟糕的是，如果指定路径写成了 $ORACLE_HOME/dbs/orapw$ORACLE_SID，该文件极有可能被集群直接忽略，或启动时被ASM托管文件覆盖。最终结果是：你在一个节点修改密码后，只有该节点认新密码，其他节点依然沿用旧密码，执行 sqlplus / as sysdba 时会弹出 ORA-01017 或 ORA-12641 这类令人头疼的错误。
只采用两种Oracle官方认可的同步方式
方式一（推荐）：利用 asmcmd pwcopy 进行原子级同步。首先在主节点执行 ALTER USER sys IDENTIFIED BY newpass;（此步骤后面还会再强调），然后通过 asmcmd pwcopy +DATA/CDB1/PASSWORD/pwdcdb1.256.123456789 /tmp/pwdcdb1 将文件导出，经scp传输至其他节点，再反向执行 pwcopy /tmp/pwdcdb1 +DATA/CDB1/PASSWORD/pwdcdb1.256.123456789。注意：必须使用 pwcopy 而非 cp，否则文件的元数据和内部校验可能损坏，导致文件拷贝成功但实际无效。
方式二（最稳妥）：统一创建软链接指向ASM文件。让所有节点的 $ORACLE_HOME/dbs/orapw$ORACLE_SID 均指向同一ASM路径，例如执行 ln -sf +DATA/CDB1/PASSWORD/pwdcdb1.256.123456789 $ORACLE_HOME/dbs/orapwcdb1。此软链接必须由 oracle 用户创建，同时确保 remote_login_passwordfile=SHARED 已生效，通过 srvctl modify database -d cdb1 -p "remote_login_passwordfile=SHARED" 完成设置。
修改SYS密码后必须重新生成并分发，不能仅依赖 ALTER USER
很多人以为，在某个节点上执行一条 ALTER USER sys IDENTIFIED BY xxx 就万事大吉。实则不然——该命令只更新数据字典中的记录，密码文件并未发生任何变化。RAC各节点间的密码文件不会自动同步，DG主备之间也不会复制。因此，修改SYS密码后，必须立即用 orapwd 重建密码文件，参数中加入 file='+DATA/ORCL/PASSWORD/pwdrac19c' format=12.2 force=y，然后通过 pwcopy 或软链接方式覆盖所有节点。对于RAC多节点、DG主备多实例的场景，每个实例名对应的 orapw 都必须严格匹配，遗漏任何一个就会引发 ORA-16191 等同步错误。
还有一个容易忽略的细节：密码文件的时间戳更新了，并不代表内容也随之更新。即使你刚刚把文件拷贝过去，若未使用 force=y 重建或未走 pwcopy 流程，文件中存储的仍可能是旧口令。这一点千万不要想当然。
