ORA-01653 根因是表空间无法分配连续区段，常见于用户配额为0、数据文件MAXSIZE过小、碎片严重或磁盘满；需查dba_ts_quotas、autoextensible状态、alert.log及dba_segments定位。
ORA-01653 错误根本不是“磁盘满了”，而是表空间里拿不出连续的空闲区段来分配给表段——哪怕 dba_free_space 显示还有几 GB 空闲，也可能因配额为 0、数据文件卡死或碎片太碎而失败。
查用户在目标表空间的配额是否为 0
这是最隐蔽也最高频的根因：表空间明明有空闲，但用户一插数据就报 ORA-01653。新建用户默认 max_bytes = 0，等于没给任何写入权限。
- 执行：
SELECT username, tablespace_name, max_bytes FROM dba_ts_quotas WHERE username = 'SCOTT' AND tablespace_name = 'USERS'; - 若返回
max_bytes = 0，立刻赋权：ALTER USER SCOTT QUOTA UNLIMITED ON USERS;或指定额度如QUOTA 2G ON USERS - 多租户环境下，
dba_ts_quotas必须在当前 PDB 中查，CDB$ROOT 查不到
确认数据文件 autoextensible 状态和 MAXSIZE 是否合理
只开 AUTOEXTEND 不够，关键看 MAXBYTES 是否被设成了 1GB、32GB 这类明显偏小的值。
- 查状态：
SELECT file_name, bytes/1024/1024 AS curr_mb, maxbytes/1024/1024 AS max_mb, autoextensible FROM dba_data_files WHERE tablespace_name = 'USERS'; -
autoextensible = 'NO'：必须手工扩容，用ALTER DATABASE DATAFILE '/path/to/users01.dbf' RESIZE 8192M; -
autoextensible = 'YES'但max_mb接近当前值：调高上限，例如ALTER DATABASE DATAFILE '/path/to/users01.dbf' AUTOEXTEND ON MAXSIZE 32G; -
autoextensible = 'YES'且MAXSIZE足够，但扩容仍失败：立刻检查alert_<sid>.log</sid>，大概率是文件系统级磁盘已满（报ORA-01119或ORA-27041）
新增数据文件比 RESIZE 更安全且在线
单个数据文件接近操作系统限制（如 ext4 单文件上限 16TB），或原文件所在磁盘快满时，加新文件比硬扩旧文件更稳妥。
- 先确认路径磁盘空间：
df -h /u01/app/oracle/oradata/ - 执行新增：
ALTER TABLESPACE USERS ADD DATAFILE '/u01/app/oracle/oradata/ORCL/users02.dbf' SIZE 2048M AUTOEXTEND ON NEXT 128M MAXSIZE 32G; - Oracle 19c 默认启用 ASSM（
segment_space_management = AUTO），新增后无需手动干预；但注意：SMALLFILE 表空间（默认）单文件不能超 32GB，要更大需建 BIGFILE
别忽略碎片和大对象的真实占用
dba_free_space 显示的“空闲”可能是大量小碎片拼出来的，无法满足一次扩展所需的连续块。尤其当表含 LOB 段或长期未维护时，dba_segments 中的实际占用可能远超预期。
- 查大表：
SELECT owner, segment_name, segment_type, bytes/1024/1024 AS mb FROM dba_segments WHERE tablespace_name = 'USERS' ORDER BY bytes DESC FETCH FIRST 10 ROWS ONLY; - 若发现某张表异常占大（比如几百 MB 以上），且业务允许，可考虑
TRUNCATE TABLE xxx;快速释放空间（注意：不是DELETE） - 不要依赖
dba_free_space的总和判断“还有多少空”，要结合coalesce操作或新增数据文件来绕过碎片问题
