用orapwd修改SYS密码会覆盖整个密码文件，仅保留指定的SYS密码，清空其他所有sysdba/sysoper用户权限。
用 orapwd 修改 SYS 密码会覆盖整个密码文件
oracle 的 sys 用户密码实际存在两个地方：数据字典（dba_users）和外部密码文件（orapw$oracle_sid）。当你用 orapwd 命令重置，它不是“更新”，而是重建密码文件——所有已授权的 sysdba/sysoper 用户都会被清空，只剩你指定的 sys 密码生效。
常见错误现象：ORA-01031: insufficient privileges 在远程连接时突然出现，但本地 sqlplus / as sysdba 仍能进。这是因为远程依赖密码文件，而你刚用 orapwd 把其他用户（比如 system 或自定义 DBA 账号）的 sysdba 权限删掉了。
-
orapwd必须在数据库关闭或静默状态下运行（非必须但强烈建议），否则新文件可能不被立即加载 - 参数
force=y才能覆盖已有文件；缺省是force=n，会报错OPW-00005: Password file already exists - 如果用了
ignorecase=y，密码将不区分大小写——这会影响密码强度策略，且无法通过 SQL 语句反向控制
ALTER USER sys IDENTIFIED BY 只改数据字典，不影响密码文件
这条语句只更新 sys 在 DBA_USERS 中的密码哈希，对 orapw$ORACLE_SID 文件完全无感。也就是说：本地 / as sysdba 还能进，远程连接也照常——前提是密码文件里存的还是旧密码。
使用场景很明确：你只想让 sys 用户下次登录数据库时用新密码，但不想动任何外部权限配置，也不影响其他 DBA 账户的 sysdba 授权状态。
- 执行后无需重启实例，也不需要重载密码文件
- 若数据库启用了
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE，该语句不会同步到密码文件，远程仍需用旧密码连sys - 如果误设为
SHARED，ALTER USER甚至不允许修改sys密码，直接报ORA-01994: GRANT failed: password file missing or disabled
什么时候该用哪个？看你的认证路径
关键判断点就一个：你的应用或 DBA 是怎么连上 sys 的？
- 本地
sqlplus / as sysdba→ 走操作系统认证，不读密码文件，ALTER USER就够了 - 远程
sqlplus sys/password@db as sysdba→ 必须依赖密码文件，此时只改ALTER USER没用，必须用orapwd同步 - 有多个 DBA 账户被授予
sysdba（如backup_dba），且都靠密码文件登录 →orapwd会把他们全踢掉，得手动用GRANT SYSDBA TO backup_dba补回来
性能与兼容性影响很小，但顺序错了就白忙：先 ALTER USER 再 orapwd 是安全的；反过来，orapwd 后再 ALTER USER，远程连 sys 用的还是密码文件里的旧密码，容易造成“以为改了，其实没生效”的错觉。
最容易被忽略的细节：密码文件路径和权限
Oracle 不会自动找密码文件位置，它严格按规则拼接：$ORACLE_HOME/dbs/orapw$ORACLE_SID（Linux/Unix）或 %ORACLE_HOME%\database\orapw%ORACLE_SID%（Windows）。哪怕你把文件放在别处并用 init.ora 指定 remote_login_passwordfile 路径，只要文件名不匹配 SID，就等于没生效。
- Linux 下密码文件权限必须是
640，属主oracle:oinstall，否则实例启动时报ORA-01990: error opening password file - Windows 下要注意文件是否被杀毒软件锁定，
orapwd执行成功但后续连接失败，十有八九是这个原因 - 多租户环境（CDB/PDB）中，
orapwd只作用于 CDB root，PDB 的sys密码独立管理，不能靠它同步
改完密码，别急着通知所有人，先用 sqlplus sys/newpass@tns_alias as sysdba 和 sqlplus / as sysdba 各试一次，确认两条路都通——这才是真正生效的信号。
