Oracle数据库用户密码与Linux系统用户密码无关，修改oracle系统账户密码不影响数据库登录；重置SYSTEM/SYS密码需用SQL命令ALTER USER，并注意12c+版本的大小写敏感和密码复杂度要求。
Oracle数据库用户密码和Linux系统用户密码是两回事
很多朋友在Linux环境下部署了Oracle后，看到系统里有个oracle用户，很容易产生一个误解：是不是修改这个系统账户的密码，就能同步改掉数据库里SYS或SYSTEM的登录凭证？答案是否定的。这完全是两套独立的认证体系。
oracle这个用户，本质上只是用来安装和运行数据库软件的操作系统账户。它的权限在于文件系统、进程管理，并不直接参与数据库内部用户身份的验证。所以，即便你用passwd oracle命令改了系统密码，对于通过SQL*Plus连接数据库这件事，是没有任何影响的。数据库压根不认这个。
真正要改的是Oracle数据库内的用户密码
那么，想重置SYSTEM或SYS这类核心管理用户的密码，正确姿势是什么？必须进入数据库内部，执行标准的SQL命令。当然，前提是你得有一个具备足够权限的账户（通常是另一位DBA用户）能先连进去。
- 第一步，建立连接：使用类似
sqlplus / as sysdba的命令（这要求当前登录的Linux用户属于dba组，且Oracle监听服务正常）。 - 第二步，执行修改：连接成功后，运行
ALTER USER system IDENTIFIED BY new_password;即可。 - 一个关键提醒：对于
SYS用户，语法虽然一样，但在Oracle 12c及之后的版本中，即使修改了密码，远程登录通常仍需指定AS SYSDBA身份，仅凭密码可能无法直接连接。
说到这里，一个典型的错误场景就清晰了：有人兴冲冲地执行了passwd oracle，回头发现SQL*Plus还是连不上，于是怀疑是不是数据库需要重启。其实不然，问题根源在于你修改的密码，数据库根本就不校验。
什么时候才该用root切到oracle用户并执行passwd
既然改系统密码不影响数据库，那passwd oracle这个操作到底在什么场景下才有实际意义呢？主要集中在操作系统层面的管理需求：
- 场景一：系统登录受阻。当你忘记了
oracle账户的Linux系统密码，导致无法通过su或ssh切换到该用户去启动监听器或数据库实例时。 - 场景二：文件系统操作授权。需要让其他运维人员临时以
oracle身份操作特定文件，比如查看诊断日志、修改网络配置文件$ORACLE_HOME/network/admin/tnsnames.ora等。 - 场景三：自动化脚本配置。在一些自动化运维脚本中，为确保能通过SSH免密方式切换到
oracle用户，可能需要先重置或设定其系统密码。此时修改的是Linux系统/etc/shadow文件中的条目。
操作流程通常是：先sudo su -切换至root权限，再执行passwd oracle。务必记住，这一切都发生在数据库“大门”之外，与门内的登录密码是两条平行线。
容易被忽略的关键点
事情还没完，在修改数据库用户密码时，还有几个细节容易踩坑，尤其是在较新的Oracle版本中。
首先，密码复杂度与大小写。从Oracle 12c开始，默认启用了密码区分大小写功能，并且内置的密码验证函数会强制要求一定的复杂度（例如，必须包含数字和特殊字符）。如果你试图用ALTER USER设置一个像“123”这样的简单密码，很可能会遇到ORA-28003: password verification failed这类错误。临时解决方案是，可以先禁用密码验证函数：ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION NULL;，完成密码修改后再恢复。
其次，认证方式的影响。如果数据库配置了Oracle Wallet（钱&包）或外部认证（例如，通过参数OS_AUTHENT_PREFIX设置），那么传统的密码认证可能根本不起作用。这时候，光改密码是没用的。更需要关注的是V$PWFILE_USERS视图中的信息，以及sqlnet.ora配置文件里SQLNET.AUTHENTICATION_SERVICES的设定。搞清楚当前生效的认证方式，才能对症下药。
总之，理清操作系统账户和数据库用户之间的界限，是Oracle运维中一项基础却至关重要的认知。混淆二者，往往会让简单的密码重置问题变得扑朔迷离。
