ORA-01653/ORA-01654 根本原因是表空间数据文件已满且无法扩展，首要检查 autoextensible 是否为 YES；若为 NO，则需启用自动扩展或手动添加数据文件，并确保文件系统空间、maxsize、权限及UNDO/TEMP特殊规则均满足。
ORA-01653 / ORA-01654 出现时，先看数据文件是否启用了自动扩展
这类错误本质是表或索引在插入/扩展时无法分配新区（extent），根本原因是所在表空间的数据文件已满且无法增长。关键第一步不是加文件，而是确认 autoextensible 是否为 yes：
- 查当前数据文件状态：
SELECT file_name, bytes/1024/1024 MB, maxbytes/1024/1024 MAX_MB, autoextensible, increment_by*8/1024 INC_MB FROM dba_data_files WHERE tablespace_name = 'YOUR_TS';
- 如果
autoextensible是NO，即使磁盘还有空间，Oracle 也不会自动扩展——这是最常被忽略的配置项 -
increment_by单位是 Oracle 数据块数，实际增长大小 =increment_by × db_block_size（通常 8KB），别误以为是 KB 或 MB
启用自动扩展前必须检查文件系统剩余空间和 maxsize 上限
盲目开 autoextend on 可能导致磁盘写满、数据库 hang 住，尤其在共享存储或容器环境中：
- 用 OS 命令确认对应路径可用空间：
df -h /u01/oradata/PROD/ - 设置
maxsize必须小于文件系统可用空间，建议预留 20% 以上缓冲，例如：ALTER DATABASE DATAFILE '/u01/oradata/PROD/users01.dbf' AUTOEXTEND ON NEXT 128M MAXSIZE 30G;
- 若已有文件
maxsize达到上限但空间仍不足，ORA-01653仍会触发——此时必须新增数据文件，不能只调大maxsize
手动扩容比自动扩展更可控，但要注意表空间类型与段管理方式
对于核心业务表空间，推荐停用自动扩展，改用计划性扩容。操作前需确认：
- 表空间是否为
locally managed（9i+ 默认）：查dba_tablespaces.segment_space_management，避免在dictionary-managed表空间中混用手动 + 自动策略 - 新增数据文件路径权限和磁盘配额：Oracle 用户必须有写权限，且 SELinux/AppArmor 未拦截（常见于 RHEL/CentOS）
- 若使用 ASM，路径应为
+DATA/PROD/DATAFILE/users02.dbf，而非本地文件系统路径 - 执行扩容后，立刻验证：
SELECT tablespace_name, sum(bytes)/1024/1024 MB_USED FROM dba_segments WHERE tablespace_name = 'YOUR_TS' GROUP BY tablespace_name;
确保新空间已被识别
临时表空间和 UNDO 表空间的扩容逻辑完全不同
这两类表空间不适用常规的“加数据文件”套路，处理方式有强约束：
-
TEMP表空间：不能设autoextend on在临时文件上（11g+ 允许，但不推荐）。更稳妥的是添加新临时文件：ALTER TABLESPACE temp ADD TEMPFILE '/u01/oradata/PROD/temp02.dbf' SIZE 512M;
-
UNDOTBS1：UNDO 表空间的自动扩展受undo_retention和retention guarantee影响极大。单纯加文件可能无效，需同步检查：SELECT max(maxquerylen) FROM v$undostat;若值远大于当前undo_retention，说明需要调高该参数或增加 UNDO 表空间大小 - UNDO 表空间禁止删除非空数据文件，收缩操作极危险，基本只能增不能减
dba_free_space 和 v$undostat 加进日常巡检脚本里。 
