grant select on view_name查不到数据是因为视图不存储数据且权限不自动传递，需显式授予其依赖的底层对象（如表、函数）select或execute权限，并验证依赖链及with grant option有效性。
GRANT SELECT ON view_name 为什么查不到数据
因为视图本身不“拥有”数据，它只是封装了对底层对象（如 schema_a.table1）的查询逻辑。GRANT SELECT ON view_name TO user2 只授予对视图元数据的访问权，不自动传递对依赖表、函数或序列的权限。一旦 user2 查询该视图，Oracle 会以 user2 的身份去解析并执行视图定义里的 SQL —— 如果其中引用的 schema_a.table1 没有显式授予 user2 的 SELECT 权限，就会报 ORA-00942 或 ORA-01031。
如何确认视图真正依赖哪些对象
不能只看视图名，必须展开定义，逐层验证依赖链：
- 查视图文本：
SELECT text FROM all_views WHERE owner = 'SCHEMA_A' AND view_name = 'V_EMP' - 查直接依赖：
SELECT referenced_owner, referenced_name, referenced_type FROM all_dependencies WHERE name = 'V_EMP' AND type = 'VIEW' AND referenced_type IN ('TABLE', 'VIEW', 'FUNCTION', 'PACKAGE') - 若依赖的是同义词，还要再查同义词指向：
SELECT table_owner, table_name FROM all_synonyms WHERE owner = 'SCHEMA_A' AND synonym_name = 'EMP_SYNONYM'，然后继续查table_owner.table_name是否可访问 - 注意：物化视图不在
all_views中，需额外查all_mviews
授权时 WITH GRANT OPTION 的实际限制
它不是万能钥匙，用错反而埋坑：
-
WITH GRANT OPTION必须由源对象所有者（如schema_a）显式授予，且仅对其自己拥有的对象有效；SELECT ANY TABLE这类系统权限不支持该选项 - A → B 带 option 授权后，B 才能创建视图并转授给 C；但 B → C 授权时，若没加
WITH GRANT OPTION，C 就不能再转授给 D - 检查是否真有 option：
SELECT grantable FROM dba_tab_privs WHERE grantee = 'SCHEMA_A' AND owner = 'SCHEMA_A' AND table_name = 'EMP' AND privilege = 'SELECT'，返回YES才可用 - 生产环境慎用：option 越传越远，权限边界失控风险高
批量授权和权限落地的实操要点
手动一条条授太慢，但脚本生成也得小心：
- 生成视图授权语句：
SELECT 'GRANT SELECT ON '||owner||'.'||view_name||' TO target_user;' FROM all_views WHERE owner = 'SOURCE_SCHEMA' AND status = 'VALID';（加status = 'VALID'避免对失效视图授权失败） - 但该语句只解决“视图本身”，不解决其依赖——你还得对每个
referenced_owner.referenced_name单独执行GRANT SELECT，函数/包还需EXECUTE - 如果依赖对象很多，建议先用
SELECT DISTINCT referenced_owner, referenced_name FROM all_dependencies...提取唯一依赖列表，再拼授权 - 授权后，被授权用户需重新连接或执行
ALTER SESSION SET CURRENT_SCHEMA = ...，否则某些缓存可能仍沿用旧权限上下文
最易被忽略的是：视图里调用的 PL/SQL 函数，即使你给了表权限，没给函数 EXECUTE 权限照样失败；而这个错误常被误判为表不存在。
