临时文件损坏无法用RMAN恢复，必须先OFFLINE DROP清理控制文件元数据，再重建TEMP表空间并更新默认及用户级设置。
临时文件损坏不能用 RMAN 恢复，必须重建表空间或替换 tempfile —— 因为 Oracle 根本不备份、不归档、不校验临时文件，RMAN 对 tempfile 的所有操作（RESTORE、RECOVER、DELETE）全部无效。
ORA-01157 报错时别碰 RMAN，先清理控制文件残留元数据
报 ORA-01157: cannot identify/lock data file 或 ORA-01110，说明控制文件里还记着一个已不可访问的 tempfile 路径。RMAN 无法修复它，强行执行 RESTORE TEMPFILE 会直接报 ORA-01275；DELETE ARCHIVELOG ALL 对它也完全没影响。
真正要做的，是让 Oracle “忘记”这个路径：
- 先查损坏文件：
SELECT FILE_NAME, STATUS FROM DBA_TEMP_FILES WHERE TABLESPACE_NAME = 'TEMP'; - 确认无活跃使用：
SELECT SID, SERIAL#, SQL_ID FROM V$SESSION WHERE TEMPSEG_SIZE > 0;—— 若有结果，评估是否可杀会话（尤其注意连接池长连接） - 强制脱机并清除元数据：
ALTER DATABASE TEMPFILE '/u01/oradata/ORCL/temp01.dbf' OFFLINE DROP;（注意：是OFFLINE DROP，不是DROP INCLUDING DATAFILES） - 验证是否清掉：再查
DBA_TEMP_FILES，该行应已消失
重建 TEMP 表空间优先用 CREATE TEMPORARY TABLESPACE，不是 ADD TEMPFILE
很多人试 ALTER TABLESPACE TEMP ADD TEMPFILE，结果新文件加进去了，但旧的 INVALID 记录还在 DBA_TEMP_FILES 里卡着——Oracle 临时段分配器会轮询所有条目，包括这些“幽灵文件”，导致间歇性 ORA-01652。
正确做法是建干净的新表空间：
- 新建：
CREATE TEMPORARY TABLESPACE temp_new TEMPFILE '/u02/oradata/ORCL/temp_new01.dbf' SIZE 200M AUTOEXTEND ON NEXT 64M; - 切全局默认：
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp_new; - 逐个改用户：
ALTER USER scott TEMPORARY TABLESPACE temp_new;（仅改数据库属性不够） - 旧表空间确认无人使用后，再
DROP TABLESPACE TEMP INCLUDING CONTENTS AND DATAFILES;
重建后应用仍报 ORA-01652？检查连接池和残留临时段
新建的 tempfile 不会自动接管老会话的临时段需求。已有连接可能还绑着失效句柄，尤其在 Tomcat、WebLogic 等连接池场景下，即使数据库端已切换，应用层仍在复用旧连接。
必须做两件事：
- 查残留临时段：
SELECT SEGMENT_NAME, SESSION_ADDR FROM V$SORT_SEGMENT WHERE TABLESPACE_NAME = 'TEMP';，再关联V$SESSION看是否真活跃；若已断连但段未释放，需重启实例或等超时（非紧急可观察） - 清空应用连接池：重启应用服务，或调用连接池管理接口主动 close 所有连接（如 Tomcat 的
/manager/html页面或 JMX 操作）
最容易被忽略的是：OFFLINE DROP 后不验证 DBA_TEMP_FILES 是否真清空，就急着建新表空间；或者只改了 DEFAULT_TEMP_TABLESPACE，却忘了批量更新用户级设置。这两步漏掉，问题只是延迟爆发，不是解决。
