ORA-01119报错主因是语法或环境适配错误：路径须单引号包裹、单位须大写（如500M）、OMF启用时不可指定文件名、ASM环境须用别名格式（如'+DATA/...'），且执行后需验证文件状态、表空间读写性及归属。
ALTER TABLESPACE ADD DATAFILE 语法写错就报 ORA-01119
直接执行 ALTER TABLESPACE ... ADD DATAFILE 报 ORA-01119: error in creating database file，八成是语法或环境适配问题。这不是权限或磁盘空间不够的信号，而是语句本身被 Oracle 拒绝解析。
- 路径必须用单引号包裹，
'/u01/oradata/ORCL/users02.dbf'✅；裸写/u01/oradata/ORCL/users02.dbf❌，会直接报错 - 大小单位必须大写且带单位，
500M✅；500m、500MB、500（漏单位）在多数版本中都会失败 - OMF（Oracle Managed Files）启用时，不能指定路径和文件名，只允许写
SIZE 500M AUTOEXTEND ON，文件由DB_CREATE_FILE_DEST自动分配 - ASM 环境下路径格式固定为
'+DATA/ORCL/DATAFILE/users02.256.123456789'，不能套用 Linux 文件系统逻辑
新增文件后表还是插不进数据？先查 dba_data_files
执行完 ALTER TABLESPACE users ADD DATAFILE，INSERT 仍报 ORA-01653，不是语句没生效，而是新加的文件没真正“可用”。常见原因不是语法错，而是状态错。
- 立刻运行：
SELECT file_name, status, tablespace_name FROM dba_data_files WHERE tablespace_name = 'USERS'，确认新文件status是AVAILABLE，不是INVALID或空值 - 检查表空间是否只读：
SELECT tablespace_name, status FROM dba_tablespaces WHERE tablespace_name = 'USERS'，若status为READ ONLY，需先执行ALTER TABLESPACE USERS READ WRITE - 大小写敏感：数据库区分大小写时，
USERS≠users，拼错表空间名会导致文件被加到另一个同名但不存在的表空间（实际静默失败） - 文件创建成功但未加入分配列表的情况极少见，多发生在异常中断后；此时可尝试重启实例或手动
ALTER DATABASE DATAFILE ... ONLINE
AUTOEXTEND ON NEXT 和 MAXSIZE 怎么设才安全
AUTOEXTEND ON 不是“开了就不用管”，它只控制该文件自身增长行为，不影响其他文件，也不解决磁盘满的问题。设得不合理反而掩盖真实容量风险。
-
NEXT值不宜过小（如NEXT 1M），否则频繁扩展引发 I/O 毛刺，影响 OLTP 写入性能 -
NEXT也不宜过大（如NEXT 1G），一次分配远超当前所需，造成空间浪费且延迟发现磁盘瓶颈 -
MAXSIZE必须显式设置，MAXSIZE UNLIMITED在生产环境危险——一旦监控缺失，可能占满整个挂载点 - 推荐组合：
AUTOEXTEND ON NEXT 100M MAXSIZE 2G，再配合定期巡检：SELECT SUM(bytes)/1024/1024 AS free_mb FROM dba_free_space WHERE tablespace_name = 'USERS'+ OS 层df -h
表空间扩容后为什么 dba_free_space 不变
执行成功后查 dba_free_space，空闲空间没增加，不是扩容失败，而是新文件刚创建、尚未被 Oracle 分配任何区（extent）。它处于“已存在但未使用”状态，需要触发一次实际写入才会体现。
- 最简单验证方式：往该表空间建一张测试表，比如
CREATE TABLE t1 (id NUMBER) TABLESPACE USERS，再查dba_free_space就能看到变化 - 如果建表也失败，说明表空间仍不可写（只读）、用户 quota 耗尽、或新文件路径所在磁盘无写权限（注意 Oracle 进程属主，非当前登录用户）
- 不要依赖
dba_free_space即时反映容量——它统计的是已分配但未使用的块；真正看容量上限，应查dba_data_files.bytes
status 和 tablespace_name 是否匹配，以及忽略 OMF/ASM 环境的路径规则。这些点不卡在语法层面，却卡在执行后的可用性上。 
