必须显式设置MAXSIZE，否则AUTOEXTEND ON默认UNLIMITED，生产环境等同于无限制；自动扩展绑定在单个DATAFILE上，ALTER TABLESPACE xxx AUTOEXTEND ON语法非法，须用ALTER DATABASE DATAFILE指定路径、NEXT和MAXSIZE。
必须显式设置 maxsize，否则 autoextend on 默认是 unlimited——这在生产环境等于没设限，磁盘被撑爆前几乎不会预警。
查清每个数据文件的真实状态再动手
表空间的自动扩展能力绑定在单个 DATAFILE 上，不是表空间整体可设。很多人执行 ALTER TABLESPACE users AUTOEXTEND ON 直接报 ORA-00905: missing keyword，因为该语法根本不存在。
先确认目标文件当前是否可扩、扩到哪了：
SELECT file_name, autoextensible, bytes/1024/1024 AS curr_mb, maxbytes/1024/1024 AS max_mb FROM dba_data_files WHERE tablespace_name = 'USERS';
- 若
autoextensible = 'NO'：得先开扩展，再设上限，不能跳步 - 若
max_mb = 0：说明MAXSIZE未生效（autoextensible关闭时该值无意义） - 若
max_mb = 32767：大概率是 Oracle 11g/19c 在db_block_size=8K下的隐式 32GB 封顶，再涨就报ORA-02142
ALTER DATABASE DATAFILE 是唯一有效路径
改 MAXSIZE 只能用 ALTER DATABASE DATAFILE，且单位必须写全，顺序不能错。常见翻车点：
-
MAXSIZE 32767❌：Oracle 当成字节，实际只设了 32KB -
MAXSIZE 32G✅：单位明确，推荐写法；32767M也合法，但易误读 - 路径大小写/斜杠方向不一致：Linux 下路径区分大小写，Windows 下正反斜杠都行，但别混用
- 一次改多个文件？别用脚本批量跑——
SYSTEM或UNDOTBS1文件路径写错一个，实例可能无法启动
安全示例：
ALTER DATABASE DATAFILE '/u01/oradata/ORCL/users01.dbf' AUTOEXTEND ON NEXT 128M MAXSIZE 32G;
NEXT 值不是越小越好，也不是越大越省事
NEXT 决定下一次扩展时加多少，不是“每次动态增长量”，它固定不变。选错会直接拖慢写入或浪费空间：
- OLTP 场景（高频小事务）：
NEXT 64M–256M平衡扩展频次与碎片；NEXT 1M会导致每秒多次扩展，IO 毛刺明显 - 批量加载/归档类表空间：
NEXT 500M–1G更合适，减少触发次数 -
NEXT 4G风险高：一次需连续 4GB 空间，若磁盘剩余 3.9GB 且不连续，扩展直接失败，后续仍报ORA-01653
别忽略底层约束：db_block_size=8K 时单文件理论极限约 32TB，但 ext4 文件系统通常卡在 16TB，ASM 外部冗余下单文件硬限 35TB——MAXSIZE 必须低于这些值，留出缓冲。
配额（QUOTA）和碎片常被当成“表空间有空闲”就忽略
ORA-01653 报错时，DBA_FREE_SPACE 显示还有 5GB 空闲？可能根本分不到用户头上。
- 查用户配额：
SELECT username, tablespace_name, max_bytes FROM dba_ts_quotas WHERE username = 'APP_USER' AND tablespace_name = 'USERS';—— 若max_bytes = 0，用户完全不能写，哪怕表空间空着 20GB - 碎片问题：
ALTER TABLESPACE USERS COALESCE;整理空闲 extent，尤其当DBA_FREE_SPACE中最大bytes小于建表所需 initial extent 时必报错 - 新增数据文件比
RESIZE更安全：ADD DATAFILE是在线操作，不锁表；而RESIZE在某些版本中会短暂阻塞 DML
真正稳住表空间，靠的不是单设 MAXSIZE，而是配额、碎片、文件系统空间、NEXT 增量四者同步校准。漏掉任何一环，监控告警还没响，磁盘先 df -h 显示 100%。
