ORA-01653报错主因是数据文件MAXSIZE达32767M（32GB）上限或AUTOEXTENSIBLE关闭，需查dba_data_files确认当前大小、自动扩展状态及最大值，再针对性扩容或添加新文件。
ORA-01653 报错时，先查 AUTOEXTENSIBLE 和 MAXSIZE 是否已到顶
报 ora-01653 不代表磁盘满了，大概率是某个数据文件的 maxsize 已被设为 32767m（即 32gb）且当前 bytes 接近该值。oracle 11g 默认块大小为 8kb 时，单个数据文件物理上限就是 32gb —— 这不是 bug，是硬限制。
执行这条 SQL 查清现状：
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'：必须先开自动扩展，再调MAXSIZE - 若
max_mb是 32767 且curr_mb > 32000：说明快撞墙了，不能只改NEXT，得加新文件或调高MAXSIZE（但注意：32767M 是 32GB 的安全上限，设更大可能无效） - 若
max_mb = 0：表示禁用自动扩展，MAXSIZE本身无意义，先开AUTOEXTEND ON
修改 MAXSIZE 的正确写法和常见翻车点
ALTER DATABASE DATAFILE 是唯一能改单个数据文件 MAXSIZE 的命令，但参数顺序和单位极易出错。
- 必须带单位：
MAXSIZE 32767M合法，MAXSIZE 32767会被当成字节，实际只设了 32KB - 不能超过 32767M（约 32GB），否则报
ORA-02142: missing or invalid ALTER TABLESPACE option - 路径必须完全匹配
DBA_DATA_FILES.FILE_NAME，大小写、斜杠方向、空格都不能错（Windows 路径用双反斜杠或正斜杠都行，但别混用） - 执行前确认该文件所在磁盘还有空间，否则改完也扩不出去，后续会报
ORA-01119或ORA-27041
示例（安全写法）：
ALTER DATABASE DATAFILE '/u01/app/oracle/oradata/ORCL/users01.dbf' AUTOEXTEND ON NEXT 512M MAXSIZE 32767M;
为什么只改 MAXSIZE 往往不够用
很多 DBA 看到 MAXSIZE 到顶就猛调这个值，结果过两天又报错 —— 因为根本问题不在上限，而在增长策略不合理或空间碎片化。
-
NEXT设太小（如NEXT 1M）：每次只扩 1MB，高频写入下会频繁触发扩展，IO 毛刺明显，还容易卡在锁上 -
NEXT设太大（如NEXT 4G）：一次分配过大，可能直接跨过可用连续空间，导致扩展失败 - 已有数据文件内碎片多：
DBA_FREE_SPACE显示总空闲够，但没有单个 >8MB 的连续 extent，ORA-01653照样报 - 用户配额（
QUOTA）没开：即使表空间有 20GB 空闲，用户max_bytes = 0，照样不能写
建议搭配执行：ALTER TABLESPACE USERS COALESCE; 整理碎片；再查 DBA_TS_QUOTAS 确认用户额度。
长期稳定方案：别死磕单文件，用多文件分摊压力
靠不断调高 MAXSIZE 是饮鸩止渴。Oracle 官方推荐方式是为表空间添加第二个（甚至第三个）数据文件，而非把一个文件撑到极限。
- 新文件路径要和原文件不在同一磁盘分区，避免 IO 瓶颈集中
- 初始
SIZE建议设为 2–5GB，比NEXT值大，减少首次扩展次数 - 新文件也开
AUTOEXTEND ON，但MAXSIZE仍设为 32767M，保持统一管理边界 - 加完立即执行
ALTER TABLESPACE USERS COALESCE;，让 Oracle 重新平衡 extent 分配
加文件命令示例：
ALTER TABLESPACE USERS ADD DATAFILE '/u02/oradata/ORCL/users02.dbf' SIZE 3G AUTOEXTEND ON NEXT 512M MAXSIZE 32767M;
真正难处理的从来不是 MAXSIZE 数值本身，而是搞不清它到底受制于数据库块大小、文件系统限制，还是管理员手抖填错了单位。每次改之前，先 SELECT 一眼当前值，比凭记忆重试三次更省时间。
