ORA-01536报错本质是用户在指定表空间的配额（max_bytes）耗尽，与表空间剩余空间无关；需查user_ts_quotas中max_bytes值（-1为无限制），用ALTER USER QUOTA精确调整配额，单位不可省略，且立即生效。
ORA-01536报错不是表空间没空间，是用户没配额
看到ORA-01536: space quota exceeded for tablespace 'USERS'，别急着加数据文件或查dba_free_space——这个错误和表空间剩余多少空间完全无关。它只说明当前用户在指定表空间的配额（max_bytes）已被用完。哪怕dba_free_space显示还有 5GB 空闲，只要用户配额设为 50MB 且已写满，INSERT 或 CREATE 就会立刻失败。
查配额必须看user_ts_quotas，不是dba_free_space
运行以下查询确认真实配额状态：
SELECT tablespace_name, bytes, max_bytes FROM user_ts_quotas;
max_bytes 的含义很关键：
-
-1：无限制（OK） - 正整数（如
52428800）：单位字节，即 50MB；若bytes >= max_bytes，就已超限 -
0：禁止写入，任何 DDL/DML 都会被拦截
注意：tablespace_name 大小写需与 dba_tablespaces.tablespace_name 完全一致（某些配置下区分大小写），不能靠猜测拼写。
ALTER USER QUOTA语法极易出错
给用户加配额必须用 ALTER USER，且单位不可省略：
-
ALTER USER scott QUOTA 200M ON users;✅ 正确 -
ALTER USER scott QUOTA 200 ON users;❌ 报错：200 是非法值 -
ALTER USER scott QUOTA UNLIMITED ON users;✅ 解除该表空间限制 -
ALTER USER scott QUOTA 0 ON users;✅ 彻底禁写，适合冻结账号
执行后立即生效，无需重启、刷新或重连会话。但若用户当前正执行长事务且已占满旧配额，新配额对**该事务无效**——配额检查发生在语句解析阶段，事务中途不重检。
为什么改了配额还是报错？常见漏点
执行 ALTER USER 后仍触发 ORA-01536，大概率踩了这些坑：
- 建表或插入时显式指定了其他表空间（如
TABLESPACE example），但你只给users加了配额 - 连接用户不是你修改的那个（比如改了
scott，但应用连的是app_user） - 目标表空间名大小写不一致（
USERS≠users，尤其在 Linux + 区分大小写的初始化参数下） - 用户被授予了
UNLIMITED TABLESPACE系统权限，但又被单独设了QUOTA 0——后者优先级更高，仍会拦截
最隐蔽的点是：临时表空间（TEMP）压根不走配额机制，ORA-01536 里出现 TEMP 只能说明 SQL 写错了表空间名，或者 DBA 错误地把用户默认表空间设成了临时表空间。
