unlimited tablespace是仅能直接授予用户的系统权限，不可通过角色中转；即使resource角色被嵌套授予，用户也不会获得该权限，且其存在与否需通过dba_sys_privs或session_privs确认。
UNLIMITED TABLESPACE 是系统权限，不是角色或对象权限
它只能直接授予用户，不能通过角色中转。哪怕你把 RESOURCE 角色赋给一个角色 r1，再把 r1 赋给用户，该用户也不会自动获得 UNLIMITED TABLESPACE 权限——这是 Oracle 的硬性限制，不是配置遗漏。
常见错误现象：用户明明有 RESOURCE，却在建表时报 ORA-01950: no privileges on tablespace 'USERS'。这时别急着查角色嵌套，先确认是否真有该系统权限：
-
SELECT * FROM dba_sys_privs WHERE grantee = 'USERNAME' AND privilege = 'UNLIMITED TABLESPACe';（注意拼写是TABLESPACe，末尾无 E） - 或者更直接：
SELECT * FROM session_privs;（连接后执行，看当前会话是否含该权限）
GRANT unlimited tablespace TO user_name 会覆盖所有配额限制
一旦执行这条语句，用户对所有永久表空间（包括 SYSTEM、SYSAUX）都获得无限制使用能力，之前用 ALTER USER ... QUOTA ... ON ... 设置的单个表空间配额全部失效。
这意味着：
- 即使你已执行过
ALTER USER scott QUOTA 0 ON users;，只要GRANT unlimited tablespace TO scott;成功，scott 依然能在USERS表空间建表 -
DBA_TS_QUOTAS视图里对应记录可能消失或显示MAX_BYTES = -1，但实际以权限为准 - 临时表空间不受影响——
UNLIMITED TABLESPACE不控制TEMPORARY TABLESPACE的排序/临时段使用
回收 UNLIMITED TABLESPACE 后，用户必须显式配额才能建对象
执行 REVOKE unlimited tablespace FROM user_name; 后，用户立刻失去跨表空间无限制写入能力。此时若未提前设置配额，任何建表、建索引操作都会报 ORA-01950。
补救方式只有两种，且必须显式执行：
- 给默认表空间设配额：
ALTER USER user_name QUOTA 100M ON users; - 或直接给无限配额（仅限该表空间）：
ALTER USER user_name QUOTA UNLIMITED ON users;
注意：QUOTA UNLIMITED ON users 和 GRANT unlimited tablespace 效果相似，但前者只作用于 users 表空间，后者作用于全部永久表空间；前者可被角色继承（因属用户属性），后者不可。
RESOURCE 角色附带 UNLIMITED TABLESPACE，但仅限直接授予用户时生效
当你执行 GRANT connect, resource TO alice;，Oracle 内部会隐式赋予 alice UNLIMITED TABLESPACE 权限——这不是 RESOURCE 角色定义里写的，而是数据库的特殊逻辑。
但这个隐式授予非常脆弱：
- 如果之后执行
REVOKE resource FROM alice;，权限会立即消失 - 如果
RESOURCE是通过中间角色授予的（如GRANT resource TO role_a; GRANT role_a TO alice;），alice就不会得到该权限 - Oracle 19c 及以后版本仍保持此行为，未改变
生产环境里别依赖这种隐式行为。需要无限制表空间能力，就明明白白执行 GRANT unlimited tablespace TO ...；需要精细控量，就用 QUOTA 配合 REVOKE unlimited tablespace ——两者混用容易互相掩盖，排查时最头疼。
