删除角色后视图变INVALID是因权限链断裂而非代码错误，视图仅动态解析SQL，角色删除导致所有者失去对依赖对象的访问权，查询时报ORA-00942；修复需直接补授权而非仅重新编译。
删除角色后视图变 INVALID 是因为权限链断裂，不是视图代码出错
Oracle 视图本身不存储数据、不固化权限，它只在查询时动态解析并执行定义里的 SQL。当视图引用了某个角色授予的权限（比如通过 GRANT SELECT ON scott.emp TO role_a，再 GRANT role_a TO view_owner），而你执行了 DROP ROLE role_a，那么视图所有者就失去了对 scott.emp 的访问能力——但视图元数据没变，Oracle 仍认为它“语法合法”，只是运行时无法解析依赖对象，于是标记为 INVALID 状态。
视图失效的真实表现是查询时报 ORA-00942，不是编译失败
INVALID 状态不等于不能查，而是“查的时候才暴露问题”。常见现象包括：
- 执行
SELECT * FROM my_view直接报ORA-00942: table or view does not exist，即使表明明存在 -
ALTER VIEW my_view COMPILE成功返回，但SHOW ERRORS显示PLS-00201: identifier 'SCOTT.EMP' must be declared - 视图在
DBA_OBJECTS中STATUS = 'INVALID'，但TEXT字段仍可正常读取
根本原因不是视图定义坏了，而是当前用户（即视图所有者）已无法访问其依赖的基表或函数——而这个访问能力原本靠被删的角色间接提供。
修复必须补权限，不能只靠重新编译
ALTER VIEW ... COMPILE 对这类问题基本无效，因为 Oracle 编译阶段只检查语法和对象名是否存在，不验证运行时权限可达性。真正要做的，是让视图所有者重新获得对依赖对象的直接权限：
- 确认缺失权限：查
ALL_TAB_PRIVS或DBA_TAB_PRIVS，看视图所有者是否还有对referenced_owner.referenced_name的SELECT权限 - 手动补授权：
GRANT SELECT ON scott.emp TO view_owner（注意：必须是直接授予，不能靠残留角色） - 如果依赖的是函数或包，还要补
EXECUTE权限；若涉及同义词，得确认同义词指向的对象权限也到位 - 补完后执行
ALTER VIEW my_view COMPILE，状态才会变回VALID
容易踩的坑是：误以为 CREATE OR REPLACE VIEW 能绕过权限问题——它只会重写定义，不恢复缺失的底层访问权。
批量失效时别逐个修，先查清角色曾授了哪些权限
一个角色可能曾被授予几十张表、多个 schema 的权限，删角色后影响范围很难肉眼判断。更高效的做法是反向追溯：
- 查该角色曾经授了什么：
SELECT grantee, owner, table_name, privilege FROM dba_tab_privs WHERE grantee = 'ROLE_A' - 再查哪些视图所有者曾被授予该角色：
SELECT grantee FROM dba_role_privs WHERE granted_role = 'ROLE_A' - 组合两表，就能列出所有可能受影响的
grantee.owner.table_name组合，针对性补权
注意：如果角色还带 WITH ADMIN OPTION，那下游用户可能又转授给了别人，权限链更深——这种场景下，删角色的影响面远超表面可见的视图列表。
