查不到“没有限制配额”的用户，是因为unlimited tablespace是系统权限而非配额，不存于dba_ts_quotas；应查dba_sys_privs中privilege='unlimited tablespace'的记录，并注意resource角色隐含该权限。
查不到“没有限制配额”的用户，是因为 Oracle 根本不把 UNLIMITED TABLESPACE 当作一种配额——它压根不写进 DBA_TS_QUOTAS。真正要找的是拥有该系统权限的用户，而不是配额为 -1 的记录。
为什么 DBA_TS_QUOTAS 查不到无限配额用户
DBA_TS_QUOTAS 只存显式设置的配额，比如 ALTER USER u QUOTA 50M ON users。一旦用户被授予 UNLIMITED TABLESPACE，Oracle 就跳过配额检查，该视图里连一行都不会生成。所以：
- 查
MAX_BYTES = -1？这个值只在显式设了QUOTA UNLIMITED时才可能出现，但 Oracle 不支持该语法，实际永远见不到 - 查结果为空？不能说明没无限权限，反而很可能是真有
UNLIMITED TABLESPACE - 查
MAX_BYTES = 0？那是显式禁止，和“无限”完全相反
正确查询方式：从 DBA_SYS_PRIVS 入手
所有真正具备“无限制建表空间对象”能力的用户，都必须通过系统权限获得，唯一可靠入口是 DBA_SYS_PRIVS：
SELECT GRANTEE, ADMIN_OPTION FROM DBA_SYS_PRIVS WHERE PRIVILEGE = 'UNLIMITED TABLESPACE';
注意几个关键点：
-
GRANTEE是用户名（不是角色名），因为UNLIMITED TABLESPACE不能授给角色 -
ADMIN_OPTION = 'YES'表示该用户还能转授此权限，属于高危配置，需重点标记 - 若当前用户无
SELECT ANY DICTIONARY，查DBA_SYS_PRIVS会无结果或报错，可改用ALL_SYS_PRIVS（只显示你有权看到的）或USER_SYS_PRIVS（仅当前用户）
别漏掉 RESOURCE 角色带来的隐含权限
直接授予 RESOURCE 角色，Oracle 会硬编码附带 UNLIMITED TABLESPACE 权限——这条记录不会出现在 DBA_ROLE_PRIVS 或 ROLE_SYS_PRIVS 中，但真实生效：
- 执行
SELECT * FROM DBA_ROLE_PRIVS WHERE GRANTEE = 'U1' AND GRANTED_ROLE = 'RESOURCE'成立 → 几乎肯定有无限权限 - 该隐含权限只在
RESOURCE直接授予用户时触发；若通过中间角色（如APP_ROLE）间接继承，则不生效 -
REVOKE RESOURCE FROM u1会连带收回UNLIMITED TABLESPACE，可能导致已有表插入失败（ORA-01950）
最常被忽略的复杂点：权限链与配额失效并存
你以为给用户设了 ALTER USER u QUOTA 1M ON users 就能控住空间？如果该用户同时有 UNLIMITED TABLESPACE（无论是直授还是来自 RESOURCE），这条配额就彻底失效。验证只需一句：
SELECT PRIVILEGE FROM USER_SYS_PRIVS WHERE PRIVILEGE = 'UNLIMITED TABLESPACE';
只要返回结果，DBA_TS_QUOTAS 里的任何配额值都不起作用。真正麻烦的不是查不到，而是查到了却不知道权限来自哪一层——可能藏在角色继承链深处，也可能被 DBA 角色覆盖。
