根本原因是Oracle权限不传递，视图依赖的表、函数等需单独授权；ORA-01031表示缺显式权限，ORA-00942表示底层对象不可见；跨schema视图须确保每层依赖均有WITH GRANT OPTION。
直接给用户 GRANT SELECT ON view_name TO user 后查询仍报错，根本原因不是授权没执行，而是 Oracle 的权限模型不传递——视图本身是对象，但它的定义里引用的表、函数、同义词等，都得单独授权。
查不到数据时先确认错误码到底是哪个
ORA-01031 和 ORA-00942 表面都是“没权限”，但定位点完全不同：
-
ORA-01031: insufficient privileges：说明用户对视图或其依赖对象缺少显式SELECT（或EXECUTE）权限，且不是角色间接授予的（Oracle 不认角色里的对象权限） -
ORA-00942: table or view does not exist：通常是用户连依赖的底层表名都解析不到，比如视图里写了hr.employees，但目标用户根本没被授过hr.employees的SELECT权限，也不是hr用户本人
别急着重授视图权限，先用当前应用用户登录 SQL*Plus，手动执行 SELECT * FROM view_name 看报什么错。错不一样，排查路径就不同。
跨 schema 视图必须检查依赖链和 WITH GRANT OPTION
假设视图 v_emp_dept 在用户 app 下创建，定义是 SELECT e.name, d.dept_name FROM hr.employees e JOIN hr.departments d ON e.dept_id = d.id，那么以下三步缺一不可：
-
hr用户必须执行：GRANT SELECT ON employees TO app WITH GRANT OPTION -
hr用户必须执行：GRANT SELECT ON departments TO app WITH GRANT OPTION -
app用户才能执行：GRANT SELECT ON v_emp_dept TO webuser
漏掉任意一个 WITH GRANT OPTION，app 就无法把底层权限“穿透”过去。可以用这条语句验证：SELECT grantable FROM dba_tab_privs WHERE grantee = 'APP' AND owner = 'HR' AND table_name IN ('EMPLOYEES', 'DEPARTMENTS') AND privilege = 'SELECT'，返回值必须是 YES。
别忽略同义词和物化视图这两类隐性依赖
视图定义里如果用了同义词（比如 CREATE VIEW v AS SELECT * FROM emp_syn），那不能只查 emp_syn 的权限，还得顺着它查到底层真实对象：
- 查同义词指向：
SELECT table_owner, table_name FROM all_synonyms WHERE owner = 'APP' AND synonym_name = 'EMP_SYN' - 再查
table_owner.table_name是否已对目标用户授权
另外，all_views 不包含物化视图，如果视图实际是 MATERIALIZED VIEW，得去查 all_mviews，否则生成的授权脚本会漏掉它。
批量授权脚本只能解决“视图层”，不能代替人工验依赖
用 SELECT 'GRANT SELECT ON '||owner||'.'||view_name||' TO target_user;' FROM all_views WHERE owner = 'SOURCE_SCHEMA' AND status = 'VALID' 生成授权语句，确实能快速搞定所有视图对象本身，但它完全不管这些视图背后调了哪些表、函数、包。
真正容易被忽略的是：视图定义里可能嵌套了另一个视图，而那个视图又依赖函数，函数里又查了第三张表——这种多层依赖，必须用 all_dependencies 逐层展开：SELECT referenced_owner, referenced_name, referenced_type FROM all_dependencies WHERE name = 'V_EMP' AND type = 'VIEW'，然后对每一条结果再递归查依赖，直到所有 referenced_type 是 TABLE、FUNCTION 或 PACKAGE 为止。
