能，但有前提：临时表空间的tempfile被删后实例可启动，问题在首次需临时段操作时触发ora-01157等错误；正确处理是先offline drop再add tempfile重建。
temp文件被误删后数据库还能正常启动吗
能，但有前提：临时表空间的 tempfile 被删，只要没执行过需要排序/哈希等操作（比如大查询、建索引），实例通常照常启动。一旦触发磁盘排序，就会报错 ORA-01157: cannot identify/lock data file 或 ORA-01110，这时会卡在等待状态或直接报错。
- 实例启动不依赖
tempfile的物理存在，只校验控制文件里记录的路径 - 真正出问题是在第一个需要临时段的操作时，不是启动时
- 如果是 ASM 环境，删的是 ASM alias 而非实际 AU，行为略有不同，但表现类似
用 ALTER DATABASE TEMPFILE … DROP INCLUDING DATAFILES 可以直接删掉坏路径
不能直接删——这条命令要求文件当前处于 OFFLINE 状态，而丢失的 tempfile 实际上是“不可访问”，不是逻辑 offline。强行运行会报 ORA-01516: nonexistent log file, datafile or tempfile。
正确做法是先让 Oracle “忘记”这个路径：
- 运行
ALTER DATABASE TEMPFILE '/path/to/lost_temp01.dbf' DROP INCLUDING DATAFILES;会失败 - 必须先用
ALTER DATABASE TEMPFILE '/path/to/lost_temp01.dbf' OFFLINE DROP;
（注意：不是DROP INCLUDING DATAFILES，是OFFLINE DROP） - 这条命令不检查文件是否存在，只从控制文件中移除记录
- 执行后立刻生效，无需重启
重建TEMPFILE必须指定新的文件路径和大小
重建不是“恢复”，而是新建一个功能等价的临时文件。关键点在于：
- 必须用
ALTER TABLESPACE TEMP ADD TEMPFILE，不能用CREATE TEMPORARY TABLESPACE（除非你打算换表空间名） - 新路径不能和原路径重名（即使文件已不存在，Oracle 仍可能报
ORA-25153: Temporary Tablespace is Empty类错误） - 大小建议 ≥ 原值，否则后续大排序可能频繁扩展，影响性能
- 如果是 OMF（Oracle Managed Files）环境，可省略路径，用
SIZE 100M AUTOEXTEND ON让 Oracle 自动分配
示例：
ALTER TABLESPACE TEMP ADD TEMPFILE SIZE 200M AUTOEXTEND ON NEXT 50M MAXSIZE 2G;
重建后临时段使用是否立即生效
是，但要注意两个隐含行为：
- 新增的
tempfile默认状态为ONLINE，无需手动ALTER DATABASE TEMPFILE … ONLINE - 当前已连接会话的 PGA 中可能还缓存着旧临时段信息，但新 SQL 执行时自动绑定到新文件；老会话若正在跑长排序，可能仍在用已删除文件的句柄（Linux 下表现为文件被“deleted”但未释放空间），此时需 kill 会话或等其结束
- 检查是否生效：查
v$tempfile确认status = 'ONLINE'，再查v$sort_segment看tablespace_name是否指向正确表空间
临时表空间不像数据文件那样牵扯一致性检查，所以重建快、风险低——但正因为太简单，很多人跳过验证步骤，结果发现应用跑着跑着又报 ORA-01157，其实是忘了还有第二个 tempfile 没处理。
