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无效
必须在每个PDB中单独执行GRANT语句
c##用户不会被“广播”授予权限，哪怕你用了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完全不受影响。
注意：
-
GRANT CONNECT, RESOURCE TO c##app必须在ALTER SESSION SET CONTAINER = pdb_name之后执行 - 不能在PDB中执行带
CONTAINER=ALL的授权语句，会直接报ORA-65047: not allowed in a pluggable database -
DBA角色在PDB中不可用，执行会触发ORA-01917: user or role 'DBA' does not exist
真正容易被忽略的配额与容器状态依赖
即使你正确切到PDB并执行了GRANT，如果该PDB中USERS表空间不存在、未设置为默认表空间，或c##app没被分配配额，CREATE TABLE依然失败——报错可能仍是ORA-01031，而非明确提示配额问题。
排查时必须确认：
SELECT tablespace_name, status FROM dba_tablespaces WHERE tablespace_name = 'USERS';SELECT username, default_tablespace, temporary_tablespace FROM dba_users WHERE username = 'C##APP';SELECT tablespace_name, bytes/1024/1024 MB FROM dba_ts_quotas WHERE username = 'C##APP';- 目标PDB是否处于
OPEN状态：SELECT name, open_mode FROM v$pdbs WHERE name = 'YOUR_PDB';
