DEFINER模式下ROLE权限完全失效，因权限检查以定义者身份进行且忽略角色；改用CURRENT_USER模式可使角色生效，但需调用者会话显式启用对应角色，且对象级权限仍须直接授予或通过已启用角色持有。
ROLE权限在DEFINER模式下完全失效
Oracle默认的存储过程是AUTHID DEFINER（所有者权限），执行时以定义者身份检查权限，而角色权限（如DBA、RESOURCE）在该模式下被忽略——哪怕调用者已启用该角色，过程内部也看不到任何role授予的对象或系统权限。
常见现象：ORA-01031: insufficient privileges 或 PLS-00201: identifier must be declared，尤其在动态SQL中访问跨schema表、建表、查dba_*视图时高频出现。
- 角色权限只在会话级生效，不透传进
DEFINER过程的权限上下文 -
SESSION_ROLES视图在过程内查出来是空的，不是bug，是设计如此 - 即使用户登录后执行了
SET ROLE ALL，对DEFINER过程也无影响
Authid Current_User能用ROLE，但有硬性前提
改用AUTHID CURRENT_USER（调用者权限）后，过程运行时以调用者身份校验权限，此时角色才真正起作用——但前提是调用者当前会话已启用对应角色。
关键配套动作常被跳过：JDBC连接后必须显式执行SET ROLE ALL或SET ROLE role_name，否则即使用户被授了role，CURRENT_USER模式下仍报权限不足。
- Oracle不自动启用default role，必须手动
SET ROLE - 如果role里包含对象权限（如
SELECT ON hr.employees），调用者必须对该对象有直接授权或通过role持有，不能只靠role里的系统权限（如SELECT ANY TABLE）间接覆盖 - 动态SQL访问跨schema对象时，仍需确保调用者拥有该schema下具体对象的权限，role本身不解决对象级访问控制
GRANT EXECUTE权限必须带schema且不能走role
即使存储过程本身能跑通，调用它也需要独立授权——而这个授权如果通过role间接赋予，在AUTHID DEFINER过程里依然无效。
错误写法：GRANT EXECUTE ON get_employee_info TO scott（缺schema）或通过app_exec_role把EXECUTE包给用户。
- 必须写成
GRANT EXECUTE ON hr.get_employee_info TO scott，schema不可省略 - 包内过程不能单独授权，只能
GRANT EXECUTE ON hr.emp_pkg TO scott - 同义词调用时，权限检查落在原对象上，不是同义词本身
- role间接授予的EXECUTE权限，在DEFINER过程调用时被无视，报
PLS-00201或ORA-00942
最稳妥的解法：绕过role，直授对象/系统权限
生产环境建议放弃依赖role来支撑存储过程逻辑，改为显式授予所需权限。这避免了SET ROLE遗漏、role未启用、权限链断裂等隐形故障点。
例如过程里要建表，就直接GRANT CREATE TABLE TO your_user；要查hr.employees，就GRANT SELECT ON hr.employees TO your_user。
- 系统权限（如
CREATE ANY TABLE）和对象权限（如SELECT ON schema.table）都需显式授予用户，不能指望role兜底 - 权限生效无需重连，但授完后要确认用户当前会话没缓存旧权限状态（可查
SESSION_PRIVS验证） - 如果过程逻辑复杂、涉及多schema多对象，逐个授权虽繁琐，但比排查role失效场景快得多
最容易被忽略的是：AUTHID CURRENT_USER不是万能钥匙，它把权限检查推迟到运行时，但没降低权限要求——调用者仍得自己具备所有被访问对象的权限，role只是其中一种获取途径，且必须已启用。
