临时文件autoextend on maxsize unlimited极危险，因笛卡尔积或全表扫描可在秒级耗尽磁盘，尤其在共享存储中会波及其他实例；必须设合理next（如256m）和maxsize（如8g）并验证路径权限。
为什么临时文件 autoextend 会失控
临时文件设成 AUTOEXTEND ON MAXSIZE UNLIMITED 后，某个 SQL 出现笛卡尔积或未加限制的全表扫描，几秒内就可能把磁盘打满。这不是 Oracle 的 bug，而是配置与业务负载严重不匹配的结果——MAXSIZE UNLIMITED 在共享存储、容器或 NFS 环境中尤其危险，因为磁盘空间是全局资源，一个库失控会影响整个宿主机或其他实例。
查当前临时文件的 autoextend 配置是否危险
别只看是不是开了 AUTOEXTEND ON，重点检查 MAXSIZE 和 NEXT 是否合理：
SELECT file_name, autoextensible, bytes/1024/1024 AS curr_mb, maxbytes/1024/1024 AS max_mb, increment_by * 8 / 1024 AS next_mb FROM dba_temp_files;- 若
max_mb是2147483645（即UNLIMITED），立刻调整 - 若
next_mb小于 64（比如 5 或 10），说明每次扩展太碎，IO 压力大且易触发频繁分配；若大于 512（比如 1024），单次增长过大，容易跨过安全水位
安全调整 autoextend 参数的实操步骤
停用无限扩展，改用“可控增长 + 明确上限”策略：
- 对已有文件调大
NEXT并设合理MAXSIZE：ALTER DATABASE TEMPFILE '/u01/oradata/db/temp01.dbf' AUTOEXTEND ON NEXT 256M MAXSIZE 8G; - 新增文件比改老文件更稳妥（在线、无锁、不影响当前排序）：
ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/oradata/db/temp02.dbf' SIZE 4G AUTOEXTEND ON NEXT 128M MAXSIZE 16G; - 路径必须由 DBA 确认有写权限；RHEL/CentOS 上还要检查 SELinux 是否拦截（
ausearch -m avc -ts recent | grep oracle） - 执行后立刻验证：
SELECT tablespace_name, file_name, autoextensible, maxbytes/1024/1024 AS max_mb FROM dba_temp_files WHERE tablespace_name = 'TEMP';
临时段长期不释放时，别只扩空间
如果 DBA_TEMP_FREE_SPACE.FREE_SPACE 持续偏低，但 dba_temp_files 显示文件没满，大概率是临时段被会话长期占用未释放——这和磁盘无关，是会话残留或 SMON 卡住：
- 查谁在吃空间：
SELECT s.sid, s.username, u.tablespace, u.segtype, u.blocks*8/1024 AS mb_used FROM v$sort_usage u, v$session s WHERE u.session_addr = s.saddr ORDER BY u.blocks DESC; - 确认无业务影响后杀掉异常会话：
ALTER SYSTEM KILL SESSION '123,4567' IMMEDIATE; - 强制合并碎片（无需重启）：
ALTER TABLESPACE TEMP COALESCE;
自动扩展本身不是问题，问题出在没配 NEXT 和 MAXSIZE 的边界。生产环境里，临时文件的增长必须像内存申请一样受控——你不会让一个进程 malloc 十个 GB 还不限制，临时文件也一样。
