SEC_CASE_SENSITIVE_LOGON 是 Oracle 11g 及更早版本控制密码大小写敏感的数据库参数，默认为 TRUE，修改后需重启生效；12c 起废弃，密码默认区分大小写且不可关闭。
SEC_CASE_SENSITIVE_LOGON 是什么，它在哪起作用
这个参数只存在于 oracle 数据库 11g 及更早版本（12c 起已废弃），控制数据库层面的密码校验是否区分大小写。它不是应用层开关，也不是操作系统或客户端设置——改了它，alter user ... identified by 创建/修改的密码才真正按大小写敏感方式存储和比对。
常见错误现象：用户说“我输的是 Password123，但报错 ORA-01017：invalid username/password”，而实际密码是 Password123（首字母大写），但数据库里存的是 password123（全小写）；或者反过来，应用连不上，但 SQL*Plus 能登——大概率是客户端连接时没触发大小写校验逻辑，而数据库本身已设为敏感。
- Oracle 11g 默认值为
TRUE（即区分大小写），但很多老系统在升级后被手动设为FALSE，导致新创建用户密码不区分大小写 - 12c 及以后版本该参数被移除，所有密码默认区分大小写，且无法关闭
- 它不影响密码策略（如复杂度、过期），只影响登录时的字符串比对行为
怎么查和改 SEC_CASE_SENSITIVE_LOGON
必须用具有 SELECT_CATALOG_ROLE 或 DBA 权限的用户执行，普通用户查不到：
SHOW PARAMETER sec_case_sensitive_logon
或
SELECT value FROM v$parameter WHERE name = 'sec_case_sensitive_logon';
修改需重启生效（静态参数），不能在线改：
- 临时生效（仅当前实例，重启丢失）：
ALTER SYSTEM SET sec_case_sensitive_logon = FALSE SCOPE=MEMORY;—— 不推荐，不可靠 - 永久生效：
ALTER SYSTEM SET sec_case_sensitive_logon = FALSE SCOPE=SPFILE;，然后重启数据库 - 如果用 PFILE 启动，直接编辑
init.ora文件，添加或修改sec_case_sensitive_logon=FALSE
注意：设为 FALSE 后，新创建用户的密码会自动转成小写存储（即使你输入 MyPass123，存进数据字典的是 mypass123）；已有用户密码不受影响，仍按原样比对。
为什么改了参数，用户还是登不上
因为密码校验发生在多个环节，SEC_CASE_SENSITIVE_LOGON 只管最后一步——数据库服务端比对。前面环节可能已经“吃掉”大小写：
- 某些 JDBC 驱动（特别是老版本 ojdbc6）在连接字符串里加了
uppercasePassword=false，会强制把密码转小写再发给服务端 - 应用代码里做了
password.toLowerCase()再传给连接池，等于白设参数 - Oracle Wallet 或外部认证（OS auth、LDAP）完全绕过该参数，不走这套校验流程
- 数据库链接（DB Link）发起的远程登录，用的是远端数据库的参数设置，不是本地的
典型误判场景：DBA 把参数改成 TRUE，但应用日志显示连接时传的是全小写密码——问题不在数据库，而在应用或驱动层。
12c+ 迁移时最常踩的坑
从 11g 升级到 12c，SEC_CASE_SENSITIVE_LOGON 参数消失，所有密码强制区分大小写。很多系统崩溃就因为这个：
- 旧脚本里硬编码了小写密码（比如
conn scott/tiger），而 12c 中用户实际密码是Tiger123，直接报 ORA-01017 - 备份恢复后，11g 的
FALSE状态下创建的用户（密码已存为小写），在 12c 中仍能登录，但一旦执行ALTER USER ... IDENTIFIED BY，新密码立刻按大小写敏感存入，旧逻辑就断了 - GoldenGate 或 Data Pump 导出导入时，若未带
EXCLUDE=PASSWORDS，会把加密后的密码哈希一起搬过去，但哈希算法在 12c 有变化，导致迁移后密码失效
真实痛点不在参数本身，而在于它牵出了一堆隐性依赖：运维脚本、监控工具、自动化部署里的密码写法、甚至 DBA 自己记的笔记——全是小写。这些地方不清理，光调参数没用。
