ora-01653/01654在autoextend on后仍发生，根本原因是配额为0、maxbytes已达上限或磁盘物理空间不足，须依次排查这三项：先查dba_ts_quotas确认用户配额，再查dba_data_files中autoextensible与maxbytes设置，最后用df -h和alert.log交叉验证磁盘真实可用空间。
开启 AUTOEXTEND ON 后仍报 ORA-01653 或 ORA-01654，不是自动扩展没生效，而是它被卡在某个环节——常见原因有三个：配额为 0、maxbytes 已到上限、磁盘物理空间不足。别急着加文件，先查这三项。
用户在表空间的配额是否为 0
这是最隐蔽但高频的问题：表空间明明有空闲，用户却无法写入。新建用户默认 max_bytes = 0，等于“禁止写入”。即使 DBA 给了表空间，不显式赋权就完全无效。
- 查配额：
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 是 YES，但 maxbytes 卡死了
AUTOEXTEND ON 只是开关，真正起作用的是 maxbytes。很多 DBA 开了 autoextend，却忘了设 MAXSIZE，或者设了个小值（比如 1G、32G），结果文件一涨到上限就停住。
- 查当前限制：
SELECT file_name, autoextensible, maxbytes/1024/1024 AS max_mb FROM dba_data_files WHERE tablespace_name = 'USERS'; - 如果
autoextensible = 'YES'但max_mb接近当前大小，执行：ALTER DATABASE DATAFILE '/u01/oradata/db/users01.dbf' AUTOEXTEND ON MAXSIZE 32G; - 注意：
MAXSIZE必须小于文件系统可用空间，建议预留 ≥20% 缓冲；设UNLIMITED在生产环境极危险
磁盘已满，autoextend 扩展失败但没报错
dba_free_space 显示还有空闲 ≠ 文件系统能写。Oracle 尝试扩展时若磁盘写满，会静默失败，并在 alert_<sid>.log</sid> 记录 ORA-01119 或 ORA-27041，但应用层只看到 ORA-01653。
- 立刻查磁盘：
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 才能生效。其中配额为 0 和 maxbytes 卡死，在 SQL*Plus 里查一下就能确认；磁盘空间则必须 OS 层和 Oracle 日志交叉验证——只看数据库视图，永远发现不了磁盘已满这个根因。
