REVOKE 会导致视图或存储过程变 INVALID，因Oracle采用懒编译机制，仅在首次调用时校验权限；撤权后依赖对象（如含静态SQL的视图、过程）因缺失底层表权限而编译失败，状态转为INVALID。
REVOKE 为什么会让视图或存储过程变 INVALID
Oracle 不会在你执行 REVOKE 时主动检查依赖对象，但它会标记那些“运行时需要该权限才能合法执行”的对象为 INVALID。比如用户 A 有 SELECT ON scott.emp，又基于它创建了视图 v_emp；当你对 A 执行 REVOKE SELECT ON scott.emp FROM A，v_emp 本身不被删，但它的定义已无法通过权限校验——下次调用时 Oracle 就会尝试重新编译，而编译失败（因 A 已无底层表权限），于是状态变成 INVALID。
常见错误现象：
- 查询视图报
ORA-04045+ORA-16000（尤其在只读从库上） - 调用存储过程报
PLS-00905: object XXX is invalid -
SELECT * FROM user_objects WHERE status = 'INVALID'能查出一堆对象
这不是 bug，是 Oracle 的“懒编译”机制：对象只在首次调用时验证权限链完整性。
哪些对象会被连带影响
不是所有引用都算硬依赖。Oracle 只对以下情况触发 INVALID：
- 视图、物化视图、数据库链接（DB Link）中直接写死表名（如
SELECT * FROM scott.emp） - 存储过程/函数/包体里静态 SQL 引用该对象（不含动态拼接）
- 同义词指向的对象，若同义词所有者无对应权限，也会让调用方报错（但同义词自身状态不变）
软依赖不会触发失效，例如：
- EXECUTE IMMEDIATE 'SELECT * FROM ' || v_table_name
- 使用绑定变量或 DBMS_SQL 构建的语句
- 角色间接授予的权限（如 A 有角色 R，R 有 SELECT 权限；撤销 R 不会让视图失效，除非显式撤掉对象级权限）
如何提前发现和避免失效
先查依赖再操作，别等报错才补救：
- 查直接依赖：
SELECT owner, name, type FROM all_dependencies WHERE referenced_owner = 'SCOTT' AND referenced_name = 'EMP' AND referenced_type = 'TABLE' - 查当前用户下所有可能受影响的对象：
SELECT object_name, object_type FROM user_objects WHERE status = 'VALID' AND object_type IN ('VIEW', 'PROCEDURE', 'FUNCTION', 'PACKAGE')，再人工核对定义中是否含目标表 - 撤权前加
ALTER SESSION SET CURRENT_SCHEMA = target_schema，模拟目标用户视角测试关键 SQL 是否仍可跑
容易踩的坑：
- 在主库撤权后忘了去从库手动编译（ALTER VIEW v_emp COMPILE）
- 用 REVOKE ... CASCADE —— Oracle 不支持这个语法，写了直接报错 ORA-00922: missing or invalid option
- 撤的是角色权限（如 REVOKE SELECT_CATALOG_ROLE FROM alice），但没意识到该角色还附带其他隐式权限，导致意外连锁失效
失效后怎么快速恢复
对象变 INVALID 不代表数据丢了，只是元数据校验卡住：
- 主库上逐个编译：
ALTER VIEW v_emp COMPILE、ALTER PROCEDURE p_test COMPILE - 批量生成编译语句：
SELECT 'ALTER ' || object_type || ' ' || object_name || ' COMPILE;' FROM user_objects WHERE status = 'INVALID' AND object_type IN ('VIEW','PROCEDURE','FUNCTION','PACKAGE','TRIGGER') - 全量编译指定 schema：
EXEC DBMS_UTILITY.compile_schema('SCOTT')（注意：此操作会锁对象，避开业务高峰）
最麻烦的情况是：多个对象形成循环依赖，或依赖链跨 schema 且权限分散。这时候单靠 COMPILE 不够，得回溯原始 REVOKE 动作，确认是否真有必要撤掉那条权限——有时宁可新建一个受限账号，也不动老账号的权限基线。
