ORA-01653/ORA-01658报错本质是缺乏连续extent而非总空间不足，需查DBA_FREE_SPACE中MAX(bytes)确认最大可用连续块；优先用ADD DATAFILE扩容，避免碎片整理，但须验证磁盘空间、权限及路径有效性。
ORA-01653/ORA-01658不是“没空间”，而是找不到连续块
Oracle建表、建索引或插入数据时，必须分配一个连续的空闲区段（extent），而不是拼凑一堆零碎空闲块。哪怕DBA_FREE_SPACE里总空闲有5GB，如果最大连续块只有2MB，而你要分配INITIAL 10M，就会直接报ORA-01658；同理，普通DML触发扩展失败则报ORA-01653。这不是磁盘满了，是“有粮但装不下整袋米”。
碎片怎么让连续块变小？三个关键机制
表空间碎片本质是空闲空间被切割成大量小块，根源在Oracle管理方式和操作习惯：
- 频繁
DELETE+INSERT（尤其批量）：行被删后留下空块，但HWM不降，新数据优先填HWM前的空隙，久而久之空块散落在各处 - 手动
ALTER TABLE ... SHRINK SPACE用得过勤：收缩会把数据往前挪，但释放的空间未必合并成大块，反而可能制造更多中等尺寸碎片 - ASSM（自动段空间管理）下PCTFREE设置不合理：比如设太高（30%），每个数据块预留太多空位，导致物理上相邻的块无法被合并为一个逻辑连续区段
查碎片不能只看“剩余多少”，要看“最大连续块”
别信SELECT SUM(bytes) FROM DBA_FREE_SPACE——它只告诉你总量。真正决定能否扩展的是最大可用连续块：
SELECT tablespace_name, MAX(bytes)/1024/1024 AS max_mb FROM dba_free_space WHERE tablespace_name = 'USERS' GROUP BY tablespace_name;
如果返回max_mb = 0.5，那任何INITIAL超过512KB的操作都会失败。顺带一提：DBA_FREE_SPACE记录的是“空闲区段”，不是“空闲字节”，一条记录对应一块连续空闲空间；记录越多，通常碎片越严重。
加文件 or 清碎片？优先选加文件，但得避开OS层陷阱
生产环境遇到扩展失败，ALTER TABLESPACE ... ADD DATAFILE比清理碎片快得多，也更安全：
- 它不锁表、不移动数据、不依赖磁盘连续空间，DML全程在线
- 但执行前必须确认：
df -h显示挂载点有空间，quota -u oracle没超硬限制，ls -ld /path/to/dir确保oracle用户有写权限 - 路径写错（比如ASM环境写了OS路径
/u01/...而非+DATA）会直接报ORA-17502，不是空间问题 - 临时表空间（
TEMP）和回滚表空间（UNDOTBS1）不支持ADD DATAFILE（12c+多租户除外），只能调大现有文件
碎片本身不会“自我修复”，只要业务持续写入，碎片就只会累积。加文件是止血，定期监控MAX(bytes)才是防复发的关键。
