ORA-01924表示角色未被授予当前用户或已授予但未启用；需查DBA_ROLE_PRIVS确认授予状态，再用SET ROLE显式激活，因默认角色在外部认证、JDBC等场景下常不自动生效。
ORA-01924 出现时，不是角色不存在，而是当前用户没被授予该角色，或虽被授予但未启用——必须显式 SET ROLE 才能激活。
查角色是否真被授予给当前用户
很多人只查 DBA_ROLES 看角色是否存在，却忘了确认“这个角色到底有没有落到你头上”。DBA_ROLE_PRIVS 是唯一权威来源，但要注意它只记录“授予”动作，不保证“启用”：
- 运行
SELECT grantee, granted_role, admin_option FROM DBA_ROLE_PRIVS WHERE grantee = 'YOUR_USER';—— 如果目标角色不在结果里，说明根本没授过 - 若角色在列表中但
ADMIN_OPTION为NO，你不能用它去再授给别人；若为YES，才可执行GRANT ... TO ... WITH ADMIN OPTION - 注意大小写：Oracle 默认大写用户名和角色名，
'your_user'不会匹配'YOUR_USER'
角色已授但 SESSION_ROLES 为空？必须 SET ROLE
Oracle 默认不自动启用角色（哪怕你设了 DEFAULT ROLE），尤其在 JDBC、Navicat 或 PL/SQL 中。光靠 GRANT role TO user 不等于权限立刻可用：
- 登录后立即执行
SELECT * FROM SESSION_ROLES;—— 若返回空集，说明角色处于“休眠”状态 - 手动启用：
SET ROLE role_name;（无密码）或SET ROLE role_name IDENTIFIED BY 'pwd';（有密码） - 想一次启用所有可授予角色：
SET ROLE ALL;，但前提是这些角色都已被授予且无密码保护 - PL/SQL 存储过程里，角色权限默认不可用，
SET ROLE在过程体内无效；必须改用AUTHID CURRENT_USER并确保调用者已启用角色
为什么 ALTER USER DEFAULT ROLE ALL 还不管用
设了默认角色，不代表每次连接都自动生效——尤其当连接使用外部认证（IDENTIFIED EXTERNALLY）、代理用户（CONNECT THROUGH）或某些 JDBC 驱动时，Oracle 会跳过默认角色激活流程：
- 检查实际生效的默认角色：
SELECT * FROM DBA_USERS WHERE username = 'YOUR_USER';，看DEFAULT_ROLE列是否为ALL或具体角色列表 - 如果列值是
ALL，但SESSION_ROLES仍为空，大概率是客户端连接方式绕过了默认角色机制 - 临时解法：在应用连接后的第一个 SQL 里加
SET ROLE ALL;（需确保驱动支持多语句） - 长期方案：避免依赖默认角色，改用显式
SET ROLE或直接授予系统权限（如GRANT CREATE TABLE TO user;）
容易被忽略的嵌套角色激活限制
角色 A 被授予角色 B，而你只被授予了角色 A —— 这种嵌套关系不会自动“穿透”到你的会话。Oracle 只认直接授予你的角色，不递归展开：
-
SELECT granted_role FROM DBA_ROLE_PRIVS WHERE grantee = 'ROLE_A';查出它包含哪些子角色，但这些子角色对你无效，除非也单独GRANT给你 - 没有视图能自动列出“你最终能获得的所有角色”，
SESSION_ROLES只反映当前已启用的、直接授予你的角色 - 跨 schema 操作（如查询
hr.employees）失败时，别只盯着SELECT_CATALOG_ROLE，先确认你是否被显式授予了SELECT ON hr.employees或启用了含该权限的角色
最常踩的坑是：在 SQL*Plus 里 SET ROLE ALL 成功了，就以为应用连上来也一样——其实 JDBC 默认不执行这句，得靠应用层显式发送，或者改用连接字符串参数（如 Oracle Wallet 或 oracle.jdbc.defaultRowPrefetch 无关，真正相关的是 oracle.jdbc.useDefaultRole，但该参数并不存在，只能靠代码控制）。
