为什么Oracle 12c中C双井用户无法在PDB中直接创建表？

C##用户在PDB中执行CREATE TABLE报ORA-01031，因其作为公共用户仅在CDB$ROOT默认拥有权限，必须在每个目标PDB内显式授予CREATE SESSION、CREATE TABLE等权限，并配置表空间配额（如ALTER USER C##APP QUOTA UNLIMITED ON users），且授权须在ALTER SESSION SET CONTAINER=pdb_name后执行。

为什么C##用户在PDB里执行CREATE TABLE会报ORA-01031

因为c##用户是公共用户，默认只在cdb$root中拥有权限，即使它能跨pdb存在，也不会自动继承目标pdb内的对象操作权限。你在pdb中用c##app登录后执行create table失败，根本不是语法或表空间问题，而是缺少该pdb上下文中的create table权限。

常见错误现象：

• 连接成功（sqlplus c##app/oracle@pdb_service），但CREATE TABLE t1(id NUMBER)直接报ORA-01031: insufficient privileges
• SELECT * FROM session_privs返回空，说明当前会话没有任何系统权限
• 误以为GRANT RESOURCE TO c##app在CDB$ROOT执行就够了——其实它只生效于CDB$ROOT，对PDB无效

C##用户必须在每个PDB中单独授权

Oracle不会把CDB级的授权“广播”到所有PDB，哪怕你用了CONTAINER=ALL创建用户，也得手动在每个PDB里补权限。否则，c##app在PDB1里连CREATE SESSION都没有，更别说建表。

实操步骤：

• 先切到目标PDB：ALTER SESSION SET CONTAINER = pdb1;
• 再授基本权限：GRANT CREATE SESSION, CREATE TABLE TO c##app;
• 配表空间配额（关键！）：ALTER USER c##app QUOTA UNLIMITED ON users;（否则建表仍报ORA-01031或ORA-01950）
• 如果要用RESOURCE角色，也得在这一步执行：GRANT RESOURCE TO c##app;——它只是预定义角色，不自动带配额

为什么GRANT RESOURCE在CDB$ROOT里执行没用

RESOURCE角色本身不包含CREATE TABLE系统权限，它只是一组权限集合；而Oracle 12c起，角色授权作用域严格绑定容器。你在CDB$ROOT执行GRANT RESOURCE TO c##app CONTAINER=ALL，实际只把角色授予了CDB$ROOT和SEED，PDB完全不受影响。

验证方式：

• 在PDB中查：SELECT granted_role FROM dba_role_privs WHERE grantee = 'C##APP'; → 返回空
• 在CDB$ROOT中查：SELECT con_id,granted_role FROM cdb_role_privs WHERE grantee = 'C##APP'; → 只有CON_ID=1（CDB$ROOT）有记录
• 所以别指望“一次授权，处处生效”，每个PDB都是独立权限域

真正要避免的坑：混淆CONTAINER=ALL的语义

CONTAINER=ALL只控制用户创建范围和密码/默认表空间等元数据同步，**不传递权限**。很多人以为加了这个就万事大吉，结果连SELECT * FROM v$session都报错——因为SELECT_CATALOG_ROLE也没在PDB里授。

容易被忽略的细节：

• 即使用户存在、密码正确、服务名对，只要没在目标PDB里显式执行GRANT，它就是个“空壳账号”
• 用SHOW CON_NAME确认当前容器是PDB，再查SELECT SYS_CONTEXT('USERENV', 'CURRENT_SCHEMA') FROM DUAL;看是否真进了目标schema
• PDB内建表失败时，优先检查QUOTA而非权限——ORA-01031可能掩盖ORA-01950（无配额）的真实原因