必须直接授予execute权限，不能通过角色；包权限以包为单位不可细分；过程内访问的对象需单独授权；同义词不改变权限检查对象。
必须直接授予 EXECUTE 权限，不能走角色
用户调用存储过程报 PLS-00201 或 ORA-00942，八成是因为权限是通过角色间接给的。Oracle 在 AUTHID DEFINER（默认）过程里会忽略角色权限，只认直接授予的 EXECUTE。哪怕你建了个 app_exec_role 并把 EXECUTE ON hr.proc_a 塞进去，再把角色授给用户，调用时照样失败。
正确做法只有这一种：GRANT EXECUTE ON hr.proc_a TO app_user; —— 每个过程都得单独、显式、直接授。
- 不要试图用脚本批量授角色来“省事”，那只是埋雷
- 如果过程数多，可用查询生成授权语句，但最终执行仍须逐条
GRANT EXECUTE ON schema.name TO user - 检查是否生效：查
dba_tab_privs，确认grantee = 'APP_USER'且privilege = 'EXECUTE'，而不是看dba_role_privs
包内过程必须授整个包，不能授单个子程序
想只给 hr.emp_pkg.get_dept_info 的执行权？不行。Oracle 不支持对包内成员做对象级授权，语法直接报 ORA-00905。包是权限最小单位，要么全放行，要么全拒绝。
GRANT EXECUTE ON hr.emp_pkg TO app_user; ✅ 才是合法写法；GRANT EXECUTE ON hr.emp_pkg.get_dept_info TO app_user; ❌ 会报错。
- 包里混了函数和过程，一样处理：授包即授全部可调用单元
- 如果包里某些过程不该被调用，得从代码层隔离（比如改名加前缀、拆包、或用条件逻辑屏蔽），不能靠权限卡
- 注意包名大小写：若建包时用了双引号如
"Emp_Pkg"，授权也得写成GRANT EXECUTE ON hr."Emp_Pkg" TO app_user;
过程内部访问表，需额外授对象权限
给了 EXECUTE 权限，不代表用户能跑通过程。只要过程里查了 hr.employees，就得再补一句：GRANT SELECT ON hr.employees TO app_user;。否则过程运行到那行就崩，报 ORA-00942，不是过程本身问题，而是权限链断在底层对象上。
- 过程所有者（如
hr）必须已拥有这些表权限，且不能是通过角色获得的——定义者权限过程不认角色 - INSERT/UPDATE/DELETE 同理，按过程实际操作类型补对应权限
- 避免用
SELECT ANY TABLE这类高危系统权限，宁可一条条授，才符合最小权限原则
同义词不影响权限检查点
用户建了同义词 CREATE SYNONYM my_proc FOR hr.proc_a;，然后执行 EXEC my_proc —— 看似绕开了 schema，其实没用。Oracle 先解析出真实对象是 hr.proc_a，再检查当前用户对 hr.proc_a 有没有 EXECUTE 权限。同义词只是别名，不改变权限主体。
- 授权仍要落在原对象上：
GRANT EXECUTE ON hr.proc_a TO app_user; - 如果同义词指向的是另一个用户的同义词（嵌套），最终仍追溯到最底层对象的 owner 和权限
- 别指望用同义词+角色组合来“绕过”直接授权要求，路径再绕，检查点不变
