Oracle数据库中授予开发者执行Explain Plan权限的合规方案咨询

嘿，Sean，作为常年跟Oracle权限和性能调优打交道的DBA，我太懂你这种既要满足开发调优需求，又要死死守住最小权限原则的纠结了。下面给你几个合规的最优方案，完全不用碰SELECT_CATALOG_ROLE或SELECT ANY DICTIONARY这种权限过大的角色：

1. 基础版：仅支持生成&查看预估执行计划 #

如果开发只需要给自己写的SQL生成预估Explain Plan，不需要查看系统里其他会话的SQL，那给这俩权限就够了：

• 首先，确保他们能访问存储执行计划的表。推荐让开发自己创建私有PLAN_TABLE（执行Oracle自带的utlxplan.sql脚本就行，不需要额外权限）；如果要用公共的系统表，就执行：

  GRANT SELECT ON SYS.PLAN_TABLE TO <开发用户名>;
  

• 如果要让他们直接用SQL Developer的「Explain Plan」按钮查看结果，还得加个权限：

  GRANT SELECT ON SYS.ALL_PLAN_TABLES TO <开发用户名>;
  

2. 进阶版：允许查看自身执行SQL的实际执行计划 #

如果开发需要看自己刚跑的SQL的真实执行计划（比如排查实际执行和预估的差异），就得加几个V$视图的权限，但要严格限制范围：

• 直接授予基表的权限（别用V$同义词，用V_$开头的基表更稳妥）：

  GRANT SELECT ON SYS.V_$SQL TO <开发用户名>;
  GRANT SELECT ON SYS.V_$SQL_PLAN TO <开发用户名>;
  GRANT SELECT ON SYS.V_$SESSION TO <开发用户名>;
  

• 关键一步：用**细粒度访问控制（FGAC）**给这些视图加个过滤策略，让用户只能看到自己会话ID对应的条目。比如创建一个策略，限制V$SESSION只能看到USERENV('SESSIONID')匹配的行，彻底杜绝他们查看其他用户的敏感SQL或计划。

3. 应急版：临时授予权限用完就收 #

如果只是偶尔要调优某条复杂SQL，不想长期给权限，那就整个临时角色：

-- 创建临时调优角色
CREATE ROLE TUNING_TEMP_ROLE;
-- 给角色加所需的最小权限
GRANT SELECT ON SYS.V_$SQL, SYS.V_$SQL_PLAN, SYS.PLAN_TABLE TO TUNING_TEMP_ROLE;
-- 授予给开发用户
GRANT TUNING_TEMP_ROLE TO <开发用户名>;
-- 调优完成后立刻回收
REVOKE TUNING_TEMP_ROLE FROM <开发用户名>;
DROP ROLE TUNING_TEMP_ROLE; -- 可选，下次要用再建

核心原则提醒 #

• 打死别碰SELECT_CATALOG_ROLE或SELECT ANY DICTIONARY！这俩权限能让用户逛遍几乎所有系统字典，妥妥的合规风险。
• 优先用私有PLAN_TABLE，减少不同用户之间的权限交叉。
• 给V$视图权限时，一定要加过滤策略，确保用户只能看到自己的数据，这才是真正的最小权限。

内容的提问来源于stack exchange，提问作者SeanGaff