ORA-01536报错本质是用户表空间配额不足，需查user_ts_quotas中max_bytes值（-1为无限制），通过ALTER USER ... QUOTA调整配额，而非盲目扩容数据文件。
ORA-01536 报错本质是用户配额不够，不是表空间没空间
看到 ora-01536: space quota exceeded for tablespace 'users'，第一反应别急着扩容数据文件——大概率是当前用户在该表空间的使用额度（quota）被卡死了。哪怕 dba_free_space 显示表空间还有 2gb 空闲，只要用户配额设成 50m，第 51mb 的 insert 就会直接报错。
- 查配额：运行
SELECT tablespace_name, bytes, max_bytes FROM user_ts_quotas;，max_bytes是关键值：-1表示无限制，其它正数就是硬上限（单位字节） - 常见误判：把
ALTER TABLESPACE ... ADD DATAFILE当万能解，结果加完照样报错——因为配额没动，用户还是只能用那最初的 50M - 典型场景：DBA 创建用户后忘了配 quota；或迁移对象到新表空间时，只改了
DEFAULT TABLESPACE，却没同步调整对应 quota
给用户增加配额：alter user quota on
这是最精准、最小权限的修复方式，适合生产环境明确控制资源分配的场景。
- 语法必须带单位：
ALTER USER scott QUOTA 200M ON users;（200不行，200M或204800K才有效） - 可设为 0 来禁止写入：
ALTER USER scott QUOTA 0 ON users;，适合临时冻结账号 - 注意大小写不敏感，但表空间名要和
dba_tablespaces.tablespace_name完全一致（比如USERS和users在多数库中等价，但某些区分大小写的配置下会失败） - 执行后立即生效，无需重启或刷新缓存
彻底放开限制：quota unlimited 或 grant unlimited tablespace
开发库、测试库或临时救急时常用，但生产环境慎用——它绕过了配额管控逻辑。
- 按表空间放开：
ALTER USER scott QUOTA UNLIMITED ON users;，只影响指定表空间，不影响其它表空间的配额设置 - 全局放开：
GRANT UNLIMITED TABLESPACE TO scott;，用户可在所有表空间无限写入（包括 SYSTEM、SYSAUX！风险更高） - 撤销方式对称：
REVOKE UNLIMITED TABLESPACE FROM scott;或ALTER USER scott QUOTA 0 ON users; - 注意权限依赖：
UNLIMITED TABLESPACE是系统权限，普通用户无法自行授予，必须由 DBA 或具有GRANT ANY PRIVILEGE的账号执行
容易被忽略的细节和连带影响
配额修改看似简单，但几个边界情况常导致反复踩坑。
- 临时表空间（
TEMPORARY TABLESPACE）不受QUOTA控制，ORA-01536永远不会出现在临时表空间上——如果报错指向 TEMP，那一定是日志/审计/或 SQL 写错了表空间名 - 用户默认表空间变更后，旧表空间的 quota 不会自动清零，可能残留
max_bytes = 0导致“看不见的阻塞” - Oracle 23c 开始支持
AUTOEXTEND数据文件，但配额仍是独立开关；即使文件能自动增长，用户 quota 不够照样报错 - 用
CREATE USER语句建用户时，若未显式指定QUOTA，默认是0（即禁止写入），不是“不限制”——这点和很多人直觉相反
真正卡住的往往不是磁盘空间，而是那一行没执行的 ALTER USER ... QUOTA。确认 user_ts_quotas 视图里的 max_bytes 值，比猜“是不是空间满了”快十倍。
