EXECUTE权限缺失导致PL/SQL调用直接报错，是因为Oracle 19c严格要求普通用户必须显式拥有该权限才能调用SYS下的系统包，且角色权限在PL/SQL上下文中不可见，缺少时触发ORA-06550与PLS-00201错误。
调用 DBMS_MONITOR、DBMS_SESSION 或 DBMS_WORKLOAD_REPOSITORY 等性能分析包失败，90% 以上不是包本身损坏，而是当前用户缺少 EXECUTE 权限或被显式拒绝（REVOKE）。
为什么 EXECUTE 权限缺失会导致 PL/SQL 调用直接报错？
Oracle 19c 对权限检查更严格：即使包已安装在 SYS 下，普通用户调用前也必须显式拥有 EXECUTE 权限。没有该权限时，ORA-06550 + PLS-00201 是最常见组合，错误信息里会明确写出未声明的标识符，比如 DBMS_MONITOR。
- 权限必须由
SYS或有GRANT ANY PROCEDURE的用户授予，不能靠角色间接继承（ROLE在 PL/SQL 包内不可见） -
GRANT EXECUTE ON DBMS_MONITOR TO scott;是最小可行操作，不要用WITH GRANT OPTION除非真要转授 - 如果用户曾被
REVOKE EXECUTE ON DBMS_MONITOR FROM scott;，再GRANT才能恢复——撤销不会自动“失效”
如何快速确认是权限问题而非包异常？
先绕过 PL/SQL 上下文，用 SELECT 直接查数据字典，比跑脚本更快定位：
- 查当前用户是否真有权限：
SELECT * FROM USER_TAB_PRIVS WHERE TABLE_NAME = 'DBMS_MONITOR'; - 查该包是否对 PUBLIC 开放（不推荐但可临时验证）：
SELECT * FROM ALL_TAB_PRIVS WHERE TABLE_NAME = 'DBMS_MONITOR' AND GRANTEE = 'PUBLIC'; - 查包是否存在且有效：
SELECT STATUS FROM ALL_OBJECTS WHERE OBJECT_NAME = 'DBMS_MONITOR' AND OWNER = 'SYS';—— 返回VALID才说明包本身没问题
哪些性能包最容易因权限失败而“静默失效”？
不是所有包都一样敏感。以下三个在 19c 中对权限最“较真”，尤其在启用统一审计或细粒度访问控制（FGAC）后：
-
DBMS_MONITOR.SESSION_TRACE_ENABLE：缺权限时不会报错，但 trace 文件根本不会生成，容易误判为功能关闭 -
DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT：缺权限会直接抛ORA-01031: insufficient privileges，但很多人忽略这个错误去查 AWR 表空间 -
DBMS_SESSION.SET_IDENTIFIER：缺权限会导致应用层设置的 client_id 在 ASH 中为空，让后续按会话追踪完全失效
权限问题本身简单，但 19c 的陷阱在于：它不会告诉你“你没权限”，而是让你看到“功能没反应”或“数据没出来”。查 USER_TAB_PRIVS 是最快破局点，别在 trace 目录或 AWR 快照时间上空耗时间。
