oracle 11g中connect角色仅含create session权限，是官方主动降级而非bug；resource不含unlimited tablespace，建表需额外配额；授dba后connect/resource冗余，最小化授权更安全可控。
Oracle 11g中CONNECT角色只剩CREATE SESSION
因为Oracle从11g开始正式将CONNECT角色降级为仅含一个系统权限：CREATE SESSION。这不是bug，是官方主动收缩——早期版本（如9i/10g）里CONNECT还带CREATE TABLE、CREATE VIEW等，但这些本就不该属于“连接”语义，容易导致权限过度开放。
为什么老脚本授CONNECT后用户仍连不上？
常见现象是执行了GRANT CONNECT TO app_user;，但应用报ORA-01045: user APP_USER lacks CREATE SESSION privilege。原因有二：
-
CONNECT角色虽存在，但可能被DBA手动清空过权限（比如用REVOKE CREATE SESSION FROM CONNECT;） - 用户被创建时指定了
DEFAULT ROLE NONE，而CONNECT未被显式激活
安全做法是绕过角色，直接授予权限：GRANT CREATE SESSION TO app_user;
RESOURCE角色也不再包含UNLIMITED TABLESPACE
很多人以为GRANT CONNECT, RESOURCE TO app_user;就能建表，结果建表时报ORA-01536: space quota exceeded。这是因为：
-
RESOURCE在11g中只含CREATE TABLE、CREATE SEQUENCE等对象创建权限 - 它**不包含**
UNLIMITED TABLESPACE，也不自动给任何表空间配额 - 若未执行
ALTER USER app_user QUOTA 100M ON users;，用户无法在users表空间分配段
生产环境应避免直接授RESOURCE，改用自定义角色封装CREATE SESSION + CREATE TABLE + 显式QUOTA。
DBA角色会覆盖CONNECT和RESOURCE，但别混着授
执行GRANT DBA TO app_user;后，用户确实能登录、建表、查数据——因为DBA已完整包含CREATE SESSION和CREATE TABLE等全部权限。但若同时写GRANT CONNECT, RESOURCE, DBA TO app_user;：
- 不会报错，但会在
DBA_ROLE_PRIVS里留下冗余记录 - 后续审计或权限回收时，
REVOKE CONNECT FROM app_user;看似撤了，实际没影响，造成误判 - 真正要收权，必须
REVOKE DBA FROM app_user;，其他两个REVOKE纯属无效操作
权限链越短越可控：需要管理能力就只授DBA；只需要开发能力，就用最小化自定义角色；连不上就盯死CREATE SESSION有没有生效——别让角色名干扰判断。
