在 Oracle 数据库中，执行 GRANT EXECUTE 为存储过程授权时，必须显式写明 schema 名，例如 GRANT EXECUTE ON hr.get_employee_info TO scott；对于包（PACKAGE），只能按整个包进行授权，不能只给包内某一个过程授权；而 DEBUG 权限仅用于查看源码，并不包含执行权限。
GRANT EXECUTE ON 必须带 schema 名
在 Oracle 中，schema 名不会自动补全。若省略 schema，直接写 GRANT EXECUTE ON proc_name TO user，通常会直接失败，并报出 ORA-00942: table or view does not exist。这并不代表对象真的不存在，而是 Oracle 在解析对象名时，由于没有明确指定 owner，导致无法定位到对应的存储过程或函数。
- ✅ 正确写法：
GRANT EXECUTE ON hr.get_employee_info TO scott - ❌ 错误写法：
GRANT EXECUTE ON get_employee_info TO scott - ⚠️ 大小写敏感：如果过程是通过双引号创建的（如
"Get_Employee_Info"），那么授权语句也必须完全一致：GRANT EXECUTE ON hr."Get_Employee_Info" TO scott
DEBUG 权限 = 查看源码，不等于执行
如果你希望某个用户只能查看 Oracle 存储过程定义，而不能调用或修改过程，就不要授予 EXECUTE，而应改为授予 DEBUG 权限。该权限允许用户查询系统视图 ALL_SOURCE 或 DBA_SOURCE 中对应对象的源码内容，但不能直接 EXEC 执行，也不能 ALTER 修改。
- 授予查看权：
GRANT DEBUG ON hr.get_employee_info TO report_user - 验证方式：report_user 执行
SELECT text FROM all_source WHERE name = 'GET_EMPLOYEE_INFO' AND owner = 'HR' ORDER BY line可以查看源码；但执行EXEC hr.get_employee_info时会报ORA-06550 / PLS-00201 - 注意：
DEBUG属于对象级权限，不是系统级权限，因此不能使用GRANT DEBUG ANY PROCEDURE，因为这个系统权限本身并不存在
包（PACKAGE）要整体授权，不能只授包体里的某个过程
Oracle 对包的权限控制粒度是 package level，而不是 procedure level。也就是说，即便你只想让其他用户调用 pkg.do_something，依然必须对整个包授予 EXECUTE 权限，否则无论是编译阶段还是运行阶段，都可能出现报错。
- ✅ 正确：
GRANT EXECUTE ON hr.emp_pkg TO scott - ❌ 无效：
GRANT EXECUTE ON hr.emp_pkg.do_something TO scott（语法错误，Oracle 不支持这种写法） - 如果包内部执行 SQL 并访问了其他用户的表，那么被授权用户还需要额外具备这些表的
SELECT权限，否则运行时依旧可能报ORA-00942
权限生效无需重连，但同义词会绕过原权限检查
在 Oracle 中，对象权限一旦授予，当前会话会立即生效，无需重新登录或执行 DISCONNECT/CONNECT。不过，如果你为用户创建了私有同义词（例如 CREATE SYNONYM my_proc FOR hr.get_employee_info），当用户执行 EXEC my_proc 时，Oracle 实际检查的是同义词解析后的权限链路。简单来说，使用同义词并不会自动获得原对象的执行权限。
- 也就是说：创建同义词的用户本身必须已经拥有对应对象的
EXECUTE权限，否则即使同义词存在，也无法正常调用 - 若想简化调用方式，通常建议结合公有同义词与显式授权一起使用：
CREATE PUBLIC SYNONYM get_emp FOR hr.get_employee_info，然后确保目标用户都已执行GRANT EXECUTE ON hr.get_employee_info TO ... - 公有同义词本身不附带权限，它只是对象别名，底层的 Oracle 权限检查机制仍然保持不变
在实际进行 Oracle 存储过程授权时，最容易忽略的两点就是 schema 名必须写全，以及包只能整体授权。这两个问题一旦处理错误，报错信息如 PLS-00201 看起来像是代码故障，实际上往往只是对象权限配置不正确所导致。
