根本原因是权限不足而非视图不存在；V$视图是同义词，需对SYS.V_$*基表单独授权SELECT权限，禁用SELECT ANY DICTIONARY等高危授权，且授权后需重新连接生效。
普通用户查V$视图报ORA-00942，不是视图不存在
根本原因不是V$视图“被隐藏”或“没创建”，而是Oracle在权限模型里把它们当作SYS拥有的特殊对象处理。V$视图本身是同义词（如V$SESSION指向SYS.V_$SESSION），而真正可授权的对象是V_$*基表。普通用户默认没有任何SELECT权限，连V_$SESSION都不可见，自然查V$SESSION会报ORA-00942: table or view does not exist——错误信息极具误导性，实际是权限拒绝，不是对象缺失。
授SELECT ANY DICTIONARY是高危操作
很多人一看到提示“obtain select privileges on the V$session…”就直接执行：GRANT SELECT ANY DICTIONARY TO username;
这等于把整个数据字典大门敞开，用户立刻能查DBA_USERS（含密码哈希）、DBA_AUDIT_TRAIL（审计日志）、V$PWFILE_USERS（特权账号列表）。这不是最小权限，是权限爆炸：
- 该权限无法按视图粒度回收，只能全撤
- 一旦用户被黑，攻击者可直接导出敏感元数据
- 某些合规审计（如等保、PCI DSS）明确禁止此授权
正确做法：只授V_$*，不授V$*
必须对V_$*对象单独授权，且仅限所需视图。例如PL/SQL Developer报错要访问三个视图，应执行：
GRANT SELECT ON SYS.V_$SESSION TO username; GRANT SELECT ON SYS.V_$SESSTAT TO username; GRANT SELECT ON SYS.V_$STATNAME TO username;
注意关键点：
- 对象名必须是
V_$SESSION，不是V$SESSION（后者是同义词，不能直接授权） - 必须带
SYS.前缀，否则会提示“invalid identifier” - 若用
GRANT SELECT ON V$SESSION，Oracle会报ORA-02030: can only select from fixed tables/views
别碰o7_dictionary_accessibility参数
这个参数控制“拥有SELECT ANY TABLE是否能间接查字典基表”，设为false看似能堵漏，但：
- 12c+已标记为
deprecated，未来版本可能移除 - 它不解决根本问题：用户仍可通过
SELECT ANY DICTIONARY绕过 - 修改需
SCOPE=SPFILE并重启数据库，运维成本高且不可逆 - 真实风险来自权限滥用，而非底层开关
最易被忽略的细节是：授权后必须让用户重新连接会话，旧连接缓存的权限状态不会自动刷新。
