ora-01654虽显示空闲空间充足，实因用户配额为0、maxbytes已达上限或磁盘物理空间不足三者之一阻断autoextend；须依次核查dba_ts_quotas配额、dba_data_files中autoextensible与maxbytes、df -h及alert.log磁盘真实空间。
空闲空间充足却报 ORA-01654，不是数据库“看错了”，而是它卡在了三个关键环节之一：用户配额为 0、数据文件 maxbytes 已达上限、磁盘物理空间已满。这三个条件必须同时满足，AUTOEXTEND ON 才能真正生效。
查用户在表空间的配额是否为 0
这是最隐蔽也最高频的原因——dba_free_space 显示有几百 MB 空闲，但用户就是插不进一条记录。新建用户默认 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查
查数据文件的 maxbytes 是否卡死
AUTOEXTEND ON 只是开关，真正起作用的是 maxbytes。很多 DBA 开了自动扩展，却忘了设 MAXSIZE，或设了个小值（比如 1G、32G），结果文件一涨到上限就停住。
- 查当前设置：
SELECT file_name, autoextensible, bytes/1024/1024 as size_mb, maxbytes/1024/1024 as maxsize_mb FROM dba_data_files WHERE tablespace_name = 'USERS'; - 若
maxsize_mb接近size_mb，说明已到顶；执行：ALTER DATABASE DATAFILE '/u01/oradata/db/users01.dbf' AUTOEXTEND ON MAXSIZE 64G; -
MAXSIZE必须小于文件系统可用空间，建议预留 ≥20% 缓冲；生产环境慎用UNLIMITED
查磁盘物理空间是否真实可用
dba_free_space 有空闲 ≠ 文件系统能写。Oracle 尝试扩展时若磁盘写满，会静默失败，并在 alert_<sid>.log</sid> 记录 ORA-01119 或 ORA-27041，但应用层只看到 ORA-01654。
- 立刻查磁盘：
df -h /u01/oradata/PROD（路径必须和dba_data_files.file_name完全一致） - 同步翻
alert_<sid>.log</sid>，搜索最近的ORA-错误，确认是否因磁盘满导致扩展中断 - 若磁盘使用率 ≥95%，且
autoextensible = 'YES'，必须立刻停用：ALTER DATABASE DATAFILE '/path/to/file.dbf' AUTOEXTEND OFF;，否则数据库可能 hang 住
真正容易被忽略的是：配额、maxbytes、磁盘空间这三者必须同时满足，AUTOEXTEND 才能生效。其中配额和 maxbytes 在 SQL*Plus 里查一下就能确认；磁盘空间则必须 OS 层和 Oracle 日志交叉验证——只看数据库视图，永远发现不了磁盘已满这个根因。
