只读用户查不到视图的主因是视图依赖对象（表、函数、同义词等）未授权，而非视图本身；需逐个检查并授予底层对象select权限，且同义词须授原对象、v$视图须授v_$形式、序列慎授且禁用nextval。
只读用户查不到视图？先确认底层表权限是否到位
执行 GRANT SELECT ON my_view TO readonly_user 后仍报 ORA-00942: table or view does not exist 或 ORA-01031: insufficient privileges，大概率不是视图授权没做，而是视图定义里引用的表、函数或同义词，目标用户根本没权限访问。
Oracle 不会自动把视图依赖对象的权限“穿透”给调用者。哪怕视图在 APP_SCHEMA 下，且你只授了视图本身，只要它查了 CONFIG_SCHEMA.settings，而 readonly_user 没被授予对 CONFIG_SCHEMA.settings 的 SELECT 权限，查询就必然失败。
- 用
SELECT text FROM all_views WHERE owner = 'APP_SCHEMA' AND view_name = 'MY_VIEW'查清视图 SQL，人工列出所有跨 schema 引用的对象 - 对每个依赖表/视图，单独执行
GRANT SELECT ON schema.table TO app_readonly（推荐走角色，别直接授用户） - 如果依赖的是同义词，注意同义词不继承权限——必须对同义词指向的**原对象**授权，而不是同义词名
序列权限不能只靠 GRANT SELECT —— 只读用户通常不需要序列
序列（SEQUENCE）本质是用于生成唯一值的写入型对象，SELECT 权限仅允许调用 NEXTVAL 和 CURRVAL，这会改变序列状态，不符合“只读”语义。生产环境里，只读用户几乎从不需访问序列。
如果你确实遇到只读应用需要读取序列当前值（比如监控类场景），才考虑授权：
- 必须显式授予
SELECT权限：GRANT SELECT ON my_seq TO app_readonly -
SELECT my_seq.CURRVAL FROM DUAL才能执行；但NEXTVAL会推进序列，应严格禁止 - 切勿授予
ALTER或USAGE（Oracle 不支持后者），也别把序列放进只读角色默认清单 - 检查序列是否被误用于 INSERT 触发器或视图定义中——这种设计本身已违背只读原则
动态性能视图（v$）和数据字典需额外授权，且不能靠 SELECT ANY TABLE 解决
只读用户连 v$session 或 dba_tables 都查不了，不是权限漏了，而是这些属于系统对象，普通对象授权完全无效。常见错误是以为 SELECT ANY TABLE 能覆盖，但它对 v$ 视图无效（这些是基于 X$ 表的内存结构，非普通段）。
安全做法是精确授权：
- 对常用监控视图，如
v$sysstat、v$archive_dest，逐个执行：GRANT SELECT ON v_$sysstat TO app_readonly（注意是v_$xxx，不是v$xxx） - 避免授予
SELECT_CATALOG_ROLE：它隐含上百个权限，包括对敏感字典表的读写能力，远超只读需求 - 数据字典表（如
dba_tables）默认拒绝普通用户访问，除非 DBA 显式授SELECT ANY DICTIONARY——该操作极度危险，不应出现在只读方案中
真正可控的只读，是靠角色封装 + 显式对象授权，不是靠禁用 INSERT/UPDATE
很多人试图用 REVOKE INSERT, UPDATE, DELETE ON table TO user 来“加固”只读，这是徒劳的。Oracle 权限模型里，“无写权限”就是默认状态；真正要做的，是确保只开放明确需要的 SELECT，其余一律不授。
关键动作只有三步：
- 建角色：
CREATE ROLE app_readonly - 批量授对象权限（表、视图、序列（慎选）、v_$ 视图）：
GRANT SELECT ON APP_SCHEMA.orders TO app_readonly - 绑定基础连接权：
GRANT CREATE SESSION TO app_readonly，再GRANT app_readonly TO readonly_user
视图和序列权限最容易被当成“顺手加一项”，结果引入非预期行为。序列一旦被授出，就必须监控其 NEXTVAL 调用；视图一旦依赖多 schema 对象，权限链就变成运维黑洞。最小权限不是口号，是每次 GRANT 前都得问一句：这个权限，此刻、此用户、此场景，真的不可替代吗？
