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（无配额）的真实原因
