oracle 19c中sec_case_sensitive_logon=false导致ora-01017登录失败，根本原因是其与默认sqlnet.allowed_logon_version_server=12/12a冲突，因12c密码版本仅支持大小写敏感认证；必须同步降级协议至8或11、清空password_verify_function、无引号重置密码并刷新共享池。
升级后直接设 sec_case_sensitive_logon=false 会让几乎所有用户登录失败（ora-01017），这不是参数没生效，而是它和 sqlnet.allowed_logon_version_server 冲突了——你得同步调低密码协议版本，再重置密码。
为什么 sec_case_sensitive_logon=false 在 19c 里会锁死登录
19c 默认把 SQLNET.ALLOWED_LOGON_VERSION_SERVER 设为 12 或 12a，这强制启用 SHA-512 密码哈希（12C 版本），而该版本只支持大小写敏感认证。此时若硬设 sec_case_sensitive_logon=false，Oracle 会拒绝所有密码校验，连 sys 都可能进不去。
查当前配置：
SELECT name, value FROM v$parameter WHERE name IN ('sec_case_sensitive_logon', 'sqlnet.allowed_logon_version_server');
再看用户密码版本：
SELECT username, password_versions FROM dba_users WHERE username = 'SCOTT';
如果返回值含 12C，说明已落入“强密码+大小写强制”闭环，单改参数无效。
必须同步调整 SQLNET.ORA 中的协议版本
只改数据库参数不够，客户端连接时也得匹配旧协议。编辑数据库服务器端的 $ORACLE_HOME/network/admin/sqlnet.ora：
-
SQLNET.ALLOWED_LOGON_VERSION_SERVER=8（或11，不推荐12） SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8
注意：8 表示兼容 Oracle 8i 起的旧密码格式（10G 版本），它不校验大小写；11 仍保留部分兼容性但可能触发 11G 密码版本，风险略高。
改完不用重启监听，但所有新连接会立即按新规则协商。
profile 的 PASSWORD_VERIFY_FUNCTION 必须清空
即使协议降级，如果用户 profile 还绑着 ora12c_strong_verify_function，重设密码时仍会强制大小写校验。
查用户 profile：
SELECT profile FROM dba_users WHERE username = 'SCOTT';
清空验证函数（以 DEFAULT 为例）：
ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION NULL;
这步不做，后续 ALTER USER ... IDENTIFIED BY xxx 仍可能报错或悄悄启用大小写检查。
重设密码时严禁使用双引号
升级前用双引号建的用户（如 CREATE USER scott IDENTIFIED BY "Tiger"），其密码在数据字典里被标记为“强制大小写”，任何参数或 profile 修改都无效。
安全重设方式（全小写、无引号）：
ALTER USER scott IDENTIFIED BY tiger;
错误方式（哪怕只改一次）：
ALTER USER scott IDENTIFIED BY "Tiger";
一旦执行后者，该用户永久锁定大小写敏感，只能删重建或接受严格大小写输入。
最后执行 ALTER SYSTEM FLUSH SHARED_POOL; 清掉 PL/SQL 认证缓存，避免旧密码哈希残留。
真正麻烦的不是参数开关，而是密码版本、协议版本、profile 函数、建库方式四者咬合在一起——漏掉任意一环，都会让 ORA-01017 反复出现。
