ora-01031 表示当前用户缺少执行操作所需的系统或对象权限，原因包括角色未启用、权限未显式授予、或通过角色获得的权限在pl/sql中不可用；dba角色无admin option无法转授，os/外部认证可能不激活权限，且运行时需通过session_roles和session_privs确认实际生效权限。
ora-01031 实际意味着什么
这个错误不是“你输错了密码”，而是 oracle 明确告诉你：当前用户没有执行该操作所需的系统权限或对象权限。它不区分“没授权”和“授权了但没生效”，只要权限检查链上任一环缺失（比如角色未启用、权限未显式授予、通过角色间接获得的权限在存储过程里不可用），就会报这个错。
为什么 GRANT DBA TO user 有时也不管用
常见误区是以为给个 DBA 角色就一劳永逸。但要注意：
-
DBA是预定义角色，但默认不包含ADMIN OPTION—— 如果你要用它去授予权限给别人，得加WITH ADMIN OPTION - 如果用户以
IDENTIFIED EXTERNALLY或 OS 认证方式登录，某些系统权限（如CREATE SESSION）可能不会自动激活，需显式SET ROLE - 在 PL/SQL 过程/函数中，**通过角色获得的权限默认不可用**（这是 Oracle 的安全限制），必须直接授予用户（
GRANT ... TO user），或启用INHERIT PRIVILEGES（12c+）并谨慎配置
快速定位缺哪个权限：从操作反推
别猜，看你在做什么操作，再查对应所需权限。例如：
- 执行
SELECT * FROM dba_users→ 需要SELECT_CATALOG_ROLE或直接SELECT权限 onDBA_USERS（后者更细粒度） - 创建同义词指向其他 schema 表 → 除了
CREATE SYNONYM，还必须有SELECT（或其他 DML）权限 on that table，且不能仅靠角色授予（见上条） - 编译包体失败报 ORA-01031 → 检查包里引用的对象（表、视图、序列等）是否都已对当前用户显式授权，尤其注意
DEFINER'S RIGHTSvsINVOKER'S RIGHTS的行为差异
验证权限是否真正生效的三步检查法
光看 DBA_ROLE_PRIVS 和 DBA_TAB_PRIVS 不够，还要确认运行时上下文：
- 登录后执行
SELECT * FROM SESSION_ROLES—— 确认期望的角色确实处于ENABLED状态；若未启用，用SET ROLE role_name IDENTIFIED BY password（如有密码）或SET ROLE ALL - 执行
SELECT * FROM SESSION_PRIVS—— 这里列出的是当前会话**实际可用**的系统权限（不含角色间接带来的） - 如果是从 SQL*Plus 外调用（如 JDBC、Python cx_Oracle），注意连接字符串是否指定了
currentSchema或使用了 proxy 用户，权限模型会变化
最隐蔽的坑往往在第三点：应用连上来默认不启用角色，而开发只在 SQL*Plus 里测试过。
