alter user quota 是设置用户表空间配额的唯一有效方式，角色不继承配额，unlimited tablespace 权限会覆盖所有配额设置，quota 0 与未设置效果相同但具审计意义，且仅约束永久段。
ALTER USER QUOTA 是唯一生效的配额设置方式
Oracle 不会自动给用户分配表空间配额，没设 = 0，不是“默认允许”。ALTER USER 是设置配额的唯一有效手段，角色（如 CONNECT 或 RESOURCE）不带配额继承。常见误操作是只授 CREATE TABLE 权限却忘了配额，结果建表直接报 ORA-01536。
-
ALTER USER scott QUOTA 100M ON users;：显式赋予 100MB 上限，单位不区分大小写，但不能带空格（100 M错，100M对） -
ALTER USER scott QUOTA 0 ON users;：彻底禁止在该表空间新建段（表、索引等），已有对象不受影响，但 INSERT 触发 extent 扩展时仍可能失败 -
ALTER USER scott QUOTA UNLIMITED ON users;：仅对users表空间放开限制，比UNLIMITED TABLESPACE更收敛 - 表空间名大小写敏感：若创建时用了双引号
"USERS"，配额语句也必须写"USERS"，否则报ORA-00959
QUOTA 0 和没设配额，效果一样但含义不同
查 DBA_TS_QUOTAS 返回空行，说明用户在该表空间**从未显式设过配额**，此时 Oracle 按“无配额”处理，等效于 QUOTA 0。这不是遗漏，是强制策略。所以不能靠“没查到记录”来判断是否安全，而要主动确认。
- 执行
SELECT * FROM DBA_TS_QUOTAS WHERE USERNAME = 'SCOTT'，空结果 ≠ 可用空间，而是等于禁止使用 -
QUOTA 0 ON users是显式声明禁止，和“没设”在行为上一致，但留下审计痕迹，便于后续排查 - 如果用户已有对象占了空间，新设
QUOTA 10M会立即生效——哪怕当前已用 12M，后续 DML 就会报ORA-01536 - 临时表空间（
TEMP）、撤销表空间（UNDOTBS1）不支持配额，对它们执行QUOTA会直接报ORA-02156
UNLIMITED TABLESPACE 权限会让 QUOTA 失效
UNLIMITED TABLESPACE 是系统级权限，优先级高于任何 QUOTA 设置。一旦授予，所有表空间配额检查都会被绕过，DBA_TS_QUOTAS 里也查不到记录——不是配额丢了，是根本没走配额路径。
- 验证是否生效：
SELECT * FROM DBA_SYS_PRIVS WHERE USERNAME = 'SCOTT' AND PRIVILEGE = 'UNLIMITED TABLESPACE'，有结果即表示QUOTA不起作用 -
RESOURCE角色隐含UNLIMITED TABLESPACE，所以授RESOURCE后再设QUOTA 1M ON users是白忙活 - 生产环境想控空间，应先
REVOKE RESOURCE FROM scott或REVOKE UNLIMITED TABLESPACE FROM scott，再设QUOTA - 回收
UNLIMITED TABLESPACE后，已有对象 DML 不受影响，但新对象创建或扩展会重新受配额约束
配额只管永久段，不管临时段和回滚段
QUOTA 的作用域非常明确：只约束用户在指定表空间中创建的**永久段**（表、索引、LOB、物化视图等）。排序、哈希连接、全局临时表用的临时段，事务产生的回滚信息，都不计入配额。
- 用户执行大排序报空间不足，问题不在
USERS配额，而在其TEMPORARY TABLESPACE是否受限 - 分区表每个分区都单独计入配额；但物化视图日志、审计表等系统对象属于
SYS，不占普通用户配额 - 真实用量要看
DBA_SEGMENTS：SELECT tablespace_name, SUM(bytes)/1024/1024 MB FROM DBA_SEGMENTS WHERE owner = 'SCOTT' GROUP BY tablespace_name -
CREATE TABLE t AS SELECT占用的是目标表所在表空间的配额，哪怕源表在别的表空间
配额生效是即时的，没有缓存或延迟；但最容易被忽略的是权限链——你以为只改了 QUOTA，其实 RESOURCE 角色悄悄开了后门。
