不能直接 restore tablespace，因 drop 后控制文件已清除其元数据，rman 查不到数据文件而报 rman-06023；必须用 tspitr 退回到删除前时间点，且需满足：archivelog 模式、归档连续、时间早于 drop 时刻。
误删表空间后，recover tablespace 不能直接“还原被 drop 的表空间”，必须用基于时间点的不完全恢复（tspitr），且该时间点必须早于 drop tablespace 命令执行时刻——否则恢复出来的仍是空的、已被标记为删除的状态。
为什么不能直接 RESTORE TABLESPACE？
Oracle 表空间被 DROP TABLESPACE 后，控制文件中对应的数据文件记录会被清除，RMAN 查不到该表空间的任何数据文件信息，执行 RESTORE TABLESPACE users 会报 RMAN-06023: no backup or copy of datafile found to restore。这不是备份缺失，而是元数据已从控制文件中消失。所以必须退回到删除前的时间点，让控制文件“还记得”这个表空间存在。
执行 TSPITR 前必须确认的三件事
缺一不可，否则 RMAN 会在第一步就失败：
- 数据库必须处于
ARCHIVELOG模式（SELECT log_mode FROM v$database返回ARCHIVELOG） - 归档日志链必须连续覆盖目标恢复时间点（查
v$archived_log，确保APPLIED = 'YES'的归档序列号无断点） - 目标时间点必须早于
DROP TABLESPACE的确切时间（可通过DBA_AUDIT_TRAIL或告警日志定位，误差建议留 5 分钟余量）
RMAN 中执行表空间级不完全恢复的关键步骤
注意：不是在原库上操作，而是通过辅助实例完成，避免影响生产库；整个过程会自动创建临时辅助库（auxiliary instance），你只需提供足够磁盘空间和正确参数。
- 在 RMAN 中指定辅助实例位置：
SET AUXILIARY INSTANCE TO '/tmp/aux_ora'（路径需有写权限） - 启动 TSPITR：
RECOVER TABLESPACE users UNTIL TIME "TO_DATE('2026-05-14 15:28:00','YYYY-MM-DD HH24:MI:SS')" - 若要恢复到其他用户下或重命名表空间，加
REMAP TABLESPACE users TO users_restored - 恢复完成后，RMAN 会自动生成一个
.dmp文件（默认在AUXILIARY DESTINATION），需手动用impdp导入目标库，或用NOTABLEIMPORT跳过导入只导出 dump
最容易被忽略的两个细节
一是辅助实例的 db_name 必须与目标库不同，否则 RMAN 创建失败并残留后台进程；二是 UNTIL TIME 指定的时间点必须精确到秒——如果只写到分钟（如 '2026-05-14 15:28'），RMAN 默认按当天零点解析，导致恢复失败或恢复错版本。真实环境里，90% 的 TSPITR 失败都卡在这两处。
