如何恢复被DROP的表空间_基于时间点的表空间恢复TSPITR方案-Oracle-PHP中文网

ORA-01207报错源于控制文件SCN低于数据文件头SCN，需用更早的控制文件（如RMAN还原或备份控制文件），并确保辅助实例路径完整、归档日志连续、恢复后手动ONLINE表空间及重建UNUSABLE对象。

ORA-01207 文件头比控制文件新，说明控制文件太旧

做 tspitr 时最常见的报错就是 ora-01207，本质是恢复后的数据文件头 scn 高于当前控制文件里记录的 scn。这不是“恢复失败”，而是你用的控制文件没包含这个表空间被删前的状态——比如你用了当前在线控制文件，但它从 drop tablespace 之后就没重建过，自然不认新恢复进来的文件。

必须换一个“老一点”的控制文件：要么从 RMAN 备份中还原（RESTORE CONTROLFILE UNTIL TIME '...'），要么用备份控制文件（BACKUP CURRENT CONTROLFILE 生成的那个）。注意，不能直接拷贝当前控制文件来“假装老”，它的时间戳和 SCN 都对不上。

检查控制文件时间：SELECT CREATED FROM V$DATABASE;，对比你计划恢复到的时间点
RMAN 中还原控制文件后，必须执行 ALTER DATABASE MOUNT，再 RECOVER DATABASE，不能跳步
如果用了 RESETLOGS 之后的控制文件，就彻底没法做 TSPITR 了——它连那个表空间存在过的记录都没了

RMAN TSPITR 命令里必须显式指定辅助实例路径

RECOVER TABLESPACE ... AUXILIARY DESTINATION 看似只要填个目录就行，但实际这里填的不是“放备份的地方”，而是辅助实例（auxiliary instance）的整个工作根目录：包括参数文件、密码文件、归档日志临时存放点、甚至自动创建的控制文件。RMAN 会在这个路径下建子目录 adump、dpdump、oradata，缺一不可。

常见错误是填了个空目录，结果辅助实例启动失败，报 ORA-01078: failure in processing system parameters 或找不到 spfile。别指望 RMAN 自动帮你建好所有结构。

确保目标路径有足够空间（至少 2 倍于要恢复的表空间大小）
路径权限必须能让 Oracle 用户读写，且不能在 ASM 上直接指定裸路径（要用 +DG_NAME 格式）
如果数据库启用了 OMF（Oracle Managed Files），辅助实例的 DB_CREATE_FILE_DEST 必须明确设成该路径，否则 RMAN 可能往默认位置写文件导致混乱

恢复后必须手动将表空间 ONLINE 并检查段对象状态

TSPITR 完成后，表空间默认是 OFFLINE 状态，且里面所有数据文件都是 RECOVER 模式，不手动处理就无法访问。更隐蔽的问题是：即使 ONLINE 成功，部分索引或 LOB 段可能处于 UNUSABLE 状态，因为它们依赖的元数据在恢复过程中没同步更新。

不能只跑 ALTER TABLESPACE ... ONLINE 就完事。得立刻查 DBA_SEGMENTS 和 DBA_INDEXES，尤其关注 STATUS 列。

先执行：ALTER TABLESPACE tsp_name ONLINE;
再查：SELECT SEGMENT_NAME, SEGMENT_TYPE, STATUS FROM DBA_SEGMENTS WHERE TABLESPACE_NAME = 'TSP_NAME';
发现 UNUSABLE 索引，必须重建：ALTER INDEX owner.idx_name REBUILD;，不能等应用报错才处理

增量备份 + 归档日志缺失会导致恢复中断在中间时间点

TSPITR 不是“找最近一次全备还原”这么简单。RMAN 会按你指定的时间点（UNTIL TIME），往前找最晚的一次全备或增量备份作为起点，再应用其后的所有归档日志。如果某段归档日志被删了、或备份片损坏，恢复就会卡在那个断点，报 ORA-19505: failed to identify file 或 ORA-00308: cannot open archived log。

特别容易被忽略的是：归档日志路径在辅助实例里是重新映射的。RMAN 默认不会自动把主库的归档路径复制过去，得靠 SET ARCHIVELOG DESTINATION 或提前在辅助实例的 init.ora 里配好 LOG_ARCHIVE_DEST_1。