ora-01950报错根本原因是用户在目标表空间无quota配额，而非权限不足；即使有unlimited tablespace权限或create table权限，若dba_ts_quotas中查不到该用户在对应表空间的配额记录（如tbs_idx），建表或建索引仍会失败。
ora-01950 报错根本不是权限没给全，而是用户在目标表空间上压根没有配额（quota）——哪怕你已经 grant unlimited tablespace，也可能照样失败。
查不到 USER_TS_QUOTAS 就等于没配额
普通用户无法访问 DBA_TS_QUOTAS，但能安全执行：
SELECT * FROM USER_TS_QUOTAS;
如果结果为空，说明你在所有表空间上都未被分配任何配额。这不是“看不见”，是真没有。
注意：UNLIMITED TABLESPACE 权限不会让这条查询变出记录——它只是绕过配额检查，不等于自动写入配额元数据。
UNLIMITED TABLESPACE 不等于自动获得所有表空间的 QUOTA
这个系统权限的作用是：跳过对「每个表空间单独配额」的校验，但它有硬性限制：
- 不向下继承到 PDB，必须在 PDB 内显式再授一次
- 若数据库启用了大小写敏感（如
SEC_CASE_SENSITIVE_LOGON=TRUE），TBS_IDX和tbs_idx被视为不同表空间，配额/权限不互通 - 它不解决表空间本身处于
OFFLINE或READ ONLY状态的问题 - 它不能覆盖安全策略禁用（比如 Oracle Vault 或自定义审计规则直接拦截该权限）
索引建在哪个表空间，就得在哪配 quota
CREATE INDEX 语句里明确写了 TABLESPACE TBS_IDX？那 DBA 必须执行：
ALTER USER your_user QUOTA UNLIMITED ON TBS_IDX;
如果索引分散在多个表空间（例如主键索引在 TBS_IDX、函数索引在 TBS_FUN），每个都得单独配。漏一个，建对应索引时就报 ORA-01950。
别用 GRANT UNLIMITED TABLESPACE TO your_user 代替——它绕过所有配额控制，多数生产环境策略禁止启用，且不解决单表空间缺失配额的问题。
最容易被忽略的细节：DEFAULT TABLESPACE ≠ 自动配额
即使 USER_USERS.DEFAULT_TABLESPACE 返回的是 TBS_IDX，也不代表你能在里面建对象。Oracle 仍会检查该表空间上的配额，哪怕建索引时没写 TABLESPACE 子句。
更隐蔽的是：DBA 可能回收了 UNLIMITED TABLESPACE 权限（比如通过角色调整或脚本批量清理），但忘了同步补配额，这时用户行为突然中断，却查不出明显变更点。
