ORA-01144 是因 SMALLFILE 表空间单个数据文件块号超 2^22−1=4194303 的硬限制所致，与权限、磁盘空间无关；应通过 ADD DATAFILE 横向扩容，而非 RESIZE。
ora-01144 不是配置错误或权限问题，而是 oracle 对单个数据文件的硬性块数上限触发的拒绝操作——你试图写的块号超出了 2^22 - 1 = 4194303 的边界。
为什么 resize 或 add datafile 会突然报 ORA-01144
这个错误只发生在 SMALLFILE 表空间（默认类型），其 rowid 中用 22 位表示块号（block number），因此单个数据文件最多容纳 4194303 个数据库块。超出即报错，和磁盘空间、OS 限制、用户权限都无关。
- 常见触发操作：
alter database datafile ... resize、alter tablespace ... add datafile ... size - 错误信息里两个数字很关键：比如
File size (4194304 blocks) exceeds maximum of 4194303 blocks—— 差 1 块就失败 - 实际最大字节数 =
db_block_size * 4194303；若db_block_size=8192（8KB），则上限为32GB - 8KB，约 32767MB -
SYSTEM和SYSAUX永远是 SMALLFILE，无法改为 BIGFILE
怎么确认当前表空间是 SMALLFILE 还是 BIGFILE
别猜，直接查：
SELECT tablespace_name, bigfile FROM dba_tablespaces WHERE tablespace_name = 'USERS';
返回 'NO' 就是 SMALLFILE，'YES' 才是 BIGFILE。注意：BIGFILE 表空间只允许一个数据文件，且上限是 4G 块（即 4 × 1024 × 1024 = 4194304 块），但它的 block number 字段是 32 位，所以不会卡在 4194303。
- 新建 BIGFILE 表空间语法：
CREATE BIGFILE TABLESPACE tbs_bf DATAFILE '/path/to/file.dbf' SIZE 50G; - 已有 SMALLFILE 表空间不能“升级”为 BIGFILE，只能重建或换策略
- 查询当前块大小：
SHOW PARAMETER db_block_size
最稳妥的扩容方案：add datafile 而非 resize
对 SMALLFILE 表空间，不要执着于把一个文件扩到极限，而应横向增加多个合规大小的数据文件。
- 单个新文件 size 建议 ≤
32767M（即 32G - 1M），留点余量避免四舍五入误差 - 示例命令：
ALTER TABLESPACE USERS ADD DATAFILE '/u01/oradata/ORCL/users02.dbf' SIZE 32767M; - 路径需有写权限，且所在文件系统剩余空间 ≥ 指定 size
- 可一次加多个：
ADD DATAFILE ... SIZE 32767M, ... SIZE 32767M（Oracle 12c+ 支持） - 加完立刻生效，无需重启；后续对象自动分配到空闲文件中（取决于 LMT 管理方式）
容易被忽略的关键细节
很多人试过 resize 32767M 还报错，是因为没考虑单位换算和块对齐。
- 用 MB 指定 size 时，Oracle 会按
db_block_size向上取整到整块，例如 32767M 在 8KB 块下实际是32767 × 1024 × 1024 / 8192 = 4194176块 —— 安全；但 32768M 就变成 4194304 块 —— 超限 -
dba_data_files.maxbytes显示的是当前文件允许的最大字节数，不是理论极限；它可能已被人工设小（如autoextend on maxsize 20G） - 如果表空间启用了
autoextend，检查是否已触达maxsize上限，而非误以为还能手动 resize - 裸设备（raw device）上建文件时，OS 层面的设备大小也必须 ≥ Oracle 请求的 size，否则报错可能掩盖真实原因
