ORA-28040和ORA-01017登录失败主因是认证协议与密码版本不匹配：19c默认要求SQLNET.ALLOWED_LOGON_VERSION_SERVER≥11且仅认含12C哈希的密码，旧客户端需降级服务端参数，用户须重设密码以生成兼容哈希。
升级后用户权限看似“失效”，大概率不是权限丢了，而是认证机制、密码版本或默认profile限制被新版本严格校验了。
ORA-01017 / ORA-28040 登录失败：密码哈希与协议不匹配
11g 用户用原密码连不上 19c，报 ORA-01017 或 ORA-28040，根本原因不是权限被 revoke，而是密码加密版本和客户端协议不被 19c 默认接受。
-
ORA-28040：客户端太老（比如 10g/11g JDBC），而 19c 默认要求最低sqlnet.allowed_logon_version_server=11；临时解法是改$ORACLE_HOME/network/admin/sqlnet.ora，加一行：sqlnet.allowed_logon_version_server=8（立即生效，不用重启库） -
ORA-01017：用户密码只存了 10g/11g 的哈希（PASSWORD_VERSIONS字段查出来不含12C），但 19c 启动后默认只认含12C的哈希；验证命令：SELECT username, password_versions FROM dba_users WHERE username = 'SCOTT'; - 补救方法：用
SYS执行ALTER USER scott IDENTIFIED BY VALUES '<old_hash_value>';</old_hash_value>不推荐；更稳妥的是让该用户重设一次密码（哪怕设成原密码），触发生成新哈希：ALTER USER scott IDENTIFIED BY "xxx" REPLACE "xxx";
用户能登录但查不到表：PUBLIC synonym 或角色未自动继承
升级后普通用户执行 SELECT * FROM emp; 报 ORA-00942: table or view does not exist，但 SYS 下能查——这不是权限丢失，而是 19c 对 PUBLIC synonym 和角色启用更严格的解析路径。
- 检查是否依赖
PUBLIC下的 synonym：SELECT * FROM all_synonyms WHERE synonym_name = 'EMP' AND owner = 'PUBLIC';；如果存在，确认其TABLE_OWNER是否仍有效（比如原表所在 schema 被 rename 或 drop 过） - 确认用户默认角色是否被禁用：
SELECT * FROM dba_role_privs WHERE grantee = 'SCOTT' AND default_role = 'FALSE';；若是，执行ALTER USER scott DEFAULT ROLE ALL; - 19c 默认关闭了
OS_AUTHENT_PREFIX相关隐式角色，如果业务靠OPS$前缀 OS 认证，需显式授权并检查REMOTE_OS_AUTHENT（已废弃，不建议启用）
DBA 权限用户无法执行某些操作：SEC_CASE_SENSITIVE_LOGON 或 resource_limit 干扰
升级后 SYS 或 SYSTEM 执行 CREATE DIRECTORY 或 GRANT ANY DIRECTORY 报错，或用户会话莫名被 kill，往往不是权限配置错了，而是旧参数在 19c 下行为变更引发连锁反应。
-
SEC_CASE_SENSITIVE_LOGON在 12c+ 已废弃，但 11g 若设为FALSE，升级后可能使部分密码校验逻辑异常；检查：SHOW PARAMETER sec_case_sensitive_logon；若为FALSE，建议升级后立即设为TRUE（需重启实例） -
resource_limit = TRUE+DEFAULTprofile 中PASSWORD_LIFE_TIME=180或FAILED_LOGIN_ATTEMPTS=10，会导致用户看似“权限还在”但一登录就因过期/锁定被拒；查 profile：SELECT * FROM dba_profiles WHERE profile='DEFAULT' AND resource_name IN ('PASSWORD_LIFE_TIME','FAILED_LOGIN_ATTEMPTS'); - 临时绕过：用
ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;和FAILED_LOGIN_ATTEMPTS UNLIMITED;；但生产环境建议按最小权限原则单独调整业务用户 profile
权限“看起来有”但实际不生效：数据字典视图访问控制强化
19c 默认启用 COMMON_USER_PREFIX 和细粒度数据字典保护（如 DICTIONARY_ACCESSIBILITY=FALSE），导致某些 DBA 脚本或监控工具查 DBA_OBJECTS 返回空——不是没权限，而是看不到其他容器或 CDB 级对象。
- 确认当前连接是
AS SYSDBA还是普通SYS；非 CDB 环境下，必须用sqlplus / as sysdba才能查全量DBA_*视图 - 如果升级后建了 PDB，而用户账号未在 PDB 中创建或未授予
SET CONTAINER权限，ALTER SESSION SET CONTAINER=pdb1;会失败，进而所有对象访问都受限 - 检查
V$PWFILE_USERS是否包含该用户；若用密码文件认证，REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE且用户未被显式加入密码文件，AS SYSDBA登录会静默失败
最易被忽略的一点：升级后首次启动时没运行 utlrp.sql，大量数据字典包（如 DBMS_STATS）处于 INVALID 状态，导致权限相关函数（如 DBMS_METADATA.GET_DDL）直接报错，让人误以为“授权没生效”。务必在升级完成、数据库 OPEN 后立刻执行：@?/rdbms/admin/utlrp.sql。
