ORA-01653错误本质是表空间内无法分配足够连续区段，须按序排查：用户配额是否为0、数据文件autoextensible状态及maxbytes限制、底层磁盘空间；配额为0和autoextensible关闭是最常见原因。
ora-01653 错误不是“磁盘满了”，而是表空间里找不到足够大的连续空闲区段——哪怕 dba_free_space 显示还有几 gb，也可能因配额为 0、autoextensible 关闭或 maxbytes 卡死而失败。必须按顺序查：用户配额 → 数据文件自动扩展状态 → 底层磁盘空间。
查用户在目标表空间的配额是否为 0
这是最隐蔽但高频的坑：表空间明明有空闲，SCOTT 用户却报 ORA-01653。原因就是该用户在 USERS 表空间没被显式赋权。
- 运行：
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 - 新建用户默认
max_bytes = 0，不手动赋QUOTA就无法写入任何表空间 - 多租户（PDB）场景下，
dba_ts_quotas必须查当前 PDB 的视图，不是CDB$ROOT
确认 autoextensible 是否开启且 maxbytes 足够
只开 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），或原文件所在磁盘快满了，直接加新文件更安全。
-
ADD DATAFILE操作在线、不阻塞 DML；而RESIZE会短暂锁住该文件上的所有 DML - 如果表空间是
SMALLFILE类型（默认），单个文件不能超 32GB；若需更大，得建BIGFILE表空间 - 新增后无需手动干预，Oracle 19c 默认启用自动段空间管理（ASSM）
- 注意路径权限和磁盘剩余空间，避免
ORA-01119报错
配额和自动扩展配置容易被忽略，尤其在 PDB 场景下；RESIZE 看似简单，但可能触发 IO 阻塞，而 ADD DATAFILE 虽安全，却要求你提前确认磁盘路径可用性——这两个动作的“副作用”比错误本身更值得警惕。
