ora-01536报错本质是用户在永久表空间的配额超限，与表空间物理空间及临时表空间无关；需查user_ts_quotas中max_bytes值（-1为无限制），用alter user quota调整配额，语法须带单位且表空间名大小写需匹配。
ora-01536 不是表空间没空间，而是用户被卡死了配额 —— 查 user_ts_quotas，改 alter user ... quota，别去动数据文件或临时表空间。
查配额：别看 dba_free_space，要看 user_ts_quotas
错误现象：报错 ORA-01536: space quota exceeded for tablespace 'USERS'，但 dba_free_space 显示该表空间还有 2GB 空闲，执行仍失败。
根本原因：ORA-01536 只检查用户在该永久表空间的配额（max_bytes），和表空间物理剩余空间完全无关。
-
SELECT tablespace_name, bytes, max_bytes FROM user_ts_quotas;—— 必须用这个查，不是dba_free_space或v$sort_usage -
max_bytes = -1：无限制（OK） -
max_bytes > 0：单位字节，比如52428800就是 50MB，超了就报错 -
max_bytes = 0：禁止写入，任何 DML/DDL 都会直接拦截
改配额：语法带单位、大小写要对、立即生效
错误做法：写 ALTER USER scott QUOTA 200 ON users; —— 缺少单位，Oracle 报错 ORA-00922: missing or invalid option。
- 必须带单位：
200M、2G、204800K合法；200、200m（小写 m）非法 - 表空间名大小写敏感取决于数据库参数，稳妥起见先查
SELECT tablespace_name FROM dba_tablespaces;确认拼写（如USERS还是users） - 执行后立即生效，无需重启实例、刷新缓存或重连会话
- 如果用户当前正运行长事务且已占满旧配额，新配额不会回溯修复该事务 —— 配额检查发生在语句解析阶段
临时表空间报 ORA-01536？那一定是 SQL 写错了
真实现象：错误信息里出现 tablespace 'TEMP' 或 'TEMPORARY'，但 ORA-01536 永远不会在临时表空间触发。
- 临时表空间（
TEMP）完全不受QUOTA机制控制，用户无法、也不需要被授予对它的配额 - 遇到这种情况，99% 是建表/索引时误写了
TABLESPACE TEMP，例如：CREATE TABLE t(x INT) TABLESPACE TEMP; - 极少数情况是 DBA 错误地把用户默认表空间设成了临时表空间：
ALTER USER scott DEFAULT TABLESPACE TEMP;—— 这属于严重配置错误，需立刻纠正 - 临时表空间真正爆满的错误是
ORA-01652，解决路径完全不同（查v$sort_usage、扩容 tempfile）
UNLIMITED 是快捷解法，但得清楚代价
生产环境快速救急常用，但权限边界容易失控。
-
ALTER USER scott QUOTA UNLIMITED ON users;—— 只放开指定表空间，相对安全 -
GRANT UNLIMITED TABLESPACE TO scott;—— 全局放开，用户可在SYSTEM、SYSAUX等关键表空间无限写入，DBA 权限才可执行 - 撤销操作对称：
REVOKE UNLIMITED TABLESPACE FROM scott;或ALTER USER scott QUOTA 0 ON users; - 注意：普通用户无法自行授予或撤销这些权限，必须由 DBA 或拥有
GRANT ANY PRIVILEGE的账号操作
配额看似只是个数字，但它在语句解析时硬性拦截，不依赖事务状态、不延迟生效、不区分对象类型 —— 这也是为什么加完配额还报错，大概率是语句本身指定了错误的表空间，或者用户正在执行的事务已锁定旧配额上限。
