TEMP表空间文件丢失后数据库仍可启动，但执行排序等操作会报ORA-01157/ORA-01652；必须用ALTER TABLESPACE ADD TEMPFILE重建，而非RMAN恢复或CREATE TEMPORARY TABLESPACE，且需同步处理PDB容器、用户默认设置及应用连接池。
TEMP 表空间文件丢失后，数据库仍能启动，但执行排序、哈希连接、全局临时表操作时会直接报 ORA-01157 或 ORA-01652 ——这不是“恢复问题”，而是“重建问题”。Oracle 明确禁止对临时文件做介质恢复，ALTER DATABASE RECOVER 对它无效，RMAN 也根本不会备份或还原 tempfile。
为什么 RMAN list failure 找不到 temp 文件丢失？
rman 的故障检测机制（list failure / advise failure）完全不覆盖临时文件。它只关注数据文件、控制文件、归档日志等可恢复对象。dba_temp_files 视图里查不到记录，或状态为 offline，就是唯一可靠信号。别指望 rman 主动提醒你 temp 挂了。
必须用 ALTER TABLESPACE ADD TEMPFILE，不是 CREATE TEMPORARY TABLESPACE
除非原 TEMP 表空间已彻底损坏（比如 DROP TABLESPACE TEMP INCLUDING CONTENTS AND DATAFILES），否则优先走 ALTER TABLESPACE ... ADD TEMPFILE。原因很实际：
-
CREATE TEMPORARY TABLESPACE会建全新表空间，你得手动把所有用户默认临时表空间切过去（ALTER USER ... TEMPORARY TABLESPACE），还可能漏掉 PDB 级设置 -
ALTER TABLESPACE TEMP ADD TEMPFILE直接扩容，不影响现有用户配置和应用行为 - 如果原路径磁盘满或权限异常，
ADD TEMPFILE支持指定新路径，比如：ALTER TABLESPACE TEMP ADD TEMPFILE '/u02/oradata/ORCL/temp02.dbf' SIZE 100M AUTOEXTEND ON NEXT 64M
PDB 和 CDB 的 temp 文件要分开处理
Oracle 12c+ 是多租户架构，CDB$ROOT、PDB$SEED、每个 PDB 都有自己独立的临时文件。不能只修根容器就以为万事大吉：
- 先确认当前容器：
SHOW CON_NAME；如在CDB$ROOT，需分别处理：SELECT NAME, CON_ID FROM V$TEMPFILE - CDB 的 temp 文件在
CDB$ROOT下重建；PDB 的 temp 文件必须先ALTER SESSION SET CONTAINER = pdb_name，再执行ALTER TABLESPACE ... ADD TEMPFILE - 千万别在 PDB OPEN 状态下删 tempfile：会卡住
RECOVER或导致ORA-01153；稳妥做法是先ALTER PLUGGABLE DATABASE pdb_name CLOSE IMMEDIATE
重建后仍有 ORA-01652？检查三件事
新加的 tempfile 已存在且 ONLINE，但应用仍报无法扩展临时段，大概率是旧会话没释放句柄：
- 查残留临时段：
SELECT SEGMENT_NAME, SESSION_ADDR FROM V$SORT_SEGMENT WHERE TABLESPACE_NAME = 'TEMP'，再关联V$SESSION看是否还有活跃会话绑定着已失效 tempfile - 用户默认临时表空间没同步：即使数据库级
DEFAULT_TEMP_TABLESPACE改了，已有用户仍可能指向旧空间，逐个确认：SELECT USERNAME, TEMPORARY_TABLESPACE FROM DBA_USERS WHERE USERNAME NOT IN ('SYS','SYSTEM') - 应用连接池缓存旧连接：Tomcat、WebLogic 等 JDBC Pool 不会自动感知 tempfile 变更，必须清空连接池或重启应用服务
