ora-01113报错时不能直接alter tablespace online，必须先执行介质恢复；因数据文件已脱离一致性状态，需查v$recover_file确认error列非null后，按归档模式标准流程：offline for recover、restore、recover、online。
ORA-01113 报错时不能直接 ALTER TABLESPACE ONLINE
遇到 ORA-01113: file 7 needs media recovery，说明该数据文件已脱离一致性状态，控制文件记录的 SCN 高于文件头 SCN，必须先做介质恢复。跳过 RECOVER 直接执行 ALTER TABLESPACE ... ONLINE 会失败，且 OFFLINE DROP 在归档模式下也不可逆——它只是从控制文件中移除记录，不解决物理不一致问题。
关键判断依据不是表空间当前是 OFFLINE，而是查 v$recover_file：
- 若
ERROR列为NULL且STATUS是OFFLINE NORMAL，说明只是正常脱机，日志完整，可直接ALTER TABLESPACE ... ONLINE - 若
ERROR显示media recovery required或STATUS是RECOVER，就必须走恢复流程 - 若查询
v$recover_file返回空集，但仍有 ORA-01113，大概率是控制文件还记着已删的物理文件（比如 OS 层 rm 了 .dbf 但没用ALTER DATABASE DATAFILE ... OFFLINE DROP）
RMAN 恢复单个表空间的标准流程（归档模式下）
前提：数据库 OPEN、归档模式启用（ARCHIVELOG），且有可用归档日志和联机日志。
以表空间 OCPTBS 为例，标准操作链是：
-
ALTER TABLESPACE OCPTBS OFFLINE FOR RECOVER;（仅对非 SYSTEM 表空间有效；SYSTEM 表空间不能 offline，需用数据库级恢复） -
RMAN> RESTORE TABLESPACE OCPTBS;（如果数据文件物理丢失才需要这步；若文件还在但状态异常，可跳过） -
RMAN> RECOVER TABLESPACE OCPTBS;（自动应用归档日志 + 联机重做日志，补全到最新 SCN） ALTER TABLESPACE OCPTBS ONLINE;
注意：RECOVER TABLESPACE 不会自动校验块损坏。如果怀疑有坏块，恢复前先运行 RMAN> RESTORE TABLESPACE OCPTBS VALIDATE; 或恢复后用 DBVERIFY 扫描。
检查恢复后数据一致性不能只看 ONLINE 状态
表空间成功 ONLINE 只代表 Oracle 认为它“可用”，不代表里面的数据逻辑正确或无坏块。
必须额外验证：
- 用
ANALYZE TABLE ... VALIDATE STRUCTURE CASCADE;检查索引与表一致性（慎用于大表，会锁表） - 对关键业务表抽样 SELECT，确认主键、外键、约束字段值合理（例如日期没变成 1970-01-01，金额没变负数）
- 查
v$database_block_corruption是否为空；若有记录，说明恢复过程检测到坏块，需结合备份或 DBVERIFY 定位修复 - 如果恢复前用了
OFFLINE IMMEDIATE，尤其要关注未刷脏块是否丢失——这种场景下即使恢复成功，也可能存在少量事务回滚丢失
SYSTEM 表空间离线怎么办？
SYSTEM 表空间不能 offline，所以没有 ALTER TABLESPACE SYSTEM OFFLINE 这条路。一旦它异常离线或报 ORA-01113，只能走数据库级恢复：
- 关闭数据库：
SHUTDOWN ABORT - 启动到 MOUNT：
STARTUP MOUNT - 执行：
RECOVER DATABASE;（Oracle 自动识别哪些 datafile 需恢复） - 打开：
ALTER DATABASE OPEN;
如果归档日志缺失，RECOVER DATABASE 会失败，此时只能接受不完全恢复（RECOVER DATABASE UNTIL TIME ... 或 CANCEL），并做好数据丢失预期。SYSTEM 表空间损坏往往意味着字典视图、用户对象元数据出问题，恢复后务必检查 dba_tables、dba_indexes 等核心视图能否正常查询。
