ORA-01536报错本质是用户在永久表空间配额超限，需查user_ts_quotas中max_bytes值（-1为无限制），用ALTER USER QUOTA调整配额，而非扩容数据文件；TEMP表空间不参与配额检查，报错指向TEMP说明SQL写错表空间名或配置错误。
ORA-01536 报错不是表空间没空间，而是用户没配额——查 user_ts_quotas，用 ALTER USER QUOTA 解决，别去扩数据文件。
查当前用户的配额实际是多少
报错信息里写的表空间名（比如 'USERS'）一定是永久表空间，TEMP 或 TEMPORARY 不可能触发这个错误。真正要看的是用户被分配了多少额度：
- 运行
SELECT tablespace_name, bytes, max_bytes FROM user_ts_quotas; -
max_bytes = -1：无限制，OK -
max_bytes > 0：单位是字节，比如52428800就是 50MB，若bytes >= max_bytes就已超限 -
max_bytes = 0：禁止写入，任何 DDL/DML 都会直接失败
给用户加配额的正确写法
语法必须带单位，大小写要和 dba_tablespaces.tablespace_name 完全一致（Linux 下部分配置区分大小写）：
-
ALTER USER scott QUOTA 200M ON users;—— 显式分配 200MB -
ALTER USER scott QUOTA UNLIMITED ON users;—— 只放开该表空间，比GRANT UNLIMITED TABLESPACE更安全 -
ALTER USER scott QUOTA 0 ON users;—— 临时禁写，适合冻结测试账号 - 不能写成
200或200MB（Oracle 不认MB，只认M）
为什么改了配额还是报 ORA-01536？
常见漏点不是权限或语法，而是执行对象错位：
- 连错了用户：你改了
scott的配额，但应用连的是app_user，得查dba_users确认当前连接账号 - 建表指定了别的表空间：DDL 里写了
TABLESPACE example，但你只给users加了配额 - 默认表空间不匹配：查
SELECT username, default_tablespace FROM dba_users WHERE username = 'YOUR_USER';，确保和配额目标一致 - 长事务已占满旧配额：新配额生效后，正在执行的事务仍按旧限额检查，需等它结束或回滚
临时表空间（TEMP）根本不用配额
如果错误信息里出现 TEMP 或 TEMPORARY，那基本可以断定是 SQL 写错了表空间名，或者 DBA 错把用户默认表空间设成了临时表空间（极罕见且错误）：
-
ORA-01652才是临时表空间不足的真实报错，查v$sort_usage或v$temp_space_header - 临时文件扩容用
ALTER DATABASE TEMPFILE ... RESIZE或ADD TEMPFILE，和QUOTA无关 - 永远不要对
TEMP表空间执行ALTER USER ... QUOTA，语法虽不报错，但毫无作用
配额是按用户+表空间粒度控制的，一个用户在 USERS 有配额，在 EXAMPLE 没配额，是完全合法的状态；最容易被忽略的是：配额检查发生在语句解析阶段，不是执行时——所以即使磁盘还有空、表空间还有 free space，只要配额卡死，就立刻报错。
