oracle 12.2起resource角色不再隐含unlimited tablespace权限，用户需显式授予quota或unlimited tablespace才能建表；否则报ora-01536。
Oracle 12c R2（12.2）起，RESOURCE角色不再隐含UNLIMITED TABLESPACE系统权限。这不是bug或配置错误，而是Oracle官方明确的行为变更——RESOURCE被“瘦身”了，剥离了过去隐式授予的UNLIMITED TABLESPACE权限。
查不到UNLIMITED TABLESPACE就说明没这个权限
执行SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE = 'U1' AND PRIVILEGE = 'UNLIMITED TABLESPACE'返回空行，基本可确认该用户未获得此权限。注意：DBA_TS_QUOTAS为空也不代表有无限权限，它只记录显式设置的配额；真正决定配额是否生效的是UNLIMITED TABLESPACE是否存在。
- 在12.2+版本中，
GRANT RESOURCE TO u1后，这条查询一定为空 - 若仍看到
UNLIMITED TABLESPACE，说明是手动授的，或通过DBA角色、或通过老版本迁移脚本遗留下来的 - 不要依赖
DBA_ROLE_PRIVS里有没有RESOURCE来判断空间权限——它现在和UNLIMITED TABLESPACE完全解耦
RESOURCE角色现在只包含CREATE类权限
现在的RESOURCE就是一个纯对象创建集合，不含任何空间控制逻辑。它的实际权限可通过SELECT * FROM ROLE_TAB_PRIVS WHERE ROLE = 'RESOURCE'和SELECT * FROM ROLE_SYS_PRIVS WHERE ROLE = 'RESOURCE'验证：
- 保留的系统权限包括：
CREATE CLUSTER、CREATE INDEXTYPE、CREATE OPERATOR、CREATE PROCEDURE、CREATE SEQUENCE、CREATE TABLE、CREATE TRIGGER、CREATE TYPE、CREATE VIEW - 明确移除了：
UNLIMITED TABLESPACE（不再出现在ROLE_SYS_PRIVS中） - 这意味着：哪怕你授了
RESOURCE，只要没设QUOTA，用户建表立刻报ORA-01536: space quota exceeded
为什么建表失败？因为没配额也没无限权限
典型报错场景：GRANT CONNECT, RESOURCE TO app_user后，用户执行CREATE TABLE t1 (x INT)直接失败。原因很直接：
- 用户默认表空间是
USERS，但DBA_TS_QUOTAS里查不到该用户的配额记录 -
DBA_SYS_PRIVS里也没有UNLIMITED TABLESPACE - Oracle要求：要么有
UNLIMITED TABLESPACE，要么在目标表空间有显式QUOTA（哪怕0） - 修复只需一行：
ALTER USER app_user QUOTA 10M ON USERS
升级后最易忽略的兼容性坑
从11g/12.1升级到12.2+后，原来能跑的建用户脚本可能突然失效。尤其注意以下三点：
- 旧脚本里写
GRANT RESOURCE TO u就以为万事大吉——现在必须补QUOTA语句，否则所有建表操作都会中断 - 如果脚本里还带
REVOKE UNLIMITED TABLESPACE FROM u，而用户根本没这个权限，会报ORA-01952，建议加WHENEVER SQLERROR CONTINUE或先查再撤 - 用
DBA_ROLES或ROLE_SYS_PRIVS做权限审计时，别再假设RESOURCE==UNLIMITED TABLESPACE，它们现在是两条独立权限线
真正麻烦的不是权限变少了，而是脚本里藏着“我以为它还在”的逻辑——这种隐式依赖在批量建用户、CI/CD自动部署里最容易爆发。
