表空间OFFLINE会导致其上所有对象状态变为INVALID，因Oracle禁止访问离线段；须先恢复表空间ONLINE并确保数据文件可用，再重新编译依赖对象。
表空间 OFFLINE 会直接让上面的对象变成 INVALID
Oracle 不允许在 OFFLINE 表空间里访问任何段对象（表、索引、LOB、物化视图等）。一旦表空间被置为 OFFLINE，所有位于该表空间中的对象在 ALL_OBJECTS 或 USER_OBJECTS 中的 STATUS 会立刻变为 'INVALID'，哪怕过程本身语法完全正确、依赖也没变。这不是编译错误，而是 Oracle 的运行时强制隔离机制：它拒绝加载或执行任何引用了离线段的对象。
常见触发场景包括：
- 人工执行
ALTER TABLESPACE users OFFLINE IMMEDIATE后未及时恢复 - 磁盘满导致 DBWn 写失败，Oracle 自动把表空间设为 OFFLINE（不是人工操作）
- 数据文件被误删或 ASM diskgroup offline，间接使表空间不可用
存储过程调用时才暴露问题，但根源不在过程本身
过程可能之前一直能编译通过，STATUS 是 'VALID'；一旦它内部 SELECT 一张在 OFFLINE 表空间里的表，首次执行就会报 ORA-00376: file X cannot be read 或 ORA-00942: table or view does not exist——注意，后者不是真不存在，而是 Oracle 在解析阶段就因表空间离线而拒绝定位该段。
关键点：
-
USER_DEPENDENCIES里仍能看到该表被引用，但ALL_OBJECTS中这张表的STATUS已是'INVALID' - 过程自身状态不会自动变成
'INVALID'，除非你显式ALTER PROCEDURE xxx COMPILE，此时解析器会检查依赖对象可用性，失败则标为INVALID - 即使过程没被重编译，只要调用路径触及离线表空间中的对象，就会立即中断
为什么不能只编译过程来修复？
单纯对存储过程执行 ALTER PROCEDURE xxx COMPILE 解决不了根本问题。因为编译只是做语法和依赖解析，而离线表空间里的对象仍不可访问。编译会失败，并在 ALL_ERRORS 中留下类似错误：
PLS-00905: object SCOTT.EMP is invalid
这意味着：你得先让表空间回到 ONLINE 状态，且其中所有数据文件都可读写，才能让依赖对象“活过来”。否则，任何基于这些对象的编译或执行都会卡在解析层。
典型修复链路是：
- 查
v$datafile和df -h，确认表空间离线是否由磁盘满、文件丢失或权限问题引起 - 释放空间 / 恢复文件 / 修正路径后，按归档模式走对应流程：
RECOVER DATAFILE（ARCHIVELOG）或OFFLINE DROP（NOARCHIVELOG，仅限非关键表空间） - 再执行
ALTER DATABASE DATAFILE ... ONLINE→ALTER TABLESPACE ... ONLINE - 最后才轮到
ALTER PROCEDURE xxx COMPILE——这时才有意义
容易被忽略的隐性依赖
有些过程看似没直接查业务表，却仍会失效，比如：
- 用了
SELECT * FROM v$session这类动态性能视图——它们底层依赖SYSTEM表空间，而SYSTEM绝对不能 OFFLINE；若有人误操作或 ASM 故障波及 SYSTEM，整个实例都可能 hang - 过程里调用了同义词（
SYNONYM），而该同义词指向一张在 OFFLINE 表空间里的表 - 包体（
PACKAGE BODY）里声明了基于离线表的游标变量或记录类型，即便没执行到那部分代码，编译时也会校验
真正棘手的是：表空间 ONLINE 了，过程也 COMPILE 成功了，但第一次调用仍报 ORA-04068——这往往是因为包状态被清空后，会话还缓存着旧上下文。别急着重跑，先 ALTER SYSTEM FLUSH SHARED_POOL 或重启会话。
