ORA-01653/ORA-01658报错本质是空闲空间不连续，无法分配所需Extent：dba_free_space总和虽大，但最大连续块小于请求大小，且行数>200即碎片严重；ASSM下COALESCE无效，应依碎片程度选SHRINK SPACE、MOVE或TRUNCATE，并及时更新统计信息。
这不是空间真没了，而是 Oracle 分配机制卡在了“连续性”上——ORA-01653 或 ORA-01658 报错时，dba_free_space 显示有几 GB 空闲完全不矛盾。
为什么空闲空间总和很大，却无法建表或插入？
Oracle 不按字节分配，而是以 Extent（区）为单位申请连续空间。哪怕你有 5GB 碎片化空闲，但最大一块只有 2MB，而建索引需要一次性分配 8MB 的 Extent，就会直接失败。
-
dba_free_space每一行代表一段**物理连续**的空闲块；行数越多，碎片越严重 - ASSM 表空间下，频繁
DELETE+INSERT会导致位图标记混乱，新数据倾向写入新区而非复用旧块 - 传统 DMT 表空间中，
ALTER TABLESPACE ... COALESCE可合并相邻空闲Extent；但在 ASSM 下执行该命令**完全无效**，也不报错——这是最常踩的坑
怎么快速确认是碎片导致的“假性不足”？
先排除真容量问题，再聚焦连续性：
- 查数据文件是否已达上限：
SELECT file_name, autoextensible, maxbytes FROM dba_data_files WHERE tablespace_name = 'YOUR_TS'；若autoextensible = 'NO'且bytes = maxbytes，优先扩容 - 查最大连续空闲块：
SELECT MAX(bytes)/1024/1024 AS max_free_mb FROM dba_free_space WHERE tablespace_name = 'YOUR_TS'；如果结果远小于你要分配的Extent大小（如 0.3MB vs 需要 1MB），就是碎片卡住 - 查碎片程度：
SELECT tablespace_name, COUNT(*) FROM dba_free_space GROUP BY tablespace_name；>200 行基本可判定需整理
用户配额为 0 是最隐蔽的“空间不足”原因
表空间明明有空闲，SCOTT 用户却报 ORA-01653？大概率是没被赋权。
SELECT username, tablespace_name, max_bytes FROM dba_ts_quotas WHERE username = 'SCOTT' AND tablespace_name = 'USERS'- 若返回
max_bytes = 0，说明该用户在该表空间无任何配额；新建用户默认就是 0 - 修复命令：
ALTER USER SCOTT QUOTA UNLIMITED ON USERS或QUOTA 2G ON USERS
ASSM 表空间下真正有效的碎片整理方式
COALESCE 无效，得换思路：
- 对大表：先
ALTER TABLE ... SHRINK SPACE COMPACT（需启用行移动），再SHRINK SPACE降低高水位线（HWM） - 对无法 shrink 的表（如含
LONG类型）：用ALTER TABLE ... MOVE重建段，但需业务窗口且会锁表 - 极端碎片：考虑
TRUNCATE+ 重载（仅适用于可重建场景） - 所有操作后必须立即执行：
EXEC DBMS_STATS.GATHER_TABLE_STATS，否则优化器可能误判统计信息
碎片问题最难缠的地方在于它不报错、不告警，只在某次建索引或大批量插入时突然爆发；而 dba_free_space 的行数和 MAX(bytes) 这两个指标，比使用率百分比更能暴露真实风险。
