TEMP表空间暴涨不能直接删除文件，因为Oracle正占用该文件，强行删除会导致实例崩溃或ORA-01157错误；必须通过重建临时表空间并切换默认设置来安全清理。
TEMP 表空间暴涨后，为什么不能直接删 TEMP 文件
临时表空间暴涨通常意味着有大排序、哈希连接或全局临时表（global temporary table）在持续写入，但没被及时释放。此时 temp01.dbf 或 tempfile 文件可能已膨胀到几十 gb，而你发现 os 层面删不掉它——不是权限问题，是 oracle 正在用它。强行删除会导致实例崩溃或 ora-01157 错误。
- Oracle 启动时会校验所有
tempfile的存在性和头块一致性，缺失即报错 -
DROP TABLESPACE temp INCLUDING CONTENTS AND DATAFILES会失败，因为默认 TEMP 表空间不能被删除 - 即使停库删文件，重启时若控制文件里还记着这个
tempfile路径，就会卡在 mount 阶段
怎么安全清空 TEMP 表空间而不重启数据库
核心思路是：让 Oracle 主动释放已分配但未使用的空间，而不是物理删除文件。关键操作是重建临时文件的“逻辑容器”，而非碰磁盘文件本身。
- 先查当前使用情况：
SELECT tablespace_name, file_name, bytes/1024/1024 AS mb FROM dba_temp_files; - 创建新临时表空间：
CREATE TEMPORARY TABLESPACE temp_new TEMPFILE '/u01/oradata/db/temp_new01.dbf' SIZE 100M AUTOEXTEND ON NEXT 64M; - 切换默认临时表空间：
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp_new; - 等所有会话自然迁移到
temp_new（老会话仍用原 TEMP，但新排序都走新文件） - 确认无活跃使用后，再执行：
DROP TABLESPACE temp INCLUDING CONTENTS AND DATAFILES;
注意：temp 是默认名，实际名称请用 SELECT property_value FROM database_properties WHERE property_name = 'DEFAULT_TEMP_TABLESPACE'; 确认。
ORA-01652 无法扩展临时段时，别急着加文件
这个错误表面是空间不够，但真实原因常是：大量未提交事务持有临时段，或 PGA 设置过小导致频繁落盘。盲目增加 tempfile 只会让问题延迟爆发。
- 先查谁在占临时段：
SELECT s.sid, s.username, u.tablespace, u.segfile#, u.segblk#, u.blocks FROM v$session s, v$sort_usage u WHERE s.saddr = u.session_addr; - 检查
pga_aggregate_target是否过小（比如设成 256M 但服务器有 64G 内存），过小会迫使排序提前写入 TEMP - 确认 SQL 是否有隐式转换或缺失索引，导致本该走索引范围扫描的排序变成全表 + 大量
SORT ORDER BY - 临时加文件只是权宜之计：
ALTER TABLESPACE temp ADD TEMPFILE '/u01/oradata/db/temp02.dbf' SIZE 2G;，但必须配合后续清理动作
重启数据库前必须检查的三件事
如果已经决定重启，别直接 shutdown immediate —— 很多 TEMP 问题会在重启后复现，因为根本原因没解决。
- 确认所有长事务已提交或回滚，特别是含
INSERT /*+ APPEND */或CREATE TABLE AS SELECT的批处理 - 检查是否有未清理的全局临时表数据（
ON COMMIT DELETE ROWS类型在事务结束时自动清，但ON COMMIT PRESERVE ROWS会一直留到会话结束） - 验证控制文件中 TEMPFILE 记录是否和磁盘一致：
SELECT name FROM v$tempfile;和ls -l /u01/oradata/db/temp*.dbf对不上，说明有残留条目，需用ALTER DATABASE TEMPFILE '/old/path.dbf' DROP INCLUDING DATAFILES;清理
TEMP 文件本身不存永久数据，但它的异常增长永远是某个 SQL 或配置偏差的镜像。盯住 v$sort_usage 和 v$session，比反复删文件管用得多。
