ORA-01017：用户名或密码错误——背后其实有五种可能
密码明明没改过，应用突然全员报 ORA-01017。用同样的密码在服务器本地能登，远程就不行；换个工具又行了。密码错误这个报错，一半时候密码本身没问题。这篇文章把真实遇到的五种原因和处理命令一次讲完。
文章目录
- ORA-01017：用户名或密码错误——背后其实有五种可能
- 一、报错现象
- 二、原因一：密码真的错了
- 三、原因二：密码含特殊字符，被 shell 转义了
- 四、原因三：密码过期，客户端只笼统报登录失败
- 五、原因四：密码大小写敏感（11g 的分水岭）
- 六、原因五：远程 as sysdba 登录，密码文件的问题
- 七、验证
- 八、预防
一、报错现象
ORA-01017: invalid username/password; logon denied先说一个设计细节：这个报错故意不区分"用户不存在"和"密码错误"，防止别人靠报错信息枚举出有效用户名。所以看到 01017，用户名和密码两个方向都要怀疑。
二、原因一：密码真的错了
概率最大的一种，但"真的错了"往往错得隐蔽：
- 复制密码时带上了首尾空格或换行符
- 配置文件里密码项被截断（properties 文件值里多写了个反斜杠）
- 多套环境密码不同步，应用连的其实是测试库
在数据库端直接验证，排除传输路径干扰：
# 在数据库服务器本机直连验证（绕开 tnsnames）sqlplus scott/你的密码@localhost:1521/orcl服务器上能进、客户端不行 → 直接跳到原因二、四、五排查。
三、原因二：密码含特殊字符，被 shell 转义了
密码是Be@2024!x，直接敲命令：
sqlplus scott/Be@2024!x@orcl必挂。@会被 sqlplus 解析成"连接串开始了"，!在交互式 bash 里还会触发历史扩展。这不算 Oracle 的锅，是 shell 和连接串解析规则的坑。
正确写法——整个连接串用单引号包住，密码部分再用双引号：
sqlplus'scott/"Be@2024!x"@orcl'拆解：外层单引号防 shell 动手脚；双引号告诉 Oracle 这一段是密码字面量，里面的@不当作连接串分隔符。
几个变体场景：
# 密码里有双引号本身：密码 Ab"cdsqlplus'scott/"Ab""cd"@orcl'# 密码里有单引号：密码 Ab'cdsqlplus"scott/\"Ab'cd\"@orcl"# 写进脚本里推荐用 heredoc，彻底避开转义sqlplus /nolog<<'EOF' connect scott/"Be@2024!x"@orcl select user from dual; EOF应用代码里（JDBC）不需要 shell 转义，直接传字面量即可，别把 shell 的转义习惯带进去。
四、原因三：密码过期，客户端只笼统报登录失败
11g 起PASSWORD_LIFE_TIME默认 180 天，密码到期后：
- 宽限期内登录：报
ORA-28002: the password will expire within N days，能登录 - 彻底过期后：报
ORA-28001: the password has expired，登录被强制要求改密
坑在于不少客户端（老版 JDBC 驱动、某些报表工具）把 28001/28002 处理成笼统的"登录失败"，界面上一眼看过去和 01017 没区别。
确认账号状态：
SELECTusername,account_status,expiry_date,profileFROMdba_usersWHEREusername='SCOTT';account_status一览：
| 状态 | 含义 |
|---|---|
| OPEN | 正常 |
| EXPIRED(GRACE) | 宽限期内，尽快改密 |
| EXPIRED | 已过期，必须重设密码 |
| LOCKED(TIMED) | 失败次数超限被锁（见系列第 19 篇） |
处理——重设密码（想保持原密码就再设成原密码）：
ALTERUSERscott IDENTIFIEDBY"新密码";五、原因四：密码大小写敏感（11g 的分水岭）
11g 开始默认sec_case_sensitive_logon = TRUE，密码区分大小写。10g 时代建的账号、老脚本里全大写的密码，升级后突然就登不上了。
验证参数与改法：
-- 查看当前设置SHOWPARAMETER sec_case_sensitive_logon-- 临时切回不区分大小写（10g 行为）ALTERSYSTEMSETsec_case_sensitive_logon=FALSESCOPE=BOTH;注意这里有个更深的坑：该参数为 FALSE 时，Oracle 用旧版不区分大小写的密码哈希来校验。如果账号在 11g 之后设过密码、密码文件里只剩新版哈希（password_versions 只有11G/12C），设成 FALSE 后反而谁都登不上。看一下哈希版本：
SELECTusername,password_versionsFROMdba_usersWHEREusername='SCOTT';如果只有新版，先重设一次密码让 Oracle 生成双版本哈希，再切换参数。长远做法是通知所有持有方改用正确大小写的密码，而不是依赖 FALSE 兜底。
六、原因五：远程 as sysdba 登录，密码文件的问题
典型症状：本地完全正常，远程不行：
# 在数据库服务器上——成功sqlplus / as sysdba# 从客户端——ORA-01017sqlplus sys/密码@192.168.1.10:1521/orcl as sysdbaas sysdba的远程认证不走数据字典，走的是密码文件（orapw 文件）。以下情况都会报 01017：
- 密码文件不存在或被误删
- 密码文件被重建过，里面的密码和当前 sys 密码不一致
remote_login_passwordfile设成了 NONE（等于禁用远程 sysdba）
排查三步：
-- 1. 有没有人登记在密码文件里SELECT*FROMv$pwfile_users;-- 2. 参数设置（应为 EXCLUSIVE）SHOWPARAMETER remote_login_passwordfile# 3. 密码文件是否存在（Linux 路径，文件名 = orapw + 实例名，区分大小写）ls-l$ORACLE_HOME/dbs/orapworcl修复——用 orapwd 重建（12c 及以后加force=y覆盖已存在文件）：
orapwdfile=$ORACLE_HOME/dbs/orapworclpassword=新密码entries=10force=y说明：
entries是可容纳的 sysdba 用户数上限- EXCLUSIVE 模式下 sys 改密码会同步写回密码文件；SHARED 模式多个库共用一个密码文件且不能
GRANT SYSDBA，现代环境基本只用 EXCLUSIVE
顺带一句：普通用户远程登录不走密码文件，普通用户的 01017 和这里无关，别往 orapw 上查。
七、验证
按原因逐条闭环：
# 原因二：转义写法直连成功sqlplus'scott/"Be@2024!x"@orcl'@验证.sql-- 原因三、四：账号状态与哈希版本SELECTusername,account_status,password_versionsFROMdba_usersWHEREusername='SCOTT';# 原因五：远程 sysdba 登录成功sqlplus sys/密码@192.168.1.10:1521/orcl as sysdba-- 应用连接数恢复，登录失败告警清零SELECTmachine,COUNT(*)FROMv$sessionWHEREusername='SCOTT'GROUPBYmachine;八、预防
- 密码变更走流程单：数据库改密、应用配置、配置中心、值班手册四处同步，任何一处漏掉就是凌晨告警
- 含特殊字符的密码，脚本统一走 heredoc 或参数文件，禁止裸拼在命令行里
dba_users的account_status、expiry_date纳入每日巡检，EXPIRED(GRACE) 提前一周告警- 密码文件纳入备份范围（
$ORACLE_HOME/dbs/orapw*），重建后立即用远程 sysdba 登录验证一次 - 应用账号与运维账号分开建 profile：应用账号密码永不过期（单独 profile 管控），运维账号保留密码有效期策略
✅ 亮点：把 01017 拆成"密码本身、shell 转义、过期、大小写、密码文件"五种真实原因，每种附最小验证命令；特别指出 11g 大小写敏感与哈希版本的连环坑、EXCLUSIVE/SHARED 密码文件的区别。扩展方向：代理认证（proxy user）、统一认证接入 LDAP/Kerberos 替代密码管理。
