应急扩容需在ORA-01653/01654报错前5–10分钟内完成，核心是快速定位瓶颈（used_percent>92%且free_space
应急扩容不是“先扩再说”，而是必须在 ORA-01653 或 ORA-01654 报错前 5–10 分钟内完成判断与操作。真正能救火的，只有三件事：快速定位瓶颈、选对扩容路径、避开 RAC/ASM/LOCAL UNDO 的隐性陷阱。
怎么快速确认是不是真要立刻扩？
别一看到告警就跑 SQL。先看两个关键事实：
- 查
dba_tablespace_usage_metrics，但只信used_percent > 92%且free_space 的组合——低于这个阈值，长事务或批量导入可能在 3 分钟内触发报错 - 用
SELECT * FROM v$session WHERE event LIKE 'enq: TS - contention'确认是否有会话卡在表空间争用上；有，说明已开始阻塞，必须立即干预 - 跳过“分析历史增长趋势”环节——应急场景下，
dba_hist_tbspc_space_usage没时间等 AWR 快照刷新
RESIZE 还是 ADD DATAFILE？看这三点
选错方式会导致扩容失败、IO 崩盘，甚至误删文件：
- 如果数据文件路径是
+DATA/ORCL/DATAFILE/users.256.12345（ASM 格式），优先用ALTER DATABASE DATAFILE '+DATA/ORCL/DATAFILE/users.256.12345' RESIZE 8G—— ASM 下RESIZE是元数据操作，秒级完成；ADD DATAFILE要分配 AU，慢且可能触发 rebalance - 如果路径是
/u01/oradata/ORCL/users01.dbf且所在磁盘df -h /u01/oradata剩余 RESIZE，改用ALTER TABLESPACE users ADD DATAFILE '/u02/oradata/ORCL/users02.dbf' SIZE 4G，避免填满根分区 - RAC 环境下，
UNDOTBS1和UNDOTBS2是独立对象，不能共用一条ADD DATAFILE语句——必须连到节点 1 扩UNDOTBS1，再连节点 2 扩UNDOTBS2
自动扩展（AUTOEXTEND）能不能开？
可以开，但必须加锁死条件：
- 永远不要设
MAXSIZE UNLIMITED—— 文件系统可能被撑爆，ASM 磁盘组也可能因无节制分配导致 rebalance 卡住 - 生产库推荐
AUTOEXTEND ON NEXT 256M MAXSIZE 16G，这个组合能扛住多数单次大插入，又不会失控 - 临时表空间（
TEMP）可设更激进的NEXT 512M，但必须配监控：SELECT tablespace_name, file_name, maxbytes/1024/1024/1024 GB FROM dba_temp_files，防它偷偷吃光磁盘 - SYSTEM/SYSAUX 表空间禁止启用
AUTOEXTEND—— 它们的增长意味着数据字典异常膨胀，该查对象而非扩容
最常被跳过的一步：扩容后立刻执行 SELECT file_name, status FROM dba_data_files WHERE tablespace_name = 'XXX'。状态为 OFFLINE 或 RECOVER 的文件不会参与空间分配，表面扩容成功，实际无效。
