ora-01658错误源于表空间缺乏足够大的连续空闲块，而非总空间不足；需查dba_free_space中max(bytes)确认最大连续块大小，若小于对象initial值即为碎片问题，可临时调小initial或清理回收站、收缩段根治。
ORA-01658 不是权限或语法问题，而是表空间里找不到足够大的连续空闲块 —— 即便 DBA_FREE_SPACE 显示还有几百 MB 剩余，只要最大连续块（MAX(BYTES)）小于你要创建对象所需的 INITIAL 大小，就会报错。
查清到底缺的是“总量”还是“连续块”
先别急着加数据文件。很多 DBA 一看到“表空间满”就扩容，结果发现加完还是报错 —— 因为真正卡住的是碎片，不是总量。
- 查总剩余空间（容易误导）：
SELECT tablespace_name, SUM(bytes)/1024/1024 AS free_mb FROM dba_free_space GROUP BY tablespace_name;
- 查**最大连续空闲块**（关键！）：
SELECT tablespace_name, MAX(bytes) AS max_contiguous_bytes FROM dba_free_space WHERE tablespace_name = '<code>YOUR_TS_NAME</code>' GROUP BY tablespace_name;
- 对比你建对象时请求的
INITIAL值：比如CREATE TABLE t(x INT) STORAGE(INITIAL 8M)就需要至少 8MB 连续空间；没显式写则按表空间默认策略推算（ASSM 下常为 64KB–1MB，但高负载后可能飙升）
临时绕过：降低 INITIAL 或延迟段创建
上线前救火最有效，不改架构、不等维护窗口。
- 显式指定小
INITIAL：CREATE TABLE t(x INT) STORAGE(INITIAL 64K)—— 注意单位是字节，64K是常见安全值 - 用
SEGMENT CREATION DEFERRED（Oracle 11.2+ 支持，19c 默认启用）：CREATE TABLE t(x INT) SEGMENT CREATION DEFERRED—— 表结构建好但不占空间，首次 INSERT 才分配，避开建表时的 INITIAL 需求 - 换表空间（如果确认其他表空间有足够连续块）：
CREATE TABLE t(x INT) TABLESPACE <code>USERS—— 别只看名字，要查MAX(BYTES)确认
根治：清理碎片 or 扩容策略优化
频繁出现 ORA-01658，说明表空间长期未维护。ASSM（自动段空间管理）下无法手动 coalesce，但仍有办法：
- 确认表空间类型：
SELECT tablespace_name, extent_management, segment_space_management FROM dba_tablespaces WHERE tablespace_name = '<code>YOUR_TS_NAME</code>';
如果是LOCAL+AUTO（即 ASSM），ALTER TABLESPACE ... COALESCE无效，别白试 - 检查数据文件是否启用了
AUTOEXTEND：SELECT file_name, autoextensible, increment_by, maxbytes FROM dba_data_files WHERE tablespace_name = '<code>YOUR_TS_NAME'; 没开 autoextend 的老数据文件，哪怕磁盘有空间也永远卡死 - 扩容优先加新数据文件（比 resize 更稳）：
ALTER TABLESPACE <code>YOUR_TS_NAMEADD DATAFILE '/u01/oradata/db19c/ts02.dbf' SIZE 500M AUTOEXTEND ON NEXT 100M MAXSIZE 2G; - 若碎片严重且业务允许停机，可考虑导出→删除→重建表空间（仅限非系统表空间）
为什么 ALTER TABLE ... ALLOCATE EXTENT 解决不了 ORA-01658
这个命令只对**已存在段**生效，而 ORA-01658 发生在段还不存在时 —— Oracle 连第一个 extent 都分不出来，根本没段给你操作。
另外，DBA_FREE_SPACE 中的空闲块大小分布往往比想象中更碎：一个 2TB 表空间，MAX(BYTES) 可能只剩 128KB，而某次建索引默认要 4MB。这种细节，不查 MAX(BYTES) 永远看不到真实瓶颈。
